AES-GCM nonce uniqueness is a deployment control

AES-GCM nonce uniqueness is a deployment control AES-GCM combines encryption with an authentication tag. The security argument depends on a rule that is easy to move out of the code review: for a given key, every invocation must use a unique initialization vector, or nonce, within the construction's limits. Reusing a key and nonce can expose relationships between plaintexts and break the integrity guarantee. NIST SP 800-38D describes the uniqueness requirement and the allowed IV construction methods. The implementation detail matters because a library may accept a nonce from the caller without understanding whether it is unique. Choose one authority for the counter A deterministic counter is straightforward when every encryptor has a distinct range. Assign each process, host or tenant a disjoint range or a unique prefix, persist the counter across restarts and reserve enough space for the maximum message rate. A restart that resets a counter while the old key remains active recreates the failure. Random nonces are easier to operate for low-volume keys, but they are not a license to ignore the birthday bound. Increase key rotation frequency as message volume grows. Keep a record of the key version, nonce source and message count so rotation is driven by evidence. Never derive the nonce from predictable fields alone, such as a database primary key, unless the resulting value is proven unique across all uses of that key. Avoid copying a nonce from a retry into a new encryption operation with changed plaintext. Separate keys by purpose Use distinct keys for different data classes, tenants and protocol roles where the design permits it. A key used for local disk encryption should not also protect session tokens or backups. The separation limits the scope of a counter-management bug and makes retirement possible without re-encrypting unrelated data. Store the key version and nonce strategy with the ciphertext metadata. On rotation, stop encrypting with the old key, keep it only for decryption during the approved migration window, then destroy it. Confirm that backups and replicas follow the same schedule. Test restarts and concurrency Run encryption across two concurrent workers, restart one worker, drain and restore from backup, and verify that no key and nonce pair repeats. Inspect logs for counter resets and key-version mismatches. A property test can generate a large sequence, but production controls still need to manage process identity, persistence and failover. The deployment is ready when the nonce budget has an owner, the key rotation path is tested and a counter reset is treated as a security event rather than a routine recovery. References NIST SP 800-38D: GCM and GMAC NIST CSRC: cryptographic nonce