A nonce is a "number used once." The whole security of several widely deployed encryption and signature schemes rests on that single word — once. Break the rule, even by accident, even one time, and you can hand an attacker your message contents, your forgery key, or in the worst case your private signing key. This is the bug that has sunk WEP, a game console, and more than one TLS library.
Most cryptographic failures are gradual: a cipher weakens, a key gets a little too short for comfort, an attack drops from impractical to merely expensive. Nonce reuse is not like that. It's a cliff. With many modern constructions, a single repeated nonce under the same key doesn't degrade security — it eliminates it, often completely, often instantly.
Understanding why turns an abstract rule ("don't reuse nonces") into something you can reason about — and it explains a string of famous breaches that all share the same root cause.
What a Nonce Is For
Encrypting the same plaintext twice with the same key should not produce the same ciphertext — otherwise an eavesdropper learns when you repeat yourself, which leaks more than you'd think. The fix is to inject a unique value into each encryption so identical inputs produce different outputs. That value is the nonce (sometimes called an IV, initialization vector, depending on the construction).
The nonce doesn't need to be secret. It's typically sent in the clear alongside the ciphertext. Its only job is to be different every time for a given key. That's the entire contract — and it's enough to make the difference between a secure cipher and a broken one.
How Reuse Breaks a Stream Cipher
AES-GCM and ChaCha20-Poly1305, the two AEAD ciphers behind most of the modern internet, both work as stream ciphers under the hood: the key and nonce generate a long pseudorandom keystream, and the plaintext is XORed with that keystream to produce ciphertext.
Now suppose you encrypt two different messages, P1 and P2, with the same key and the same nonce. Both get XORed with the identical keystream K:
- C1 = P1 XOR K
- C2 = P2 XOR K
An attacker who captures both ciphertexts computes C1 XOR C2. The keystream cancels out perfectly, leaving P1 XOR P2 — the XOR of your two plaintexts, with no key required. From there, known structure in either message (HTTP headers, file formats, language patterns) lets an attacker peel them apart. The encryption has effectively vanished.
It gets worse than confidentiality
For AES-GCM specifically, nonce reuse also leaks the authentication subkey (the value GCM uses inside its GHASH function). Two messages under one nonce give an attacker enough to solve for it — and once they have it, they can forge valid authentication tags for messages you never sent. So a single repeated nonce in GCM costs you both confidentiality and integrity at the same time.
The Signature Variant: Even Nastier
ECDSA, the elliptic-curve signature scheme, uses a per-signature random value usually written as k. It's a nonce by another name, and its reuse is the most dangerous of all. If you sign two different messages with the same k under the same private key, the algebra collapses: an attacker who sees both signatures can solve a pair of linear equations and recover your private key outright.
This is not theoretical. In 2010, the group fail0verflow demonstrated exactly this against the Sony PlayStation 3: Sony's code signing used a fixed k instead of a fresh random value for every signature, and that let researchers extract the private key used to sign software for the console. The same class of mistake has been found in Bitcoin wallets with weak random number generators, where reused or predictable k values drained funds by exposing private keys.
The deterministic-nonce construction in RFC 6979 exists precisely because trusting a device to produce a good random k every single time turned out to be a losing bet.
A Short History of the Same Bug
| Incident | What went wrong | Consequence |
|---|---|---|
| WEP (Wi-Fi, 2001) | 24-bit IV with RC4 — far too small, IVs repeated within hours on a busy network | Keystream recovery; WEP keys cracked in minutes |
| Sony PS3 (2010) | Fixed ECDSA k across all code signatures | Master private signing key extracted |
| Various TLS libs | GCM nonces generated with insufficient randomness or counters that wrapped | Confidentiality and forgery risk on affected connections |
Decades apart, different algorithms, different industries — one root cause. That's what makes nonce reuse worth a dedicated mental model rather than treating each incident as a one-off.
How Engineers Avoid It
There are two disciplined approaches, and they suit different situations:
- Counters. If a single key is used by a single sender, a simple incrementing counter guarantees uniqueness — no randomness needed, no collision risk, as long as the counter never wraps or resets. This is how protocols like TLS 1.3 and the Noise Framework manage per-message nonces.
- Large random nonces. When a counter isn't practical (multiple writers, no shared state), you can pick random nonces — but the standard 96-bit GCM nonce is risky here, because random 96-bit values start colliding (the birthday bound) after roughly 2^32 messages. Extended-nonce variants like XChaCha20 use a 192-bit nonce, making random selection safe for all practical message volumes.
Nonce-misuse-resistant modes
Because the failure is so catastrophic, cryptographers built modes designed to fail gracefully. AES-GCM-SIV (RFC 8452) and the broader SIV construction derive their effective nonce from the message content itself. If you accidentally reuse a nonce, the worst that happens is an attacker learns whether two ciphertexts encrypt identical plaintexts — the keys and forgery resistance stay intact. For systems where nonce uniqueness can't be guaranteed by design, these modes are a meaningful safety net.
The Takeaway
"Number used once" sounds like pedantry until you see how completely the math punishes a violation. The lesson for anyone building or evaluating crypto is twofold: never hand-roll nonce management when a vetted library or counter discipline exists, and treat "we generate nonces randomly" as a claim that deserves scrutiny about how random and how large.
It's also a reminder of why we lean on audited, high-level cryptographic constructions rather than assembling primitives by hand. The dangerous part of cryptography is rarely the cipher — it's the bookkeeping around it. For a related class of subtle-but-deadly implementation bugs, see padding oracle attacks and side-channel attacks.
Originally published at havenmessenger.com
