The Hard Part Is Recovery

For AES-GCM, the most dangerous moment may come after the encryption code has already worked correctly. This chapter follows a GCM key and its IV source through establishment, concurrent use, power loss, and retirement, then separates nonce uniqueness from tag, verification, and replay controls. The practical judgment is simple but demanding: a deployment must know who owns the key-wide IV state and what happens when the next unique value cannot be proved.

The previous construction choice determines what state must be preserved, but it does not remove the need for a lifecycle. A deterministic design must preserve its field assignments and invocation progress. An RBG-based design must preserve generator independence and its key-wide accounting. Both must keep key scope clear, because a value that is unique inside one component may be repeated by another component using the same key.

A GCM key has a lifecycle

The lifecycle begins when a key is established. NIST requires a GCM key established among its intended users to be fresh with high probability—different from previously used keys. This condition matters more for GCM than it may first appear. A deterministic counter or a random generator can be perfectly well behaved within one key session and still repeat an earlier IV sequence if an old key and its state are brought back into use together.

A fresh key therefore defines a new accounting domain, not just a new secret string. Every module, device, service, or context that uses that key participates in the same IV-uniqueness requirement. Separating components by ownership labels in an organizational chart does not separate them cryptographically. The key is the boundary that decides whether two equal IV values are dangerous instances of the same GCM starting conditions.

Before an IV is used, NIST treats it as a critical security parameter in the context of a validated module. It must receive protection comparable to other critical security parameters until the authenticated-encryption invocation occurs. This does not mean that the IV must remain secret after it is used. It means that an attacker or an unauthorized operator must not be able to influence, replace, or roll back the pre-use value in a way that defeats the uniqueness construction.

The system then enters active operation. Each authenticated-encryption invocation consumes one permitted IV for one input set. Under deterministic construction, the fixed field identifies the context and the invocation field advances. Under RBG-based construction, the random field comes from an approved generator or its permitted successors, and separate instances must remain independent. The operational state differs, but the transition is the same: a new protected input must receive a value that has not already been used under that key.

This is where concurrency changes the problem. Two workers may call GCM at nearly the same time. A device may be redeployed while another instance still uses the key. A configuration change may alter field lengths or construction choices for one module but not the others. NIST's operational guidance asks how those choices are enforced across all modules that ever implement authenticated encryption. The question is not whether each component can describe its own happy path; it is whether the combined system has one consistent key-wide rule.