
Why AES-GCM Sucks - eurg
https://soatok.blog/2020/05/13/why-aes-gcm-sucks/
======
eurg
HT to Filippo
([https://twitter.com/FiloSottile/status/1260598284395126786](https://twitter.com/FiloSottile/status/1260598284395126786)).
Another submission 10 hours ago didn't catch
([https://news.ycombinator.com/item?id=23165258](https://news.ycombinator.com/item?id=23165258)).

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

------
api
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?

~~~
eurg
(beware, I'm a dog)

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.

~~~
api
Ahh I see the difference... total forgery capability vs. forgery capability
only with the same nonce (which can be detected).

