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

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.