How to Make GCM Nonces Stay Unique

For AES-GCM, choosing a nonce construction means choosing how a system will prove uniqueness over time. This discussion compares the two construction frameworks described by NIST: deterministic IVs, which allocate distinct parts of the value to devices and invocations, and RBG-based IVs, which rely on a sufficiently large random field and independent generators. The useful decision is not which framework sounds safer; it is which system can actually maintain the assumptions that keep a key-scoped IV from repeating.

The comparison starts from the same constraint that governs every GCM deployment. For a particular key, distinct input sets must not receive the same IV. The two constructions organize that obligation differently. Deterministic construction makes ownership visible through fields and counters. RBG-based construction reduces explicit allocation between invocations but places more weight on generator independence, probability accounting, and the lifetime of the key.

Deterministic IVs turn uniqueness into allocation

In NIST's deterministic construction, an IV is the concatenation of a fixed field and an invocation field. The fixed field identifies the device or, more generally, the context in which authenticated encryption is being performed. The invocation field identifies a distinct set of inputs within that context. For a given key, no two devices may share the same fixed field, and no two distinct input sets handled by one device may share the same invocation field.

The construction therefore divides one global uniqueness problem into two linked assignments. Someone or something must allocate context identity across the devices that share a key. Each context must then advance its invocation state without repeating a value. If either assignment fails, the concatenation can repeat even if the other assignment is perfect. Two devices with different counters still collide if they share a fixed field; one device with a unique identity still collides if its invocation field rolls back or wraps.

The invocation field is commonly an integer counter or a linear-feedback shift register driven by a primitive polynomial so that it has a maximal cycle. The specific mechanism is less important than the transition it must guarantee: it advances with every authenticated-encryption invocation. The field lengths and positions are fixed for the life of the key. They are not parameters that separate components can reinterpret independently after deployment.

That fixed layout is what makes deterministic construction inspectable. A system owner can ask which context owns each fixed-field value, how many invocation values remain, and whether every invocation advances the state exactly once. But inspectability does not remove the coordination burden. The fixed field has a finite number of possible values, and the invocation field has a finite number of distinct values for each context. NIST explicitly identifies both limits: an s-bit invocation field cannot support more than 2^s distinct input sets for one fixed field and key, while an s-bit fixed field limits the number of distinct devices or contexts for that key and IV length.

A common 96-bit arrangement illustrates the allocation idea. NIST suggests, without requiring it, placing a 32-bit fixed field at the front and a 64-bit invocation field at the end. The point is not that those exact widths are universally correct. The point is that a reader can see the two different capacity questions. How many contexts need to share the key? How many protected input sets can each context process before the key or IV layout must change?

The arrangement also exposes a subtle boundary around key scope.