TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Chunking Attacks on File Backup Services Using Content-Defined Chunking [pdf]

123 点作者 cperciva2 个月前

9 条评论

pvg2 个月前
Less pdfblobby blog post <a href="https:&#x2F;&#x2F;www.daemonology.net&#x2F;blog&#x2F;2025-03-21-Chunking-attacks-on-Tarsnap.html" rel="nofollow">https:&#x2F;&#x2F;www.daemonology.net&#x2F;blog&#x2F;2025-03-21-Chunking-attacks...</a>
评论 #43438957 未加载
评论 #43441144 未加载
dchest2 个月前
This is great, thank you! This was on my wishlist for a few years:<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;crypto&#x2F;comments&#x2F;7imejm&#x2F;monthly_cryptography_wishlist_thread_december_2017&#x2F;dr00e10&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;crypto&#x2F;comments&#x2F;7imejm&#x2F;monthly_cryp...</a><p>I&#x27;ve tried to take a stab at this problem, but was not sure if it worked at all:<p><a href="https:&#x2F;&#x2F;gist.github.com&#x2F;dchest&#x2F;50d52015939a5772497815dcd33a7983" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;dchest&#x2F;50d52015939a5772497815dcd33a7...</a><p>It&#x27;s a modified BuzHash with the following changes:<p>- Substitution table is pseudorandomly permuted (NB: like Borg).<p>- Initial 32-bit state is derived from key.<p>- Window size slightly varies depending on key (by ~1&#x2F;4).<p>- Digest is scrambled with a 32-bit block cipher.<p>I also proposed adding (unspecified) padding before encrypting chunks to further complicate discovering their plaintext lengths. Glad to see I was on the right track :)
mananaysiempre2 个月前
&gt; I&#x27;m also exploring possibilities for making the chunking provably secure.<p>Seems like that’s possible[1] to do in a fairly straightforward manner, the question is if you can do this without computing a PRF for each byte.<p>[1] Obviously you’re always going to leak the total data size and the approximate size of new data per each transfer.
评论 #43440100 未加载
masfuerte2 个月前
Could this be mitigated by randomising the block upload order?<p>A fresh backup will be uploading thousands of blocks. You don&#x27;t want to create all the blocks before uploading, but a buffer of a hundred might be enough?
评论 #43440080 未加载
0cf8612b2e1e2 个月前
Having not read the paper, does this impact Restic or Borg which encrypt chunks?
评论 #43439791 未加载
评论 #43440124 未加载
amarshall2 个月前
My reading is that the primary vector is based on the size of the chunks (due to deterministic chunking and length-preserving encryption). Would padding chunks with random-length data (prior to encryption) help mitigate this at the cost of additional storage (and complexity)?
评论 #43442762 未加载
评论 #43448259 未加载
jszymborski2 个月前
Would SipHash be too slow? I think it would help mitigate the problem since you can key it to prevent known-plaintext attacks, right?<p>EDIT: or maybe this keyed rolling hash <a href="https:&#x2F;&#x2F;crypto.stackexchange.com&#x2F;questions&#x2F;16082&#x2F;cryptographically-secure-keyed-rolling-hash-function" rel="nofollow">https:&#x2F;&#x2F;crypto.stackexchange.com&#x2F;questions&#x2F;16082&#x2F;cryptograph...</a>
ThomasWaldmann2 个月前
borg discussion + wiki page:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;borgbackup&#x2F;borg&#x2F;discussions&#x2F;8694" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;borgbackup&#x2F;borg&#x2F;discussions&#x2F;8694</a>
pbsd2 个月前
In page 10, should the ring R be GF(2)[X]&#x2F;(X^32-1) and the map p be from {0,1}^{32} to R?
评论 #43446622 未加载