[HN Gopher] Chunking Attacks on File Backup Services Using Conte...
___________________________________________________________________
Chunking Attacks on File Backup Services Using Content-Defined
Chunking [pdf]
Author : cperciva
Score : 68 points
Date : 2025-03-21 17:30 UTC (5 hours ago)
(HTM) web link (www.daemonology.net)
(TXT) w3m dump (www.daemonology.net)
| pvg wrote:
| Less pdfblobby blog post
| https://www.daemonology.net/blog/2025-03-21-Chunking-attacks...
| cperciva wrote:
| Yeah I considered submitting that, but all the interesting
| details are in the paper.
| pvg wrote:
| The 'uninteresting' metadetails are what gets people to reach
| the interesting details so your first instinct was probably
| right but I don't think it really matters much in your case
| as you have enough local reputation to just blobpost plus
| you're around to talk about the stuff in either form.
| RadiozRadioz wrote:
| What is pdfblobby?
| cperciva wrote:
| An adjective. He was saying "less of a PDF blob".
| mananaysiempre wrote:
| > I'm also exploring possibilities for making the chunking
| provably secure.
|
| 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.
|
| [1] Obviously you're always going to leak the total data size and
| the approximate size of new data per each transfer.
| cperciva wrote:
| Right. I need to implement this and see if the performance is
| too painful.
| masfuerte wrote:
| Could this be mitigated by randomising the block upload order?
|
| A fresh backup will be uploading thousands of blocks. You don't
| want to create all the blocks before uploading, but a buffer of a
| hundred might be enough?
| cperciva wrote:
| Yes that's one of the things we're planning on doing. Doesn't
| help with small archives (or archives which don't contain much
| _new_ data) of course.
|
| I was originally planning on having that as part of 1.0.41, but
| the implementation turned out to be harder than I expected.
| 0cf8612b2e1e wrote:
| Having not read the paper, does this impact Restic or Borg which
| encrypt chunks?
| jszymborski wrote:
| > The reason rolling hashes are relevant to our topic is that
| many file backup services use variations of rolling hashes to
| achieve CDC. This paper will primarily look at Tarsnap [9], a
| project by the second author, but we will also look at other
| schemes such as Borg [2] and Restic [6]
|
| > It seems like compression as default (or even required) is
| important. Without compression, Borg and Restic are susceptible
| to known plaintext attacks. With compression, we still have
| theoretically sound (and harder) chosen-plaintext attacks but
| no known-plaintext attacks. Sadly, compression can also leak
| information for post-parameter extraction attacks, as shown in
| Example 4.3.
| cperciva wrote:
| Yes. They have been notified about these attacks.
| jszymborski wrote:
| Would SipHash be too slow? I think it would help mitigate the
| problem since you can key it to prevent known-plaintext attacks,
| right?
|
| EDIT: or maybe this keyed rolling hash
| https://crypto.stackexchange.com/questions/16082/cryptograph...
| pbsd wrote:
| In page 10, should the ring R be GF(2)[X]/(X^32-1) and the map p
| be from {0,1}^{32} to R?
___________________________________________________________________
(page generated 2025-03-21 23:00 UTC)