Comment by aborsy | Hacker News Reader

Comment by aborsy | Hacker News Reader

Parent Full thread

I have a question about Borg’s encryption. It’s stated [0] that if multiple clients update same repository, the server might be able to decrypt data.

Why is that the case and wouldn’t that make the encryption very weak? Simultaneous updates happen quite often.

Would restic have the same problem?

——————-

Update: The issue happens because Borg uses AES in the CTR mode (not AES GCM) and two clients could provide the same nonce. The server could then recover the plaintext from two cipher texts. This is the famous nonce reuse problem.

So Borg developers are not using established primitives for this use case. Also, I am not comfortable with the OpenSSL even though it’s got better since 2015. The libssl code base is a mess and buggy. On the other hand using the low level libcrypto library would expose developers to the crypto primitives with possibilities for errors for people not expert in cryptography.

Borg should consider ChaCha-Poly135 as in rclone (or at least AES-GCM).

[0]https://borgbackup.readthedocs.io/en/stable/internals/securi...

> Why is that the case [...]?

This is explained in the "Encryption" section: https://borgbackup.readthedocs.io/en/stable/internals/securi...

The important part is the part about avoiding re-use of the AES CTR value.

> Simultaneous updates happen quite often.

Personally I created a dedicated borg repository per machine I want to backup, because that avoids sharing passphrases across machines. This comes with the drawback that I cannot deduplicate across machines, but that is acceptable to me, because the data is mostly unique-ish anyway. I only backup the user data, not everything (e.g. /bin/).

Yes, thanks!

I meanwhile read about it and updated my comment.

Would it be practical to rclone the output of the Borg into a cloud service using an rclone crypt remote? In my experience, rclone’s crypt remote is sluggish, even locally. I am not sure how the mount would work.

It’s unfortunate that we have to get the dedup from Borg and the encryption from rclone!

I never used rclone, but I can tell you that a borg repository basically is a number of encrypted blobs of up to 500 MB size that are never going to be modified again (only created and deleted) + a few small metadata files. It rsyncs quite well.

I can confirm that cloning a local Borg repository to a cloud system works. One of my systems uses Borg to make a local backup. Next, B2's command line tool synchronizes the local Borg repository to B2.

Reply on news.ycombinator.com