AES-GCM vs AES-GCM-SIV — nonce misuse resistance compared
A nonce (number used once) in AEAD schemes is a per-encryption value that must be unique for every encryption under the same key. It does not need to be secret. AES-GCM uses a 96-bit nonce (12 bytes). The security proof assumes the nonce is never reused.
NIST SP 800-38D calls it an Initialization Vector (IV); RFC 5116 calls it a nonce — same concept.
96-BIT NONCE (12 BYTES)
AES-GCM encrypts by XORing plaintext with a keystream derived from (key, nonce, counter). If the same (key, nonce) pair is used twice:
The attacker recovers the XOR of the two plaintexts — which often recovers both plaintexts in practice.
AES-GCM's authentication tag uses a polynomial hash over GF(2¹²⁸) with a key H = AES_K(0¹²⁸). When the same nonce is reused, the attacker can solve for H algebraically from two (ciphertext, tag) pairs. Once H is known, the attacker can forge valid authentication tags for arbitrary ciphertexts — total integrity failure.
GHASH_H uses H directly, making H recovery from two equations over GF(2¹²⁸) a solvable linear algebra problem.
AES-GCM-SIV uses a synthetic IV approach:
The IV is derived from the plaintext itself. If the same (key, nonce) pair encrypts two different plaintexts, the two IVs differ. Nonce reuse degrades to leaking only whether two plaintexts were identical — not the keystream, not the authentication key.
Click "Encrypt Both" to begin
Click "Encrypt Both" to begin
AES-GCM-SIV derives per-message keys from the master key and nonce:
POLYVAL is a GF(2¹²⁸) polynomial hash defined in RFC 8452, using a different field representation than GHASH. The key distinction: POLYVAL's authentication key H is derived per-message from the (key, nonce) pair, not fixed per-key as in AES-GCM's GHASH.
The 128-bit POLYVAL tag becomes the synthetic IV after clearing one bit (preventing CTR counter overflow into tag space). Changing any byte of plaintext completely changes the tag and therefore the IV.
Type any message to see how the AES-GCM-SIV tag changes with each character| Property | AES-GCM | AES-GCM-SIV |
|---|---|---|
| Standard | NIST SP 800-38D | RFC 8452 |
| Nonce size | 96 bits | 96 bits |
| Nonce reuse consequence | Key recovery + full plaintext XOR | Identical plaintext detection only |
| Performance | ~1 pass | ~2 passes (extra POLYVAL) |
| FIPS approved | Yes | No (as of 2024) |
| Hardware acceleration | AES-NI + PCLMULQDQ | AES-NI + PCLMULQDQ |
| Online encryption | Yes | No — must buffer full plaintext |
| Deployed in | TLS 1.3, QUIC, IPsec | Google internal, QUIC experiments |
| Recommendation | ✅ Nonce uniqueness guaranteed | ✅ Nonce uniqueness uncertain |
AES-GCM with a counter nonce is safe. Nonce uniqueness is easy to guarantee. No need for SIV overhead.
Coordinating nonces across servers is error-prone. AES-GCM-SIV degrades gracefully on accidental reuse. Use SIV or use random 96-bit nonces with AES-GCM (collision risk is low at < 2³² messages per key).
AES-GCM-SIV is designed for this — short messages, repeated access to the same key, nonce coordination difficult. Google's Tink library uses it for key wrapping.