Nonce Discipline Is the Security Contract

This series has followed AES-GCM from one normal invocation to the failures that appear when its nonce rules are weakened. The final judgment is that AES-GCM does not fail because AES is weak. It fails when a deployment violates the mode's contract that an IV or nonce remain unique within a key domain, or when the permitted input domain and recovery behavior do not support that promise. The consequences then propagate through both halves of GCM: GCTR can reuse a keystream, while GHASH can lose the secrecy on which authentication depends.

That answer is technical, but it is also operational. A nonce is not just a field that an API accepts and a message carries. It is a starting condition for internal AES inputs and for the tag calculation. A key is not just a secret held by one process. It defines the scope across which IV uniqueness, generator independence, data volume, and recovery state must be considered. The security of an AES-GCM deployment is the result of those relationships holding together over time.

The failure is a broken contract, not a broken cipher

AES supplies the block-cipher transformation. GCM uses AES in counter mode to protect plaintext and uses GHASH, shaped by the secret subkey H, to authenticate AAD and ciphertext. The IV produces the pre-counter block J0, which anchors the counter sequence and the mask applied to the authentication value. Authenticated decryption recomputes the tag and returns plaintext only when the supplied inputs pass that check.

That structure gives the IV two kinds of leverage. It determines which AES inputs are used to form the confidentiality stream, and it helps determine the value that masks GHASH for the tag. If the same key and IV are used for distinct input sets, the corresponding counter inputs repeat. Ciphertexts then reveal the XOR of their corresponding plaintexts because the shared keystream cancels. Known or predictable content in one message can expose the stream for matching positions in another.

The authentication consequence follows from the same repeated starting conditions but is not identical to the confidentiality consequence. The same key gives the same GHASH subkey. The same IV gives the same J0-based tag mask. Tags for different AAD and ciphertext can therefore reveal relationships involving H. NIST warns that repeated IVs may allow an adversary to determine that subkey and then calculate valid tags for substituted ciphertext and AAD. If the forged input is accepted, counter-mode malleability can turn the authentication failure into controlled changes to accepted plaintext.

The escalation has to be stated with the right confidence. Repeated key-and-IV use directly creates the counter-stream relationship. It does not automatically expose every plaintext byte, because recovery depends on overlap, known content, message lengths, and the adversary's observations. NIST describes H recovery and forgery as likely or possible consequences of repeated IVs rather than as a claim that every collision produces a universal forgery without further conditions. The severity is still enough to treat a confirmed repeat as a critical failure of the affected key domain.

This is why a stronger AES key or a longer authentication tag cannot repair the original mistake. AES's security is not a substitute for unique counter inputs. A tag parameter addresses guessing and usage pressure; it does not make a repeated J0-based mask independent. A receiver-side replay check addresses whether an old valid tuple is timely; it does not restore a key whose encryption side has reused an IV. Each control is meaningful only when its boundary is kept distinct.

The most accurate short answer to the title is therefore: nonce discipline is the condition that keeps GCM's counter and authentication computations from sharing internal state across distinct messages under one key. Once that condition fails, the mode can reveal plaintext relationships and may lose the ability to distinguish a forged message from a legitimate one. The primitive remains recognizable; the security contract around its use no longer holds.

How to judge a suspected failure

A useful investigation begins with the key domain, not with the text of one nonce. NIST defines the uniqueness requirement across all instances of authenticated encryption using a given key. The probability that the same IV and key are used on two or more distinct input sets must be no greater than 2^-32. That scope includes every device, service, process, session, and recovery path that can invoke GCM with the key.

Suppose an audit finds that an IV value appears twice. The first question is whether the two records were protected under the same key. If they were not, the repeated text does not establish the same key-specific counter condition.