3 ms·

Even if the XOR of the plaintexts doesn’t help an attacker, it still makes the encryption very brittle [...] This paragraph is a little weird. Encryption at th

by tptacek 9mo ago

Even if the XOR of the plaintexts doesn’t help an attacker, it still makes the encryption very brittle [...] This paragraph is a little weird. Encryption at the point where a nonce has been reused isn't so much brittle as it is broken. You've got P1 XOR P2, neither of which are uniform random keystreams. It's highly structured. You don't need a P1 or P2 leak to begin attacking it. I'm sure the libraries are quite bad, but I'd also say that there's nothing wrong with not supporting GCM or (heh) GCM-SIV. Very few libraries do provide a GCM-SIV. I don't love GCM, and CTR+HMAC is a perfectly cromulent composed AE system.

opal_tob 9mo ago
The article wasn't talking specifically about strongMan at that point, and not all data encrypted is highly-structured. For instance, AES keys used to encrypt large files might be protected by a password-derived key to allow password changes without re-encrypting the entire file. Or an ssh key manager might store a bunch of ed25519 secret keys, which are uniform random. The case pointed out in the article-- strongMan-- definitely didn't deal with uniform random data, which is why the encryption was broken, not brittle. But if you DO have a bunch of uniform random keys encrypted using CTR mode with the same key and IV, the XOR of any two of them won't tell you much, because the XOR of random values is random. However, if any of those encrypted keys wind up compromised, it's game over for ALL the keys. Not broken, but definitely brittle. I understand not loving GCM or GCM-SIV; they definitely aren't perfect. I also agree that CTR+HMAC is just fine in a lot of situations, especially if you're careful enough to derive separate HMAC keys and encryption keys. CTR+HMAC also has the advantage of being key-committing, which gives me the warm fuzzies. Still, GCM and GCM-SIV have their use cases, especially in performance-sensitive situations. Given the widespread adoption of AEAD modes, I think failing to include GCM in an AES implementation is an indicator that a library is out of date and ought to be treated with caution.
- tptacek 9mo ago
  I'm sorry, but because you brought it up: what's the attack on a system that derives a single key for AES and HMAC?

by tptacek 9mo ago

opal_tob 9mo ago

The article wasn't talking specifically about strongMan at that point, and not all data encrypted is highly-structured. For instance, AES keys used to encrypt large files might be protected by a password-derived key to allow password changes without re-encrypting the entire file. Or an ssh key manager might store a bunch of ed25519 secret keys, which are uniform random. The case pointed out in the article-- strongMan-- definitely didn't deal with uniform random data, which is why the encryption was broken, not brittle. But if you DO have a bunch of uniform random keys encrypted using CTR mode with the same key and IV, the XOR of any two of them won't tell you much, because the XOR of random values is random. However, if any of those encrypted keys wind up compromised, it's game over for ALL the keys. Not broken, but definitely brittle. I understand not loving GCM or GCM-SIV; they definitely aren't perfect. I also agree that CTR+HMAC is just fine in a lot of situations, especially if you're careful enough to derive separate HMAC keys and encryption keys. CTR+HMAC also has the advantage of being key-committing, which gives me the warm fuzzies. Still, GCM and GCM-SIV have their use cases, especially in performance-sensitive situations. Given the widespread adoption of AEAD modes, I think failing to include GCM in an AES implementation is an indicator that a library is out of date and ought to be treated with caution.

tptacek 9mo ago
I'm sorry, but because you brought it up: what's the attack on a system that derives a single key for AES and HMAC?