If AES just specified that you pick a random IV and prepend it to the cipher text, then users of crypto libraries wouldn't need to know what an IV is. Right?
AES defines a block cipher (128 bits in, 128 bits out) so there is no "before". I think that you are suggesting that default crypto libraries should work at a higher level where the documentation specifies that the resultant encrypted material is going to be, say, one IV length longer than the unencrypted material. ... which is valid I think... Part of the problem here is that the library is doing some stuff, but perhaps not enough. The function has a name that is in one sense too descriptive and in another sense not descriptive enough. The user doesn't know exactly what sort of thing they are getting.
You get what you paid for. Please don't blame, bully or in any way personally attack the authors - they are not obliged to make changes to their (insecure) code that has been provided as-is.
From the post itself, I am not sure if the author had sent a patch or some sort of a pull-request to the affected entities. Namely pyaes and aes-js.
The response might've been different if the author had already given a patch, in somewhat backward-compatible way. This doesn't even have to be a functional patch, could be a simple `@warning: usage of default IV will cause insecure storage` similar annotations on the affected functions.
Another thing to remark (and which might've been off-putting for the authors of these libraries) that the author had used term mistakes in various places. Of course in an ideal world, ego should not or would not matter, but these libraries both seem to be quite stale and possibly the authors are having other $DAYJOB responsibilities. Making it difficult to fix things that they just receive complaints about. (I am also guessing these are quite many...)
Again in relation to the points above, it might've been better to say: Cryptography evolves over time, last years' best-practices get outdated, vulnerabilities being found, replaced with newer best-practices of this year. Same will happen next year too. It's not a deliberate mistake or any type of incompetency issue, this is a matter of ever-evolving field that we know and understand better...
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.
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.
9 comments
[ 2.1 ms ] story [ 27.4 ms ] threadThe response might've been different if the author had already given a patch, in somewhat backward-compatible way. This doesn't even have to be a functional patch, could be a simple `@warning: usage of default IV will cause insecure storage` similar annotations on the affected functions.
Another thing to remark (and which might've been off-putting for the authors of these libraries) that the author had used term mistakes in various places. Of course in an ideal world, ego should not or would not matter, but these libraries both seem to be quite stale and possibly the authors are having other $DAYJOB responsibilities. Making it difficult to fix things that they just receive complaints about. (I am also guessing these are quite many...)
Again in relation to the points above, it might've been better to say: Cryptography evolves over time, last years' best-practices get outdated, vulnerabilities being found, replaced with newer best-practices of this year. Same will happen next year too. It's not a deliberate mistake or any type of incompetency issue, this is a matter of ever-evolving field that we know and understand better...
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.
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.