What GCM Leaks When a Nonce Repeats
The important question in AES-GCM is not whether a repeated nonce looks suspicious; it is what internal work the repeat causes the mode to do again. This explanation diagnoses that failure in two stages. First, the same key and IV recreate the counter stream and expose relationships between plaintexts. Then the same IV also recreates the tag mask, creating conditions under which GHASH's secret value may be exposed and valid forgeries may become possible. The distinction matters because not every consequence has the same certainty or requires the same evidence.
A nonce repeat means the same IV has been used for distinct input data under one key. The key-and-IV combination is the relevant unit. Repeating a value under a genuinely different key is a different situation, although changing keys safely is itself a key-management responsibility. The analysis below assumes the repeated key-and-IV condition described by NIST and keeps practical attack claims conditional on the observations available to an adversary.
The first failure: one keystream serves two messages
GCM's confidentiality path is a form of counter-mode encryption. The IV produces the pre-counter block J0; GCM increments part of that block to create successive counter blocks; AES turns each counter block into an output; and GCM XORs that output with the corresponding plaintext. The AES output is often called the keystream because it is the stream of bits mixed with the message.
If the same key and IV are used again, the same J0 is produced and the same corresponding counter blocks are fed to AES. The block cipher is still behaving as designed. It is being asked the same question with the same key, so it returns the same answer. The second plaintext is XORed with the same keystream that protected the first.
That repetition creates a direct relationship between the ciphertexts. For corresponding blocks, C_1 XOR C_2 = P_1 XOR P_2. The keystream cancels because it appears once in each ciphertext. This is not a claim that an observer can instantly read both messages. It is a claim that the observer no longer faces two independent unknown plaintexts. Information about one plaintext becomes information about the other.
The algebra also shows why one known message can matter. If an observer knows a portion of P_1, the corresponding portion of the first ciphertext reveals the keystream used there. Applying that stream portion to the matching part of C_2 reveals the corresponding part of P_2. The source material does not require the messages to be identical; it requires overlap in counter positions and enough knowledge about one side to make the relationship useful.
Imagine two records with the same repeated IV. If the format of one record includes a known header, or if part of its content is predictable, the observer can use that known portion to infer the keystream for the matching positions. The inferred stream can then be combined with the other ciphertext to recover the corresponding part of its plaintext. If the messages overlap in structure or contain repeated patterns, the XOR relationship can reveal more. If they have different lengths or little predictable content, the immediate disclosure may be smaller.
This qualification is important. The construction gives the leakage relationship directly, but the amount of plaintext recovered depends on overlap, known or guessable content, lengths, and what the adversary can observe. A nonce repeat does not mean that every byte of every message is automatically exposed. It means that the confidentiality guarantee has been replaced by a relationship an attacker can analyze.
The requirement is about distinct input sets. If an identical ciphertext, AAD, IV, and tag is presented again, the immediate concern may be replay rather than the two-plaintext XOR relation. If the IV is reused with a different plaintext, different AAD, or another distinct input set, the counter-stream analysis applies directly. This is one reason an incident record must preserve the key scope and the associated inputs instead of reporting only that “the nonce appeared twice.”
The failure does not require reversing AES or finding the secret key. AES is intended to make its outputs unpredictable to someone without the key, but counter mode relies on never reusing the same key-specific counter inputs for distinct data. Once the inputs repeat, the security argument about independent keystreams no longer applies. The mode's failure is a misuse of a sound primitive, not evidence that the primitive has been cryptanalytically broken.
Malleability makes the confidentiality problem an integrity problem
Counter-mode ciphertext has another property: it is malleable. If an attacker flips a bit in the ciphertext, the corresponding bit in the decrypted plaintext flips as well. The attacker does not need to understand the entire plaintext to make a controlled change when the desired change is known. With an original plaintext-ciphertext relationship, a same-length target plaintext can be represented by changing the ciphertext by the difference between the original and target plaintexts.
In an unauthenticated counter mode, that property is already a serious integrity weakness. GCM is designed to add a tag so that a receiver rejects the modified ciphertext. A correctly functioning tag check should turn a ciphertext alteration into a failure rather than an accepted plaintext. The repeated-IV problem becomes more severe because it attacks the conditions under which that check provides assurance.
It is useful to separate two steps. The first is the malleability inherent in the counter transformation: a ciphertext change maps to a corresponding plaintext change. The second is whether the altered ciphertext carries a tag that the receiver will accept. A repeat does not make those steps identical, but it can provide the information needed to move from the first to the second. That is why NIST describes confidentiality and authentication as linked consequences of IV reuse.
The receiver may continue to perform every algorithmic step without raising a special “nonce was reused” error. It can decrypt the ciphertext, recompute a tag, and compare values. If an adversary has obtained enough information to produce a valid substitute tag, the receiver sees a syntactically normal authenticated-decryption input. The system's visible failure may therefore appear only as an accepted message with altered meaning.
The two branches in the diagram share their trigger but not their immediate evidence. The counter branch follows from repeating the key-specific counter inputs. The authentication branch requires reasoning about GHASH, the tag mask, and the adversary's transcript. Keeping those branches separate prevents a diagnosis from jumping from “a collision occurred” to “every message can now be forged” without accounting for the conditions in between.
The second failure: the tag exposes structure about GHASH
GCM's tag is built from more than the ciphertext. GHASH processes AAD, ciphertext, and their encoded lengths with the secret hash subkey H. The GHASH result is then combined with an AES output associated with J0, and the result is truncated to the configured tag length. The tag therefore depends on both the authenticated data and the IV-derived starting point.
When the IV repeats under the same key, the J0-based tag mask repeats. The GHASH inputs can differ because the messages differ, but the same mask is applied to the resulting authentication values. Comparing the observed tags and their known AAD/ciphertext inputs can then produce relationships involving H. The adversary is not simply guessing a tag; the repeated IV has caused the authentication calculation to reveal algebraic structure.
The same observation explains why AAD belongs in the diagnosis. Two records can have identical encrypted bodies but different authenticated headers, or different bodies under the same visible context. Either way, the GHASH input changes while the repeated IV keeps the mask fixed. The resulting tag relationships are about the complete authenticated input, not just about the secret body. A log that stores ciphertexts but discards the associated IV, AAD, or tags may be unable to establish how much of that structure was exposed.
NIST describes the result with careful language. If IVs repeat for GCM authenticated encryption under a given key, an adversary is likely to determine the hash subkey from the resulting ciphertexts. Once the subkey is known, the adversary can substitute ciphertext and AAD and calculate a valid tag. In most cases, the authenticated-decryption function cannot detect that the IV has been repeated, so the authentication assurance is essentially lost.
The phrase “hash subkey” can sound less important than “encryption key,” but it is the value that shapes every GHASH calculation for that key. Learning H does not mean that AES has been inverted or that the main key has been recovered. It means that the adversary has learned enough about the authentication algebra to manufacture the part of a GCM input that was supposed to demonstrate integrity.
The exact route to recovery depends on the transcript. The inputs may have different lengths, different AAD, or different amounts of known content. The adversary may need to observe multiple outputs or have access to a decryption behavior that reveals whether a proposed tag is accepted. NIST's warning supports treating a repeat as a critical incident and assuming serious authentication risk; it does not support claiming that one arbitrary collision, in every possible setting, yields a universal forgery with no further conditions.
A careful diagnosis distinguishes direct consequences from conditional outcomes
Some conclusions follow immediately from the repeated key-and-IV condition. The corresponding counter inputs repeat. The corresponding AES outputs repeat. XORing the ciphertexts removes that output and reveals the XOR of the plaintexts. Counter-mode bit changes remain mapped to corresponding plaintext bit changes. These are construction-level consequences, although their practical impact still depends on message structure and what the adversary knows.
Other conclusions are conditional but severe. Repeated IVs create repeated tag masks and relationships among GHASH values. Those relationships may allow recovery of H, as NIST explains. If H is recovered, valid tags for substituted AAD and ciphertext can be constructed. If a forged ciphertext is accepted, the underlying counter-mode malleability can allow a same-length desired plaintext when the adversary has the relevant original plaintext relationship. Each step depends on the transcript and the attack setting, but none should be dismissed as a merely theoretical change to a probability estimate.
This is also why incident analysis should begin with the key domain, not with a single ciphertext. The first questions are whether the same key was actually active, whether the IV was reused for distinct inputs, how many records share the condition, and which plaintext, AAD, and tag values are available. Without those facts, an analyst may understate the damage by looking only for readable plaintext or overstate it by assuming complete key compromise. The mode's security property can fail before either extreme is demonstrated.
A repeated IV should therefore change the operational interpretation of every affected key. The direct evidence may be a collision in an IV log, matching counter conditions, or two records with the same key-scoped invocation value. The resulting confidentiality exposure may be partial. The authentication exposure may be likely rather than mechanically certain from the first observation. But the safe conclusion is that the key domain can no longer be treated as operating within GCM's uniqueness assumption.
The next judgment is not yet how to generate a better nonce. It is to reassemble the complete failure chain: the same IV repeats the counter starting point, the counter path leaks plaintext relationships, the tag path can expose GHASH structure, and malleability becomes dangerous if authentication can be forged. Only after those links are separated can a system decide which input, state, and ownership boundaries must prevent the chain from starting.