Archivecryptography
AEAD Nonce Reuse Is Catastrophic, Not Unlucky
Reusing a nonce under the same key leaks plaintext XOR and, for GCM, the authentication key itself.
- Published
- Reading time
- 1 min read
AEAD modes (AES-GCM, ChaCha20-Poly1305) promise confidentiality and integrity in one pass. That promise depends on a unique nonce per key. Reuse it and the mode fails in ways that are not subtle.
What leaks
For a stream-cipher-based AEAD, two messages encrypted with the same key and nonce produce:
C1 XOR C2 = P1 XOR P2
The keystream cancels. Any known or guessable plaintext recovers the other. With GCM, nonce reuse also allows recovery of the GHASH authentication key H, after which an attacker can forge messages at will.
Why it happens anyway
- Counters reset after a process restart and are not persisted.
- Random 96-bit nonces are safe only up to about 2^32 messages per key (birthday bound), and systems exceed that.
- Keys are shared across replicas that each start a counter at zero.
The fixes
- Use a deterministic construction such as XChaCha20-Poly1305 (192-bit nonce) for random nonces.
- Derive a per-message key with HKDF from a random salt, then use a constant nonce.
- Partition the nonce space by writer ID and persist counters atomically.
Takeaway: treat nonce uniqueness as a hard invariant with a monitored budget; the failure is total, not graceful.