The crypto in Borg is bad. Even has its own page in the docs about how bad it really is. The tl;dr is "there is one AES key per repository and we use this with AES-CTR and trust the remote server to not fiddle with the counter".
Last time I checked there was still no work being done on improving performance. Multithreading has been on the agenda for years and will probably never come, much like improved crypto.
The AES/MAC composition itself in Borg is done correctly, the problem is the way Borg uses the composition: with a single AES/MAC key for the entire repository which a) never changes b) cannot be changed and c) IVs/nonces used with those keys are primarily tracked by server-side, i.e. untrusted, state. This means that using multiple clients with one repository is never secure in Borg.
> It would be much better to use a dedicated authenticated encryption scheme, like AES-GCM.
Actually, in the scheme Borg uses, which is vulnerable to repeating IVs/nonces, using AES-GCM or Chapoly (or indeed any Wegman-Carter authenticator) would not only delete confidentiality, but also authenticity, i.e. it wouldn't just disclose plaintext to the attacker, but allow an attacker to potentially change your backups [1].
> That being said, I don't know if I'd call Borg's encryption "weak." It's not ideal, and I don't personally trust it. But it's not like they're using AES in ECB mode or Mac-Then-Encrypt CBC mode.
I'm calling it out as weak because it is an insufficient and poor design. If you say encrypted today it should better be up to me throwing my encrypted data up on a random cloud server and be sure that it's actually encrypted. This is not the case with Borg; partial credit for getting some aspects of the construction right (e.g. EtM, separate keys, properly salted master key encryption key derivation) isn't worth much when it fails to provide confidentiality in not-at-all unreasonable, practical usage.
[1] Probably not because by necessity Borg uses a separate HMAC over the plaintext for deduplication, and the manifest has a third layer of HMACing due to protocol issues, so it should be impossible to just change stuff even if you break the ciphertext authentication.
I would also like to know more about why you think Borg's encryption is questionable. I'm not familiar with Borg's internals, but there's not much one could do wrong here, as it should just be simple symmetric encryption. Does it not use a strong cipher? Is the cipher used incorrectly? Is the key derivation method weak?
Does anybody take the encryption support in attic/borg seriously? They seem to be implementing their own AE construction. Maybe they did it right, but it makes be a bit uneasy. While they're at it wrapping OpenSSL, I don't know why they wouldn't use one of OpenSSL's AEAD EVPs...
The problem with AES isn't performance. Sites have been using AES ciphersuites in TLS for many years.
The problem is that the widely-deployed AES ciphersuite, like the ciphersuites for triple DES and IDEA, uses a construction from the '90s that is itself insecure. It's based on CBC mode (which is fine) in a MAC-then-encrypt configuration (which is not), which lead to the Lucky 13 attack, and which until TLS 1.1 didn't properly set up the IVs for each record, which lead to BEAST.
No major site used RC4 because it was more performant. They used it as a workaround to Lucky 13 and BEAST, because they couldn't count on browsers fixing those problems fast enough.
> I suspect the encryption here is broken due to CTR mode AES with IV reuse. Try printing out the IV in the segment function. It's the same value across sessions.
I think it's a little more subtle. IVs are being generated deterministically, but keys are generated randomly per session. The nonce uniqueness requirement in CTR is per key. That said, there doesn't seem like there's any guard against replays of messages, or dropping of messages, or altering of messages.
> Another thing I see is that AES-CTR is being used alone, so there is no integrity guarantee for the messages.
Indeed. They seem to try and do some integrity checking at the start of a session by sending an encrypted all-zero block, as a way of verifying that the client has the correct key (stored in the url hash). From what I can tell, there's no integrity checking on any subsequent messages.
Also the KDF parameters for Argon2id seem way underpowered (19MB RAM, 1 lane, should probably be using at least 2GB RAM in a KDF setting)
It's an AES-based mode, so it only has the AES message block (and, implicitly, the key) to work with, and some of the bits in the message block need to hold the CTR counter. The problem is that leaves an uncomfortably low margin of random bits.
Seems to be the case, with non-random nonces... If I read the documentation of the used library correctly, it starts the counter always with 1 by default. Game over?
Well, there are other problems (even requiring encryption at all means some low-power clients can't use it because they lack the processing power), but X.509/WebPKI is the main one, followed by ciphersuite proliferation requiring dozens of times as much audited cryptographic code.
This project has so many cryptographic wrong answers, I don't know where to begin.
Glaring problems:
- The same unchanging aes key is shared between all nodes on a network. Compromise one, compromise all. Additionally a bad node can impersonate any other node.
- The 96 bit nonce is derived randomly and there is no rekeying which means sending more than 2^32 messages will leak your (static, unchanging) key to the world. That's 2^32 total between all clients on a network. Hope everyone is manually updating their keys!
- Default unchanging password of `hello-world` is set. Everyone remembers to change that environment variable right?
- The KDF is md5, which means attackers can brute force guess the key incredibly fast.
- There's no perfect forward secrecy (aging out of old keys).
Amazingly, this is still better than their last version, which used AES-CBC and used the same value for both the key and the IV (which is transmitted over the network).
In general, I would agree, but wouldn't you be using the slow public key crypto only once to encrypt a symmetric key you've previously generated to destroy the files?
I would assume that symmetric encryption still is more than fast enough to be scary, especially with current CPUs and native AES support.
I would think this is more laziness/incompetence of the developer than an optimisation (even more so as in the OP's article, the file were properly(-ish - I would have used AES over RC4) encrypted, but the symmetric key was attached to the file).
Well, in my amateurish opinion - there was nothing wrong with the existing AES encryption implementation. But they also had a key derivation function based on running many iterations of AES, which was weird and non-standard, I mean it seemed like it would work, but it's not proven in the cryptographic community. Now they've switched to Argon2 which is a very well reviewed KDF and I have a lot more faith in that.
I think it's interesting that there are attacks against AES-256 that don't work against AES-128. Apparently, "the key schedule for 256-bit version is pretty lousy." Surprising, to me at least.
It's not really a problem so much as it's not doing what they think it's doing. 256-bit block-size Rijndael might even be better than 128-bit (AES). I don't know.
AES is not significantly slower than a salted hash and so this does not overcome the problem of JtR style attacks. See for example: http://www.cryptopp.com/benchmarks.html
Interesting idea. But I question the overall security philosophy of a project that includes so many suspected to be weak, known to be weak, or provably weak algorithms, e.g., MD2, MD4, MD5, SHA-1, and DES.
If this is for serious security, DROP THOSE NOW. Sorry to scream, but the sooner we stop using them, the better.
I also wouldn't spend a lot of time on AES 256, given some of the recently described weaknesses that reduce it to by many bits of strength. Better to work on CAST5, e.g.
Better yet, work on the RNG. Make sure the RNG is cryptographically secure. Without a cryptographically secure RNG, all the key derivation algorithms are pretty much useless.
https://borgbackup.readthedocs.io/en/stable/internals/securi...
Last time I checked there was still no work being done on improving performance. Multithreading has been on the agenda for years and will probably never come, much like improved crypto.
reply