Is duplicacy subject to the same attacks as Borg and Restic as reported here?

Support
#1

Is duplicacy subject to the same attacks as Borg and Restic as reported here?
see Attack on content-defined chunking algorithm used by restic · Issue #5291 · restic/restic · GitHub and https://www.daemonology.net/blog/chunking-attacks.pdf

#2

Duplicacy uses CDC with rolling hash by default, but can be configured to use fixed chunking if necessary (which may improve efficiency for some types of data, like disk images)

#3

Is this a confirmation that by default, without changing to fixed chunking, duplicacy is affected by this attack vector?

#4

It isn’t. It’s stating a fact. I’m not qualified, nor interested in doing security audit nor authorized to speak on behalf of acrosync; I’m just another user like yourself.

If you want actual confirmation, you would need to have a security audit done by someone with appropriate credentials. The source is available.

Or wait for developer to chime in in case they have already done it.

#5

Here are my thoughts after reading the paper:

  1. Only attack 4 is feasible, since compression is enabled by default in Duplicacy. And the rolling hash algorithms used by Duplicacy is similar to Borg’s rather than restic’s, making attacks 5 and 6 irrelevant.

  2. Attack 4 assumes a hacker would be able to feed specifically crafted files to the backup client and watch the resulting chunk sizes on the storage server. The goal is to recover the random byte mapping table for calculating the rolling hash. But, if the hacker can already upload arbitrary files to the server, they likely already have the ability to download and decrypt the config file which contains the so-called chunk seed for generating the random byte mapping table, rending this attack pointless.

  3. Take a step back and let us pretend that the hacker can only trick a user to backup arbitrary files. In this case, the hacker would need a lot more data, since Duplicacy uses a much larger rolling hash window that Borg (2M vs 4k). In addition, the PKCS7 padding of up to 256 bytes appended by the encryption step changes the chunk sizes and complicates matters further.

  4. Even if the hacker can successfully recover the table, all they can do now is to confirm the presence of a known file in the backup. But, this will only work for large files, since Duplicacy takes a pack-and-split approach. Beside, the PKCS7 padding adds another layer of ambiguity. Therefore, evidence obtained this way would not be very convincing.

2 Likes