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.
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.