AES-CTR SP 800-38A
Pure stream cipher. Reuse collapses to C₁ ⊕ C₂ = P₁ ⊕ P₂ — keystream reuse, exactly the XOR reveal. There is no integrity tag here to lose.
What is a nonce, and why does reuse matter?
A nonce — "number used once" — is a per-message value that a cipher mixes in so the same key can safely encrypt many messages. It is not a secret: it travels in the clear next to the ciphertext, and nobody checks it for uniqueness. NIST calls it an initialization vector (IV); the idea is identical.
The ciphers here lean on one rule: never use the same nonce twice under the same key. Break that rule and the math that made them secure turns against you. What makes this lab worth your time is that the four constructions do not fail the same way — and knowing exactly how each one fails is the difference between a shrug and a catastrophe.
No theory required to start. Go to The XOR reveal, reuse a nonce yourself, and drag out a hidden message. Then the rest of the page explains what you just did.
TEACHING DEMO — NOT PRODUCTION
Every cipher operation on this page is real: AES runs in your browser's WebCrypto engine; ChaCha20 and Poly1305 are hand-rolled to the RFC 8439 test vectors so their internals are inspectable. The attacks recover real keys from real ciphertexts and are accepted by the real verifiers. It is still a teaching demo — keys live only in memory for the session, and nothing here is hardened for production use.
The XOR reveal — recover a message you were never given
This is the headline mechanism. Two messages, one AES-CTR key, one nonce. Because a stream cipher just XORs plaintext with a keystream that depends only on (key, nonce), reusing the nonce makes both messages share the same keystream — and XORing the two ciphertexts cancels it, leaving P₁ ⊕ P₂ with no key involved. Drag a guessed piece of one message across it and the other message falls out. This runs against real AES-CTR ciphertext.
- Step 1 — done: both messages encrypted under one reused nonce.
- Step 2: type a crib you'd expect in Message 1 (or let the helper pick one).
- Step 3: slide it until the recovered bytes read as English — that's Message 2.
C₁ ⊕ C₂ = P₁ ⊕ P₂ (the keystream is gone)
offset 0
Recovered bytes of Message 2 under the crib (green = printable text — the crib fits here)
Try dragging the crib to where Message 1 actually reads the (e.g. offset 0). When your guess about Message 1 is right, the true bytes of Message 2 appear — that is crib-dragging, and it needs no key.
Same mistake, four outcomes
The same slip — one nonce, twice, under one key — lands differently on each construction. For each card below, flip the nonce from unique to reused, run it, and read the two separate indicators: what the cipher's own function returned, and the security verdict. They are not the same thing. A tag can verify as VALID and still be a forgery — that reads as an ALARM, never a success.
Two indicators, on purpose. Cryptographic result is the raw return value of the primitive (did it decrypt? did the tag check out?). Security verdict tracks whether the system's guarantee still holds. Colour follows the verdict, not the return value — because a forgery the verifier accepts is the most dangerous outcome of all.
One click breaks (or spares) all four at once, then read the running tally below and the per-card detail underneath. This is the whole thesis in one motion: one mistake, four different failures.
AES-GCM SP 800-38D
Keystream reuse plus a worse break: two ciphertexts under one nonce let Joux's "forbidden attack" recover the GHASH authentication subkey H, enabling tag forgery. This is authentication-key recovery — not AES key recovery.
ChaCha20-Poly1305 RFC 8439
Keystream reuse plus recovery of the per-message Poly1305 one-time key (r, s), which is fixed by (key, nonce) — enabling forgery for that nonce. The ChaCha20 key itself is not recovered.
AES-CBC SP 800-38A
A weaker failure. IV reuse makes CBC deterministic on shared prefixes: two messages with the same leading blocks produce the same leading ciphertext blocks. It leaks prefix equality — not the keystream, not the plaintext.
The consequence table — precise, and precisely different
| Construction | Spec | What nonce reuse breaks | Precise consequence | Enc./AES key recovered? |
|---|---|---|---|---|
| AES-CTR | SP 800-38A | Confidentiality | Keystream reuse → C₁⊕C₂ = P₁⊕P₂; plaintext recovery by crib-dragging. No integrity claim to lose. |
No |
| AES-GCM | SP 800-38D | Confidentiality and integrity | Keystream reuse, plus GHASH authentication subkey H recovery (forbidden attack) → existential forgery under that key. | No — auth key only |
| ChaCha20-Poly1305 | RFC 8439 | Confidentiality and integrity | Keystream reuse, plus Poly1305 one-time key (r, s) recovery → forgery for that nonce. | No — MAC key only |
| AES-CBC | SP 800-38A | Confidentiality (partial) | IV reuse leaks equality of first blocks / message prefixes. Deterministic-encryption pattern leakage, not keystream collapse. | No |
The precision is the point. "Key recovery" is a phrase that hides a huge range. GCM and ChaCha20-Poly1305 leak the authentication key and let you forge; neither leaks the encryption key, so neither hands an attacker the ability to decrypt future messages under a fresh nonce. Overstating that would be a lie the math doesn't support.
Why the forgeries work — one cancellation, twice
Both authenticated modes fall to the same shape of mistake: a secret pad that depends only on (key, nonce) sits inside the tag, and when the nonce repeats, XORing two tags cancels that pad and exposes a clean equation in the one unknown you want. Press each button to watch the cancellation happen — nothing here moves on its own.
AES-GCM: the mask cancels, leaving a polynomial in H
The GCM tag is a keyed checksum GHASHH over the ciphertext, with a per-nonce mask EK(J₀) XORed on top. H = EK(0¹²⁸) is fixed by the key; the mask is fixed by (key, nonce).
tag₁=GHASHH(C₁)⊕mask
tag₂=GHASHH(C₂)⊕mask
tag₁ ⊕ tag₂=(C₁ ⊕ C₂)·H²⊕mask ⊕ mask
The same mask sits in both tags.
For two equal-length single blocks this collapses to tag₁ ⊕ tag₂ = (C₁ ⊕ C₂)·H², solved directly as H = √((tag₁⊕tag₂)·(C₁⊕C₂)⁻¹) over GF(2¹²⁸). Recover H and the mask, and you can forge a tag for any ciphertext under that nonce. This is exactly what the GCM card runs — the recovered H is checked byte-for-byte against the true EK(0¹²⁸), and the forged blob is handed to WebCrypto's own verifier.
ChaCha20-Poly1305: the one-time key is reused, so (r, s) leaks
Poly1305 is a one-time authenticator: for a key (r, s) the tag is (polyr(msg) + s) mod 2¹²⁸. "One-time" means (r, s) may authenticate exactly one message. In the AEAD, (r, s) is ChaCha20(key, nonce, 0)[0:32] — fixed by (key, nonce).
tag₁=n₁·r+s
tag₂=n₂·r+s
tag₁ − tag₂=(n₁ − n₂)·r+s − s
The same s sits in both tags.
With s gone, a linear (single-block) relation in r remains over the field GF(2¹³⁰−5); invert (n₁−n₂), resolve the small carry from the final mod 2¹²⁸, and r — then s — fall out. The ChaCha card recovers (r, s) from public tags only, checks them against the true one-time key, and the real Poly1305 verifier accepts the forged tag. The ChaCha20 encryption key never appears in any of this.
Where a nonce actually repeats
Reuse is not exotic. It comes from two ordinary places: random nonces colliding by the birthday bound, and counters that silently rewind.
Random 96-bit nonces and the birthday bound
Pick nonces at random from a 2bits space and a collision becomes likely far sooner than intuition says — around √(2·2bits) draws, not 2bits. Slide the message count and watch the probability of at least one repeat climb (computed live from the exact birthday formula).
Nonce size
2⁴⁰ messages
Collision probability—
50% chance at about—
This is why SP 800-38D limits a single key to 2³² invocations when 96-bit IVs are generated randomly: past that, the birthday probability of an IV collision — and the total break you just saw — stops being negligible.
Counters that rewind
A monotonic counter never repeats — until the machine does. Restore a VM snapshot, fork a process, or roll back a container and the counter resumes from an old value, re-emitting nonces already used under the same long-lived key. The counter looks perfect; the environment betrayed it.
The deeper question — how randomness and state themselves collapse — is its own subject. See the Entropy Collapse lab in the Crypto Lab catalog. This lab stops at the nonce and what breaks downstream of it.
Fixes, and what this lab is not
The mitigation: make reuse survivable (or impossible)
Two directions. Guarantee uniqueness — a single encryptor with a persistent counter, or the discipline SP 800-38D demands. Or use a misuse-resistant AEAD that degrades gracefully: AES-GCM-SIV (RFC 8452) derives the IV from the plaintext, so reuse leaks only whether two plaintexts were identical — no keystream collapse, no key recovery.
| Under one reused nonce | AES-GCM (this lab) | AES-GCM-SIV (RFC 8452) |
|---|---|---|
| Confidentiality | Keystream reuse → C₁⊕C₂ = P₁⊕P₂ | Leaks only whether two plaintexts are identical |
| Integrity | GHASH subkey H recovered → tag forgery | No key recovery; the tag still binds |
| Cost | Single pass, online | Two passes; must buffer the full plaintext |
Described, not run here. The AES-GCM-SIV column is the RFC 8452 behaviour, not a live computation — this lab deliberately does not implement SIV. To break both side by side against real crypto, see Nonce Guard.
Honest scope — what this is not
- No AES key recovery, anywhere. The GCM and ChaCha20-Poly1305 breaks recover authentication keys and enable forgery. The AES/ChaCha encryption key is never learned. The whole lab is built around that distinction.
- Not a misuse-resistant-AEAD build. AES-GCM-SIV is named as the fix and linked, not implemented here — see Nonce Guard.
- Not an entropy-source lab. How randomness and counters fail upstream is Entropy Collapse, in the catalog.
- No CBC padding oracle. CBC here leaks prefix equality only; the padding-oracle decryption attack is Padding Oracle.
- What it does not prove: that these ciphers are weak. Used correctly — a unique nonce per message under each key — every one is secure. This lab proves only that the nonce rule is load-bearing, and that violating it fails in construction-specific, non-graceful ways.