AES-GCM can protect a message's confidentiality and detect unauthorized changes. It does not, by itself, tell the receiver whether an otherwise valid message has already been processed.
Three requirements are easy to confuse: unique key/nonce pairs for encryption, authentication of the message and its context, and protocol-level replay handling. HKDF can help derive keys, but it does not automatically satisfy all three.
Nonce reuse and replay are different events
| Event | What happens | Required protection |
|---|---|---|
| Nonce reuse during encryption | Different plaintexts are encrypted with the same GCM key and nonce | A reliable key/nonce allocation strategy |
| Tampering | Ciphertext or authenticated context is changed | Authenticated decryption and rejection on failure |
| Replay | A previously valid encrypted message is delivered again | State and application rules that recognize duplicates or stale messages |
| Reordering | Valid messages arrive in a different order | Protocol-defined ordering and bounded out-of-order handling |
A replayed ciphertext can still have a valid authentication tag. Nothing was changed. It is therefore incorrect to say that every duplicate automatically fails AES-GCM authentication. RFC 5116 explicitly separates the AEAD interface from anti-replay services.
Why the key-and-nonce pair must not repeat
GCM's nonce need not be secret, but it must meet the scheme's uniqueness requirements under a given key. A 96-bit, or 12-byte, nonce is common; choosing that length does not guarantee correct generation.
Reusing the same key and nonce for different plaintexts reuses the encryption keystream, exposing relationships between the plaintexts. It can also undermine authenticity and enable forgery. The impact is serious, but it should not be described as automatically revealing every old key or every message in an account. The affected scope depends on the reused key and protocol.
NIST SP 800-38D defines GCM and its requirements. Implementations must follow applicable invocation limits and nonce-generation rules, not a simplistic “safe until this many messages” rule of thumb.
What HKDF contributes
HKDF, specified in RFC 5869, derives keying material from input secret material using extract and expand stages. Protocols can use context labels and distinct inputs to separate keys for different purposes.
HKDF is deterministic. If a crashed or rolled-back client repeats the same state and inputs, it can derive the same output again. Adding HKDF to a design therefore does not make nonce reuse impossible.
Per-message keys can reduce the amount of content protected under any one key, but safe state advancement, key separation and deletion still matter. The same nonce value under genuinely different keys is not the same failure as repeating a key/nonce pair; the protocol must establish that the keys really are different.
Replay protection belongs in the protocol
A receiver may track message identifiers, sequence positions, session epochs or consumed ratchet keys. Relevant fields must be authenticated so an attacker cannot relabel an old message as a new one.
The application must then decide what a duplicate means. Displaying a duplicate chat bubble is inconvenient; executing the same action twice may be more serious. Network retries are normal, so idempotent processing is often necessary alongside cryptographic checks.
Do not require every valid message to arrive strictly in order unless the protocol specifies that behavior. Mobile clients routinely reconnect, retry and receive delayed messages. Safe handling distinguishes a legitimate late message from an already-consumed or wrong-context message.
What to test before claiming protection
- Restart after allocating a nonce but before recording the send: can the allocation repeat?
- Restore an older state snapshot: can keys, counters or replay records roll back?
- Send concurrently from two workers or devices: are their key/nonce domains separated?
- Deliver the same valid message twice: is the application action performed once?
- Alter a session identifier or header: is the context cryptographically bound?
- Deliver valid messages out of order: are supported delays handled without accepting stale state?
Authenticated-decryption APIs should return plaintext to the application only on successful verification. That is an interface requirement; it is not a claim that no implementation ever computes a temporary plaintext buffer internally.
Reading Livara's claims accurately
Livara's security documentation names AES-256-GCM, per-message chains and LVR1/LGS1 context. Those primitives do not independently prove correct crash recovery, nonce allocation or replay rejection. Such claims need versioned protocol details and test evidence.
A strong design assigns each job explicitly: key derivation creates the intended keys, AEAD authenticates content and context, and stateful protocol logic decides whether a valid message is acceptable now.
