Nonce Guard

A1 — The one rule

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 — and the rest of this page is what happens when that one rule is broken.

NIST SP 800-38D calls it an Initialization Vector (IV); RFC 5116 calls it a nonce — same concept.

No theory yet — go break it first. Head to Section B, flip the nonce toggle, and watch AES-GCM leak. Then Section C explains the algebra behind what you just saw.

C1 — Level 1: keystream reuse (confidentiality)

AES-GCM encrypts by XORing plaintext with a keystream — a pseudorandom pad derived from (key, nonce, counter). The keystream depends only on the key and nonce, not on the message. So if you reuse a (key, nonce) pair, both messages get XORed with the same pad:

Because x ⊕ x = 0, the identical keystream blocks annihilate each other. What's left is C₁ ⊕ C₂ = P₁ ⊕ P₂ — the XOR of the two plaintexts, with no key involved at all. In practice that often recovers both messages (via crib-dragging / known structure). This is exactly the Recovered P₁ ⊕ P₂ you saw in Section B.

C2 — Level 2: authentication-key recovery (integrity)

GHASH — a keyed checksum built from multiply-add in a special number system. GF(2¹²⁸) — arithmetic on 128-bit blocks where "add" is just XOR. The mask — a per-nonce pad AES adds on top of the checksum so the tag looks random.

AES-GCM's tag is that GHASH checksum, keyed by H = E_K(0¹²⁸) (fixed by the key alone), with the mask XORed on top. For a 96-bit nonce:

The mask E_K(nonce ‖ 0³¹1) depends only on (key, nonce) — so, just like the keystream in Level 1, two tags under the same nonce carry the identical mask. XOR the two tags and it cancels:

With the mask gone, what remains is one equation in the single unknown H over GF(2¹²⁸). The picture above shows the simplest shape of it — two equal-length single blocks, where it collapses to tag₁ ⊕ tag₂ = (C₁ ⊕ C₂)·H² and H = √((tag₁ ⊕ tag₂)·(C₁ ⊕ C₂)⁻¹) falls out directly. In general your messages span several blocks and the equation is the full polynomial:

— one term per 16-byte ciphertext block, plus the length block. That is a real polynomial, and recovering H means factoring it over GF(2¹²⁸). Section B does exactly that on your two messages: gcd with x2¹²⁸ − x isolates the roots that live in the field, then characteristic-2 Cantor–Zassenhaus trace splitting separates them. Usually one root comes back; sometimes a handful, and one forged tag per candidate settles which is the real key. Recover H and you also recover the mask, and then you can forge a valid tag for any ciphertext under that nonce — this is Joux's "forbidden attack." Not theoretical: a 2016 survey (Böck, Zauner, Devlin et al.) found production HTTPS servers reusing AES-GCM nonces, exposed to exactly this.

D0 — The synthetic-IV construction (RFC 8452)

AES-GCM-SIV uses a synthetic IV approach:

1. Derive a per-nonce authentication key and encryption key from the master key and nonce
2. Hash the plaintext (and AAD) with POLYVAL (a keyed checksum, GHASH's twin in a little-endian-friendly field) — then XOR in the nonce and AES-encrypt the result to produce the tag
3. Use that tag (top bit set) as the synthetic IV for AES-CTR encryption

The IV is derived from the plaintext itself. If the same (key, nonce) pair encrypts two different plaintexts, the two IVs differ, so the two keystreams differ — the Level 1 cancellation can never happen. Nonce reuse degrades to leaking only whether two plaintexts were identical.

D1 — Key Derivation

AES-GCM-SIV derives per-nonce keys from the master key. For each counter it AES-encrypts the block counter ‖ nonce (counter is a 32-bit little-endian value; nonce is 96 bits) and keeps the low 8 bytes of the output, concatenating them:

For a 128-bit master key the encryption key uses only counters 2–3 (two blocks).

D2 — POLYVAL Authentication (why the cancel trick dies)

POLYVAL — a keyed checksum, GHASH's twin, defined in RFC 8452 in a little-endian-friendly version of the same GF(2¹²⁸) field (add = XOR).

Its key H is derived per-nonce from (key, nonce). But the decisive difference from AES-GCM is the final step: the POLYVAL result is AES-encrypted before it is output as the tag.

Recall the Level 2 break in Section C: subtracting two tags cancelled the mask and left a clean polynomial in H. Here the attacker only ever sees AESKenc(S) — never POLYVAL's raw output S. XORing two tags now XORs two AES outputs, which linearizes into nothing: the AES pseudorandom permutation shreds the polynomial structure. So even reusing a nonce (which does reuse H) never leaks the authentication key.

D3 — Tag-as-IV, Live: plaintext → tag → IV → ciphertext

SIV's whole safety property is the IV depends on the plaintext. The 128-bit tag (the AES-encrypted POLYVAL result) is the initial AES-CTR counter block — copied verbatim, with the most significant bit of its last byte set to 1 (RFC 8452 §4). That bit is the same one cleared on the tag-generation input, so the tag value can never collide with a CTR counter. Watch all four values move together as you type — the tag changes, so the IV changes, so the very first ciphertext block changes.

Message A: Type any message to see how the AES-GCM-SIV tag, derived AES-CTR IV, and first ciphertext block all change together

E2 — Decision Guidance

E3 — Honest Limitations of AES-GCM-SIV

• Not FIPS-approved — cannot use in FIPS 140-2/3 contexts
• No online encryption — must have full plaintext before starting (not suitable for streaming)
• Two passes over the data — the tag must be computed before encryption can begin, so throughput can approach half that of single-pass AES-GCM on long messages, though hardware-optimized (AES-NI + PCLMULQDQ) implementations narrow the gap
• Not yet widely deployed — operational experience is thin compared to AES-GCM