Overview
This series explains why AES-GCM's security depends on a unique IV for every distinct input set within a key domain, not on AES strength or a nonce's secrecy. It traces how the IV establishes J0 for both counter encryption and tag masking, then follows reuse from plaintext-XOR leakage to conditional GHASH-subkey recovery and forgery risk. It distinguishes replay, tag guessing, and an empty-nonce attack reported for an ISO/IEC formulation from ordinary reuse and from NIST's stated minimum length. Finally, it compares deterministic and RBG-based constructions, key-wide limits, recovery, and fail-closed decisions. The result is a system-level way to assess evidence without overstating conditional impacts.
Learning outcomes
- A repeated IV under one key reuses GCM's counter inputs, exposing XOR relationships between corresponding plaintexts.
- The same repeat also reuses the tag mask; GHASH-subkey recovery and valid forgery become serious conditional risks.
- An empty-nonce attack in the 2026 note targets an ISO/IEC formulation that permits it; NIST's stated minimum excludes that exact case.
- Safe nonce construction requires key-wide ownership, capacity, generator or counter state, recovery, and a defined response when uniqueness is uncertain.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
Why does AES-GCM require nonce uniqueness under a key?
AES-GCM requires each distinct input set under a key to receive a different IV because the IV fixes the counter stream and helps mask the authentication value. Reuse can expose plaintext relationships and may undermine tag verification.
What can happen if an AES-GCM nonce repeats?
A repeated nonce under the same key reuses the keystream, so XORing ciphertexts reveals the XOR of corresponding plaintexts; with further transcript conditions, GHASH-subkey recovery can enable valid forgeries.
Is an empty AES-GCM nonce the same as nonce reuse?
No. Empty-nonce risk is an input-domain issue reported for an ISO/IEC formulation that permits zero length; ordinary reuse is a collision across distinct invocations. NIST's stated minimum excludes the exact empty-nonce case.
How should a system keep AES-GCM nonces unique?
A system should choose a key-scoped deterministic or RBG-based construction, assign ownership, preserve state and capacity, count shared-key use, and fail closed or establish a fresh key when recovery cannot prove uniqueness.