Too bad, because the blog post illustrates some limitations with the construction that are interesting to know, like the problem with using the same authentication key for every key instead of key/nonce pair, or the fact that AES-GCM is not "message committing" - a TIL for me.
It's also very pragmatic in the end: "Don’t throw AES-GCM out just because of my opinions. It’s very likely the best option you have."
Doesn't ChaChaPoly have a similar sudden death property on nonce reuse? If I reuse a nonce, I can know the Poly1305 key which then allows me to forge endless messages with the same nonce, right?
If the implementation doesn't detect this somehow, I can inject traffic forever, right?
Misusing those primitives can kill all guarantees, of course, the amount of kill dependent on the amount of misuse. Using non random keys will kill even more.
It's about ease of correct implementation, use, and what kind of degradation happens if a side-channel leaks a specific item:
It seems that w/AES (within the AES-GCM construction) can leak a key that is useful against all other uses of the original AES key that was used to derive the authentication key.
ChaPoly uses a construction where all crypto operations for a message exchange use a key which if leaked, cannot be reused to attack so many other message exchanges as well, because it incorporates both main key and nonce in the derivation.
4 comments
[ 3.4 ms ] story [ 23.3 ms ] threadToo bad, because the blog post illustrates some limitations with the construction that are interesting to know, like the problem with using the same authentication key for every key instead of key/nonce pair, or the fact that AES-GCM is not "message committing" - a TIL for me.
It's also very pragmatic in the end: "Don’t throw AES-GCM out just because of my opinions. It’s very likely the best option you have."
If the implementation doesn't detect this somehow, I can inject traffic forever, right?
Misusing those primitives can kill all guarantees, of course, the amount of kill dependent on the amount of misuse. Using non random keys will kill even more.
It's about ease of correct implementation, use, and what kind of degradation happens if a side-channel leaks a specific item:
It seems that w/AES (within the AES-GCM construction) can leak a key that is useful against all other uses of the original AES key that was used to derive the authentication key.
ChaPoly uses a construction where all crypto operations for a message exchange use a key which if leaked, cannot be reused to attack so many other message exchanges as well, because it incorporates both main key and nonce in the derivation.