How AES-GCM Uses a Nonce
AES-GCM's nonce is easiest to understand by following one complete invocation rather than treating it as a random-looking field attached to a ciphertext. The key, IV, plaintext, and associated data enter one connected mechanism: the IV establishes a starting point for encryption and for the tag, while the key supplies both AES outputs and the secret value used by GHASH. Tracing that path explains what a receiver is checking and lets us predict which internal values repeat when a key and IV repeat.
The notation is compact, but the roles are not interchangeable. The plaintext is the secret data. Additional authenticated data, or AAD, is visible data that must still be protected against alteration. The IV is a nonce-like value identifying the invocation. The ciphertext conceals the plaintext; the authentication tag gives the receiver a way to reject altered inputs. GCM's security depends on these pieces being used together under the conditions the mode specifies.
A useful example is a protected network record. The body of the record may be plaintext, while its destination, port, protocol version, or sequence information remains visible so the network can route or classify it. Those visible fields can be supplied as AAD. The receiver then checks them as part of the same authenticated computation instead of assuming that only the encrypted body needs protection. This is the practical reason to learn the flow: the security boundary includes data that an application may never intend to hide.
The IV establishes the starting point
Consider an encryption call with a key K, an IV, plaintext P, and AAD A. GCM first derives a hash subkey, conventionally written as H, by applying AES under K to the all-zero 128-bit block: H = AES_K(0^128). This is not a second application key that a caller supplies. It is an internal value used by GHASH, and it must remain within GCM's protected computation.
GCM then turns the IV into a 128-bit pre-counter block called J0. When the IV is 96 bits long—the length NIST recommends for interoperability, efficiency, and simplicity—GCM forms J0 by appending a fixed 32-bit suffix. For another supported IV length, GCM pads and length-encodes the IV and processes that material through GHASH to derive J0. The two paths are different, but their purpose is the same: establish the starting block from which this invocation's counter sequence begins.
The distinction between H and J0 matters. H comes from the key and controls the behavior of the GHASH function. J0 comes from the IV, using H when the IV is not on the direct 96-bit path, and anchors the counter and tag computations. A repeated key means the same H; a repeated key-and-IV combination means the same relevant starting conditions for both paths. Keeping these dependencies separate makes later failure analysis much easier. It also prevents a common mistake: treating every value that appears in the formula as if it were an input the application should generate or store itself.
From J0, GCM increments a specified 32-bit portion to obtain the first counter block for plaintext encryption. It applies AES to each successive counter block, then XORs the resulting output with the corresponding plaintext block. This is the GCTR part of GCM. In a simplified notation, a ciphertext block is C_i = P_i XOR AES_K(CB_i), where CB_i is the counter block for that position. The final plaintext fragment can be shorter than a full block; GCTR truncates the AES output to the fragment's length before XORing it.
The counter sequence is stateful inside the invocation even though the caller normally sees only the final ciphertext. The rightmost 32 bits of each counter block are incremented modulo their range, while the rest of the block stays fixed for that sequence. Each counter block produces one AES output, and each output is consumed once for the corresponding portion of plaintext. This explains both the efficiency and the danger of counter mode: encryption does not need AES's inverse direction, but it does need each key-specific counter input to be used in the right way.
The counter blocks are not the plaintext, ciphertext, or IV itself. They are internal inputs to AES. The IV's job is to ensure that the sequence of counter blocks used under a given key is not repeated for a different input set. When that condition holds, the AES outputs act as a keystream specific to this invocation. When it does not, the counter mode has been asked to reuse the same stream, which is the first major failure examined later.
This also explains why a nonce does not need to be secret. The receiver needs the IV to reproduce J0 and the counter sequence, so the IV commonly travels with the ciphertext. Hiding it would not solve the central problem. What matters is that the same key does not use the same IV again for different data. A public value with a reliable uniqueness guarantee is safer than a secret-looking value whose state can be reset or duplicated.
For a 96-bit IV, the direct construction is simple and common. That recommendation should not be mistaken for a complete safety rule. Other supported IV lengths can be processed by the specified GHASH-based construction, and a 96-bit value can still be repeated. Length affects how GCM derives J0; uniqueness determines whether the resulting internal stream can safely be used for a new message.
The tag binds context and data
Encryption alone is not the whole invocation. GCM must also make a tag that covers the data the receiver is supposed to trust. GHASH takes the AAD and ciphertext, pads them to the block boundary as needed, and includes their lengths before repeatedly combining them with H in a binary finite field. The result is a single 128-bit authentication value. This is why changing a visible header can invalidate a tag even though the header was never encrypted.
The running calculation is worth understanding at a high level. It begins at a zero value. For each encoded block, GHASH combines that block with the running value and multiplies the result by H. The multiplication is defined in a finite field, so this is not ordinary integer arithmetic and it is not a conventional cryptographic hash exposed for general use. The same secret H shapes the entire authentication calculation, which is why information about it is so sensitive.
AAD gives GCM a way to protect protocol context without hiding it. Addresses, ports, sequence information, version fields, and similar values may be needed by the network or application before decryption. If they are included as AAD, a receiver can check that the context presented with the ciphertext is the context that was authenticated. If they are left outside the authenticated inputs, an attacker may be able to alter how the application interprets otherwise valid encrypted bytes. AAD is therefore not an optional comment on the ciphertext; it is another input to the integrity decision.
The lengths of AAD and ciphertext are included in the final GHASH input. That detail gives the authentication calculation an unambiguous ending and keeps differently shaped inputs from being treated as the same sequence merely because their visible blocks happen to line up. It also explains why a tag is tied to the exact combination of context and encrypted data. Reusing a tag with a different AAD or ciphertext is not supposed to work, because the GHASH input has changed.
The GHASH result is not sent as a bare hash. GCM uses the J0-associated path to mask it and then takes the configured number of leading bits as the authentication tag. At a high level, the tag has the form T = MSB_t(GCTR_K(J0, GHASH_H(A, C, lengths))). The notation hides padding and exact block encoding, but it exposes the important dependency: the tag is a function of the key, the IV-derived starting point, the AAD, and the ciphertext.
That dependency prevents a tag from being a generic checksum that can be copied from one message to another. A receiver recomputes the value from the supplied IV, AAD, and ciphertext. If the result matches the received tag, the authenticated-decryption function may return the corresponding plaintext. If it does not match, the function returns a failure indication instead. Implementations may verify the tag before computing or releasing plaintext; the specified behavior is that unauthenticated input is not accepted as a successful decryption.
The encryption path can therefore be read as two coordinated branches. One branch starts with J0, increments the counter, and uses AES outputs to turn P into C. The other branch feeds A and C into GHASH, then uses the J0-based mask to turn the authentication value into T. The branches meet at the final output, but they should not be mentally merged. GCTR provides the confidentiality transformation; GHASH and the tag provide authentication. The IV helps establish the conditions for both.
The receiver's successful result means that the supplied ciphertext, AAD, IV, and tag are consistent with the key and the GCM computation, subject to the possibility of forgery inherent in any tag mechanism. It does not, by itself, mean that the message is new. An old, correctly formed tuple can still be replayed unless the surrounding protocol tracks freshness. Authentication and replay protection meet in system design, but they are different properties.
What repeats when the key and IV repeat
The mechanism now makes the nonce rule concrete. If the same key is used, the GHASH subkey H is the same. If the same IV is used with that key, GCM derives the same J0. The counter path therefore generates the same sequence of AES inputs for corresponding positions, and the tag path uses the same J0-based mask. Repetition is not confined to a field that an attacker can see; it reuses internal structure.
On the encryption side, two ciphertext blocks created with the same counter output satisfy C_1 XOR C_2 = P_1 XOR P_2. The AES output disappears when the ciphertexts are XORed. That relationship does not automatically reveal both plaintexts, but known or predictable content in one message can expose the corresponding stream and make the other message easier to recover. The same starting conditions also leave the counter-mode ciphertext malleable: changing a ciphertext bit changes the corresponding plaintext bit if the altered input is accepted.
On the authentication side, the repeated J0-based mask creates relationships among tags whose GHASH inputs differ. Those relationships can expose information about H. The key itself has not been recovered, and AES has not been inverted; the problem is that GCM's authentication algebra has been given repeated conditions it was designed to avoid. NIST warns that repeated IVs can make recovery of the hash subkey likely and can enable an adversary to construct substitute ciphertext and AAD with a valid tag.
This is the hidden coupling behind the headline failure. The IV is used to organize counter encryption and to mask authentication. A system that treats it as harmless metadata can accidentally reuse both. A system that watches only whether encryption succeeds will see no local error: AES still produces outputs, GHASH still produces a value, and the receiver may still accept a tag. The failure is in the relationship between invocations, not necessarily in a single call's syntax.
The correct question is therefore not merely “what is the IV length?” It is “under which key can this IV appear, who controls that domain, and what evidence shows that a different input set will not receive it again?” Once the IV is understood as the starting condition for both GCTR and tag formation, the consequences of reusing it are no longer mysterious. The next problem is to follow those consequences from a repeated counter stream to the possible loss of authentication.