AES-GCM's Hidden Contract
This series examines AES-GCM, the authenticated-encryption mode widely used to protect data and the context around it. This opening focuses on the rule that is easiest to underestimate: an initialization vector (IV), also called a nonce in this setting, must be unique within the scope of a key. The practical value of that rule is not memorizing a warning; it is learning to see how a small failure in nonce management can travel through GCM's design and become a confidentiality, authenticity, and protocol problem.
The subject is not AES in isolation. AES is the block cipher that supplies the basic transformation. GCM is the mode that arranges AES outputs into a counter stream for encryption and combines a polynomial hash with that stream to authenticate data. A deployment can use a strong AES implementation and still use GCM unsafely if it repeats the wrong value, lets state roll back, or accepts an input domain that the surrounding security argument does not cover.
AES is the ingredient; GCM sets the rules
Authenticated encryption is meant to provide two results at once. It conceals plaintext, and it gives a receiver evidence that the protected inputs were not altered. In GCM, the sender supplies plaintext, additional authenticated data (AAD), and an IV. AAD might be visible protocol context—such as an address, sequence number, or version field—that must be checked even though it is not encrypted. GCM returns ciphertext and an authentication tag. On the receiving side, a matching tag permits the plaintext to be returned; a mismatch produces a failure result instead.
That description already shows why the IV matters. It is not a secret ingredient that the receiver must hide. It identifies the particular invocation and helps establish the internal starting point from which GCM generates its counter blocks and its tag mask. The IV therefore participates in the structure of both halves of the mode. The confidentiality path and the authentication path are different computations, but they are not independent of the same IV-derived starting point.
This is the first correction to a common mental model. “AES is secure” describes the strength of the underlying block cipher under its intended use. It does not prove that a system has supplied GCM with a safe sequence of IVs, kept a key's scope coherent, or recovered its state correctly after a failure. GCM's guarantees are conditional. The mode works inside a contract about how keys and invocation values are used.
The value may be public, but it cannot be casually reused
NIST states the requirement in terms of the combination of key and IV. For a given key, the probability that authenticated encryption is ever invoked with the same IV on two or more distinct sets of input data must be no greater than 2^-32. The point is not that every IV must be secret or impossible for an observer to predict. The point is that the same key-and-IV pair must not be assigned to different messages.
That scope is wider than the place where an IV is generated. Suppose two services share one GCM key. Each service can maintain a counter that is unique inside its own process and still produce the same IV as the other service. A restart can create the same result if a counter returns to an earlier checkpoint. A cloned generator can produce values that look random while repeating the same sequence in two instances. In each case, the local component may appear healthy while the key-wide domain has lost uniqueness.
This is why NIST describes the IV requirement as almost as important as keeping the key secret. A secret key does not rescue two invocations that reuse the same starting conditions. Conversely, a public IV can be safe when the system can demonstrate uniqueness for the life of that key. Fresh keys matter as well: a counter or random generator has to operate inside a key domain that has not itself been accidentally reused.
A normal invocation can be pictured as a chain. The key determines the AES functions and produces the GHASH hash subkey. The IV determines the pre-counter block, usually called J0. GCM starts its counter encryption from J0, while the tag computation folds AAD and ciphertext through GHASH and then applies a mask derived from J0. The receiver repeats the relevant computation and returns plaintext only if the tag agrees.
The diagram's repeated-IV branch is not an assertion that every incident has the same immediate outcome. It marks the point where GCM's assumptions stop supporting its intended security properties. To understand the difference between a warning and a failure mechanism, it helps to follow each path separately.
What repetition does to confidentiality
GCM's encryption component is a variant of counter mode. AES is applied to successive counter blocks, and each resulting block is XORed with the corresponding plaintext. If the same key and IV are used again, the same J0 and corresponding counter blocks are produced. The same keystream is therefore applied to both messages.
For matching portions of two ciphertexts, the relationship is simple: ciphertext one XOR ciphertext two equals plaintext one XOR plaintext two. The keystream cancels. This does not automatically reveal every byte of either message, but it changes the problem from recovering an unknown plaintext under an unknown stream to recovering one plaintext when information about the other is available. A known header, a predictable record format, or a chosen message can expose stream material for the corresponding positions.
Counter-mode encryption is also malleable. Flipping a bit in a ciphertext flips the corresponding bit in the decrypted plaintext. Normally, GCM's authentication tag is meant to make that altered ciphertext unacceptable. A repeated IV attacks the conditions that make the tag dependable, so the confidentiality problem cannot be isolated from the integrity problem.
Why the tag can fail too
The authentication side of GCM is not a generic checksum. Its GHASH function processes AAD, ciphertext, padding, and encoded lengths using a secret hash subkey, H. NIST specifies H as the result of applying the block cipher under the GCM key to the all-zero block. The resulting GHASH value is then combined with an encryption output associated with J0 to form the tag.
When an IV repeats under a key, the J0-based tag mask repeats as well. The observed tags and the corresponding authenticated data can then give an adversary relationships involving H. NIST's warning is deliberately calibrated: if IVs repeat, an adversary is likely to determine the hash subkey and can then construct substitute ciphertext and AAD with a valid tag. In that situation, the decryption routine may have no way to detect the reuse, and authentication assurance is essentially lost.
The exact transcript and adversary capability still matter. A repeated IV is not a proof that every plaintext has already been recovered or that every possible forgery succeeds without further observations. But it is a critical security event, not a small reduction in a security estimate. Once the authentication boundary is no longer trustworthy, the malleability that counter mode always possessed can become an avenue for controlled changes to accepted plaintext.
Three failures that should not be conflated
Ordinary nonce reuse is one failure class: a valid-looking IV is assigned again within a key domain. A different case appears in a 2026 note about an ISO/IEC formulation of GCM and GMAC. The note reports that this formulation permits a zero-length nonce. Under the attack described, the empty input makes the IV-derived starting value degenerate, and a single observed or chosen encryption query can yield an equation in H; solving it enables the stated forgery attacks. The note explicitly contrasts this with the NIST version, which requires the nonce to contain at least one bit.
That distinction is part of the result. The note is evidence about a particular standard boundary and its stated attack model, not evidence that every NIST-compliant GCM implementation accepts an empty nonce. No conclusion about a specific library follows without evidence that the library accepts that input and exposes the required query. The broader lesson is still important: the values an API permits are part of the security contract, not an afterthought to the cryptographic formula.
Replay is a third, separate problem. A message can have a valid GCM tag and still be an old message copied by an adversary. GCM authenticates the supplied tuple; it does not inherently decide whether that tuple is fresh in the surrounding protocol. Sequence numbers, timestamps, duplicate detection, and ordering rules may be needed in AAD or in the receiver's state. A valid tag is evidence of integrity under the key, not a universal statement about time, origin, or authorization.
Why nonce discipline belongs to the whole system
The rule becomes difficult precisely where cryptography meets operations. NIST gives two broad ways to construct IVs. A deterministic construction divides the value into a fixed field that identifies a device or context and an invocation field that advances for distinct inputs. An RBG-based construction relies on a sufficiently long random field and independent generator instances, together with limits on total invocations. Both approaches can work; neither permits a system to ignore key scope, capacity, or recovery.
The familiar recommendation to use a 96-bit IV is useful for interoperability, efficiency, and simplicity. It is not a substitute for uniqueness. Nor can a longer tag repair a repeated IV, because tag length addresses guessing and usage pressure while reuse changes the internal values on which authentication depends. Similarly, replay tracking solves freshness at the protocol boundary; it does not restore the security of an encryption-side nonce that has already been reused.
The operational question is therefore not merely “does this function generate a nonce?” It is “who owns the nonce state for this key, what prevents two contexts from sharing it, what survives a restart, and what happens when uniqueness cannot be proved?” Key establishment, deployment configuration, power-loss recovery, generator independence, invocation limits, and key retirement all participate in the answer. If a module cannot recover without repeating an IV, NIST's guidance points toward a failure state until a fresh key can be established.
AES-GCM fails when nonce discipline fails because the nonce is one of the mode's structural inputs. Reuse can make ciphertexts reveal relationships, can undermine the tag's secret algebra, and can turn a valid-looking message into an accepted forgery. An over-permissive edge case can do something similar by changing the starting point before any accidental collision occurs. The next step is to look closely at one normal GCM invocation—how J0, the counter stream, GHASH, and the tag fit together—so that the contract can be checked against the mechanism rather than remembered as a slogan.