Parag Mali - tag: aes-gcm

How AES Breaks in Real Life: The Attacks That Never Touched the Cipher

noreply@paragmali.com (Parag Mali) — Fri, 17 Jul 2026 00:00:00 GMT

**AES-the-cipher has never been broken in the field. Your AES traffic was decrypted anyway.** The best publicly known attack on the full cipher costs about $2^{126}$ operations for AES-128 -- its own authors say it does "not threaten the practical use of AES in any way" [@biclique-2011]. Yet real Wi-Fi sessions were decrypted, real HTTPS connections were forged, and real AES keys were lifted out of running servers. None of it touched the 128-bit block math. AES is a *permutation*, not a cryptosystem: to protect a message you wrap it in an *implementation*, a *mode*, and a *protocol*, and it was those three wrappers that failed -- a T-table lookup leaked the key through cache timing [@bernstein-2005; @osvik-shamir-tromer-2006]; 184 live HTTPS servers repeated an AES-GCM nonce and weaponized Joux's 2006 forbidden attack into forgery [@nonce-disrespecting-2016; @joux-2006]; and KRACK's replayed handshake rewound the AES-CCMP nonce and reused a keystream [@krack-2017]. Every fix changed *how AES is used*, never AES.

1. AES Is Unbroken. Your AES Traffic Was Decrypted Anyway.

The best publicly known attack on the full AES cipher costs roughly $2^{126}$ operations for AES-128 -- a number so far beyond feasible that its own discoverers wrote it does "not threaten the practical use of AES in any way" [@biclique-2011]. To put $2^{126}$ in scale: if every one of the billions of computers on Earth checked a billion keys a second, you would still wait longer than the age of the universe, many times over. By any honest measure, the cipher stands.

And yet, in the same decade that number was published, attackers decrypted live Wi-Fi sessions, forged authenticated HTTPS connections, and lifted AES keys straight out of running servers -- none of them going anywhere near that $2^{126}$ wall. How does a cipher nobody can break keep producing decrypted traffic and stolen keys?

The resolution is the thesis of this article, and you can hold it right now: none of these breaks touched the 128-bit block math. AES is a keyed permutation -- a function that scrambles one 16-byte block into another -- and nothing more. It is not a cryptosystem. To protect a real message you wrap that permutation in three things: an implementation that computes it on real silicon, a mode that chains it across a message, and a protocol that establishes keys and drives the mode. Each wrapper is a new, independent way to fail. And it was the wrappers, every time, that failed.

That gives you a diagnostic sentence to carry through the rest of this piece. When your encrypted traffic falls, the question is never "was AES broken?" It is: which layer around AES failed -- the implementation, the mode, or the protocol? By the end you will be able to drop KRACK, the GCM nonce scandal, and tomorrow's not-yet-published incident into that one question on sight.

To break AES in the field, you never touch AES. The table lookup leaks, the nonce repeats, the handshake rewinds -- and the 128-bit block math never moves.

This is Part 1 of How It Breaks in Real Life, a series with a single recurring claim: the primitive's mathematics almost never caused the break; the deployment did -- the nonce, the padding, key generation, a downgrade, a validation bug, or a deprecated-but-still-live algorithm. AES is the cleanest case, which is why it goes first. Its companion piece, How AES Would Break, asks what it would take to move the block itself: the key schedule, related-key cryptanalysis, the slow erosion of the security margin. That is the would-break-in-theory story. This is the did-break-in-the-field one.

If the cipher was intact and the block math never moved, then everything that broke was built around it. To see how "unbroken cipher" and "decrypted traffic" can both be true, you have to go back to what AES actually is -- and, more to the point, what it is not.

2. Why a Cipher Is Not a Cryptosystem

In October 2000, after a three-year open competition in which the world's cryptographers were invited to attack the candidates, NIST selected Joan Daemen and Vincent Rijmen's Rijndael as the Advanced Encryption Standard [@nist-press-2000]. The choice followed a public evaluation of fifteen submissions narrowed to five finalists, judged on security, performance, and efficiency from servers to smart cards [@nist-aes-dev; @nist-jres-r1-1999; @nist-jres-r2-2001]. That adversarial process is why the core math has held for over two decades -- and why, when things break in the field, the fault lies elsewhere. Winning the competition made Rijndael a cipher, not a cryptosystem.

Here is the distinction the whole article turns on. AES, standardized as FIPS 197 in 2001 and editorially refreshed in 2023 with no technical change to the algorithm, is a keyed 128-bit permutation [@fips-197]. It maps one 128-bit block to one 128-bit block under a 128-, 192-, or 256-bit key, and that is all it does.AES applies 10, 12, or 14 rounds for the 128-, 192-, and 256-bit keys. The round function is identical across all three; key size changes only the round count and the key schedule that feeds it [@fips-197]. It has no notion of a message longer than 16 bytes, no integrity, no session or conversation. Feed it the same block and key twice and you get the same output twice. On its own it cannot safely encrypt a paragraph, let alone a Wi-Fi session.

A **block cipher** is a keyed permutation on fixed-size blocks -- AES maps one 16-byte block to another under a key. A **mode of operation** (CTR, CCM, GCM, and others) is the wrapper that chains that permutation across an arbitrary-length message and, in authenticated modes, adds integrity. The block cipher is the engine; the mode is the car. You do not drive an engine.

To turn that engine into something that protects real data, you add three wrappers, and each one is a new, independent failure surface:

an implementation that computes the permutation on a real CPU, and may leak through timing or cache behavior;
a mode of operation that chains the permutation across a whole message and, in AEAD modes, adds integrity -- and imposes a contract on how you feed it nonces;
a protocol that establishes keys and drives the mode, and can mismanage them.

flowchart TD B["AES 128-bit permutation -- never broken in the field"] I["Implementation layer -- computes the block in code or silicon"] M["Mode layer -- chains the block, adds integrity, imposes a nonce contract"] P["Protocol layer -- establishes keys and drives the mode"] B --> I --> M --> P I -. break .-> AtkI["Cache timing leaks the key"] M -. break .-> AtkM["A repeated nonce reuses a keystream"] P -. break .-> AtkP["A replayed handshake rewinds the nonce"]

This map is the lens for everything that follows. The block sits at the center, untouched. The implementation wraps it, the mode wraps that, the protocol wraps that -- and the three field breaks in this article land on the three outer rings, in order, working outward from the silicon.

Note: AES has a 128-bit block size for all three variants; only the key is 128, 192, or 256 bits. When this article says "the 128-bit block math never moved," it means the block permutation, not the key. Hold onto a foreshadow: key size will turn out to be irrelevant to every break here. Against nonce reuse and a reinstalled handshake key, AES-256 fails exactly as fast as AES-128; against cache timing it is just as vulnerable, though a longer key takes proportionally more leakage to extract.

One more piece of honesty before we watch the wrappers fail. The series this article opens says the primitive's math almost never causes the break -- "almost," not "never" -- and the hedge is load-bearing.Every break in this article is independent of key size. That is not a rhetorical flourish; it is a literal property of cache timing, nonce reuse, and handshake replay, none of which involve guessing key bits.

Some deployed primitives genuinely fell as *math*, not deployment. DES died to brute force because its 56-bit key was too short, which is *why* NIST ran the AES competition in the first place. RC4's keystream biases were turned into real plaintext recovery against TLS [@alfardan-2013]. MD5 and SHA-1 fell to collision attacks -- the SHAttered project produced the first SHA-1 collision at roughly $2^{63}$ hash computations [@shattered-2017]. Those are real breaks of the primitive's mathematics. AES is simply not one of them, which is what makes its deployment-versus-primitive split so clean. Never harden "almost never" into "the math never breaks."

Three wrappers, three contracts, three ways to fail -- none of them the cipher. Before watching each one break in the field, you need to see the contracts up close: what a mode actually promises, what a nonce is, and why the humble table lookup is a loaded gun.

3. The Layers Around the Block, and the Contracts They Impose

Every one of the three field breaks is the violation of a single, specific promise. If you see the promise clearly now, the break will look obvious later. So here are all three contracts, one per layer, in order.

The implementation contract: a lookup should not leak what it looked up

Computing AES the naive way -- byte by byte through its S-box and its field multiplications -- is slow in software. So fast implementations fold an entire round into precomputed lookup tables. Four tables of about 1 KB each, conventionally called T0 through T3, turn each output column of a round into T0[a] XOR T1[b] XOR T2[c] XOR T3[d]: four reads and three XORs, so a full round is four of those -- sixteen reads in all [@bernstein-2005].

A set of precomputed lookup tables (typically four tables of 256 four-byte entries, about 4 KB total) that fold AES's SubBytes, ShiftRows, and MixColumns steps into a handful of table reads per round. It is purely a speed optimization. The block permutation it computes is identical to the slow version -- but *how* it computes it now depends on secret-derived indices.

The hidden assumption is that a table read takes the same time regardless of which entry you read. On a real CPU with a cache hierarchy, that is false: the first access to a memory line is slow, a cached line is fast, and an attacker can measure the difference. And the indices a, b, c, d are secret -- state bytes derived from the key XORed with the plaintext. So which table lines get touched, and therefore the timing, depends on the key. The implementation's contract is that a data-dependent lookup must not leak the data. The cache breaks it for free.

The mode contract: never repeat a (key, nonce) pair

A mode turns the one-block permutation into something that encrypts messages and detects tampering. Modern modes aim for AEAD.

Authenticated Encryption with Associated Data: a mode that provides confidentiality *and* integrity at once. It encrypts the plaintext and produces an authentication tag over both the ciphertext and some associated data (headers, sequence numbers) that is authenticated but not encrypted. GCM and CCM are AEAD modes; if the tag does not verify, the receiver rejects the message.

The workhorse construction is counter mode. AES is run on a counter to produce a keystream, and the keystream is XORed with the plaintext: keystream block $k_i = \mathrm{AES}_K(\text{nonce} \parallel i)$, and ciphertext $C_i = P_i \oplus k_i$. This is elegant and fast and fully parallel. It also carries one absolute obligation.

A **nonce** is a "number used once." In counter-based modes the pair (key, nonce) must be **unique for every encryption under that key**. The nonce need not be secret or random -- a counter is fine -- but it must never repeat. This is the single most load-bearing rule in practical symmetric cryptography, and it is the rule every mode-and-protocol break in this article violates.

Watch what happens if you break it. If two messages are encrypted under the same key and the same nonce, they get the same keystream. XOR the two ciphertexts and the keystream cancels:

$$C_1 \oplus C_2 = (P_1 \oplus k) \oplus (P_2 \oplus k) = P_1 \oplus P_2$$

The key never appears. The attacker who captures two same-nonce ciphertexts learns the XOR of the two plaintexts, and if they know or can guess one, they get the other -- with the cipher fully intact.

The failure that follows from a repeated (key, nonce) in a counter-based mode: identical keystream for two messages, so $C_1 \oplus C_2 = P_1 \oplus P_2$. The plaintext XOR leaks and the key is never touched. This one mechanic drives *both* the GCM break and the WPA2/CCMP break later in this article.

Key idea: A block cipher in a counter-based mode is a keystream generator. Feed it the same (key, nonce) twice and you get the same keystream, so $C_1 \oplus C_2 = P_1 \oplus P_2$ -- the plaintext XOR leaks and the key is never touched. The nonce-uniqueness contract is the one promise that stops this. Break it and the strongest cipher in the world protects nothing.

You can watch the cancellation happen. Nothing below is real AES -- the toy keystream stands in for AES-CTR output -- but the XOR algebra is exactly the algebra of the real break.

{` // Same (key, nonce) => same keystream for BOTH messages. That is the whole bug. const keystream = [0x9e, 0x37, 0xb1, 0xa4, 0x55, 0x0c, 0xd2, 0x6f];

function xorBytes(a, b) { const out = []; for (let i = 0; i < a.length; i++) out.push(a[i] ^ b[i]); return out; } const toBytes = (s) => Array.from(s).map((c) => c.charCodeAt(0));

const p1 = toBytes("ATTACK 0"); const p2 = toBytes("defend!!");

const c1 = xorBytes(p1, keystream); // what the attacker sees const c2 = xorBytes(p2, keystream); // what the attacker sees

const leaked = xorBytes(c1, c2); // C1 ^ C2, computed with NO key const truth = xorBytes(p1, p2); // P1 ^ P2, the secret relationship

console.log("C1 ^ C2 =", leaked.join(",")); console.log("P1 ^ P2 =", truth.join(",")); console.log("keystream cancelled?", JSON.stringify(leaked) === JSON.stringify(truth)); // Know one plaintext, recover the other. The cipher stayed perfectly strong. `}

GCM adds one more thing to worry about. Its integrity tag is built from a secret authentication subkey derived from the key alone, and a repeated nonce exposes that subkey to attack as well -- which is how confidentiality loss becomes forgery. We will pull that thread in the next section.

Even with perfectly unique nonces, GCM has a budget. With random 96-bit nonces, NIST caps a single key at fewer than $2^{32}$ invocations, because random 96-bit values begin colliding around the birthday bound [@sp-800-38d]. Uniqueness is not just a coding rule; it is a counting problem.

When AES-GCM came to TLS 1.2, RFC 5288 let the implementation choose part of each record's nonce -- an "explicit nonce" -- and its own security-considerations text carried a "Counter Reuse" warning that a repeated counter is catastrophic [@rfc-5288]. The contract was not merely implied; it was written down, in the same document that shipped the feature. A decade later, a scan of the live Internet found servers breaking it anyway.

The protocol contract: install a key once, so its nonce only ever counts up

A mode still needs a protocol to establish keys and supply nonces. WPA2's 4-way handshake derives a fresh Pairwise Transient Key, and AES-CCMP then encrypts each frame with a nonce built from an incrementing packet number; CCM, like GCM, forbids repeating that counter under one key [@sp-800-38c; @ieee-80211i-2004]. The assumption is simple and, on its face, obviously true: a key is installed exactly once, so the packet number only ever counts up and never rewinds.

Here are the three contracts side by side. Keep the last column in view -- it is the bill each violation runs up.

Layer	What it is	The contract it imposes	What a violation costs
Implementation	Code or silicon that computes the AES round	A data-dependent lookup must not leak the data	Cache/timing side channel recovers the key
Mode	CTR, GCM, CCM chaining the block across a message	The (key, nonce) pair must be unique per encryption	Keystream reuse leaks $P_1 \oplus P_2$; in GCM, forgery
Protocol	Handshake and key management driving the mode	A key is installed once, so its nonce only counts up	A reinstalled key rewinds the nonce, forcing reuse

Three contracts, each reasonable, each unenforced by the cipher -- the permutation cannot know whether you fed it a repeated nonce or read a leaky table. Which raises the only question that matters: in the real world, running on real servers and real routers, do these contracts actually hold? They do not. Here is where, when, and how each one broke.

4. Three Field Breaks, Three Layers, One Pattern

The comfortable belief is "we standardized a strong cipher, so our encrypted traffic is safe." What follows are three independent refutations of that inference -- one at each layer around the block, ordered by when the field break landed. Read them as a catalog, not a lineage: these are not ciphers that replaced one another but three simultaneous layers, every real deployment has all three at once, and the chronology is the attacker's frontier moving outward as each inner layer hardened.

timeline title From the silicon outward -- one pattern, three layers 2005-2006 : Implementation layer : Cache timing recovers AES keys (Bernstein, Osvik-Shamir-Tromer) 2016 : Mode layer : 184 HTTPS servers repeat a GCM nonce (Böck et al., weaponizing Joux 2006) 2017 : Protocol layer : KRACK rewinds the AES-CCMP nonce (Vanhoef and Piessens)

Generation 1: the implementation leaked (2005-2006)

In 2005, Daniel J. Bernstein did something the FIPS 197 math says is impossible: he recovered a full AES key remotely, over a network -- without breaking AES at all [@bernstein-2005; @bernstein-index]. The target was a server doing nothing but AES under clean timing conditions, so the demonstration was remote in principle rather than turnkey -- and alarming precisely because it was not purely local. It ran ordinary T-table AES, whose secret-dependent indices left the encryption's timing faintly correlated with the key; enough samples pinned the key bytes. A year later, Dag Arne Osvik, Adi Shamir, and Eran Tromer formalized the idea into two reusable cache attacks -- Prime+Probe and Evict+Time -- recovering keys with a modest number of encryptions on a shared machine [@osvik-shamir-tromer-2006].

Recovering a secret from the physical *side effects* of a computation -- its timing, its cache footprint, its power draw -- rather than from the algorithm's inputs and outputs. A cache-timing attack on T-table AES watches which cache lines the lookups touch; because the touched lines depend on key-derived indices, the access pattern leaks the key.

The mechanism is worth seeing as a chain, because every link is outside the cipher:

flowchart LR K["Secret index = key byte XOR plaintext byte"] --> L["Which T-table cache line is touched"] L --> M["Cache hit or miss changes measurable timing"] M --> R["Attacker narrows and then pins the key byte"]

You can feel the leak in miniature. A real CPU caches memory in lines of 64 bytes, so a 256-entry table falls into a handful of cache lines. The attacker never sees the secret index -- only which line was touched. Watch a single observation cut the keyspace:

{` // A CPU caches memory in 64-byte lines, so 256 one-byte table entries fall into // a few "cache lines." The attacker sees ONLY which line was touched -- not the index. const LINE = 64; const touchedLine = (index) => Math.floor(index / LINE);

const secretKeyByte = 0xB7; // unknown to the attacker const plaintextByte = 0x2A; // attacker-chosen, known const realIndex = secretKeyByte ^ plaintextByte; const observed = touchedLine(realIndex); // the only thing that leaks

// Which key bytes are consistent with the observed cache line? const candidates = []; for (let k = 0; k < 256; k++) { if (touchedLine(k ^ plaintextByte) === observed) candidates.push(k); } console.log("observed cache line:", observed); console.log("key-byte candidates remaining:", candidates.length, "of 256"); console.log("true key byte still in the set?", candidates.includes(secretKeyByte)); // One measurement: 256 -> 64. Vary the known plaintext, intersect the sets, and the byte falls out. `}

The insight is the sharpest edge of the whole thesis, so state it plainly.

Note: Cache timing recovers AES keys in the field -- that is real, and it is the reason "AES is unbroken" does not mean "your key is safe." But the leak lives in the T-table's memory-access pattern, not in the permutation. The table is a speed optimization; swap it for a leak-free implementation and the key stops leaking while the cipher stays byte-for-byte identical. Keys fall, the cipher stands. Keep that distinction sharp -- collapsing it is the reader's default error.

The fix pointed straight at the next era, and it changed how AES is computed, never what AES computes. Two responses followed: constant-time bitsliced software, which replaces the tables with data-independent boolean logic so no secret ever indexes memory [@kasper-schwabe-2009]; and, decisively, hardware AES-NI, which executes each round in silicon with no lookup tables and data-independent latency [@intel-aes-ni]. Once AES-NI reached mainstream CPUs in the early 2010s, this surface largely closed -- and the attacker's frontier moved one ring outward, to the mode.The formalization is due to Osvik, Shamir, and Tromer -- not Biham, a common misattribution [@osvik-shamir-tromer-2006].

Generation 2: the mode's contract was violated (2006, then 2016)

In June 2006, Antoine Joux submitted a public comment to NIST with a quietly devastating observation about GCM, now known as the "forbidden attack" [@joux-2006]. GCM, designed by David McGrew and John Viega, authenticates with a one-time polynomial MAC over the field $\mathrm{GF}(2^{128})$, keyed by a secret subkey derived from the encryption key alone [@mcgrew-viega-2004].

GCM's authentication secret, computed as $H = \mathrm{AES}_K(0^{128})$ -- the encryption of an all-zero block under the key. Every authentication tag is a polynomial in $H$ evaluated over the ciphertext, masked by $\mathrm{AES}_K(J_0)$ where $J_0$ comes from the nonce. Security depends on $H$ staying secret, which in turn depends on the nonce never repeating.

Joux's point: if a (key, nonce) pair repeats, the mask $\mathrm{AES}_K(J_0)$ is identical across the two messages, so the difference of their tags becomes a polynomial equation over $\mathrm{GF}(2^{128})$ whose unknown is $H$. Solve for the roots and you recover $H$; with $H$ in hand, you can forge a valid authentication tag for a message you chose -- universal forgery [@joux-2006]. The confidentiality loss from keystream reuse was already bad; this makes integrity fall too.

flowchart TD N["Same (key, nonce) used for two messages"] --> KS["Identical CTR keystream"] KS --> C["C1 XOR C2 equals P1 XOR P2, confidentiality lost"] N --> J["Identical tag mask AES_K of J0"] J --> EQ["Tag difference becomes a polynomial equation in H over GF(2 to the 128)"] EQ --> F["Roots reveal the subkey H, enabling forgery"]

For ten years this was a footnote -- a warning about a contract nobody, surely, would break. Then, in 2016, Hanno Böck, Aaron Zauner, Sean Devlin, Juraj Somorovsky, and Philipp Jovanovic scanned the Internet and found it broken in the wild [@nonce-disrespecting-2016]. Their paper, "Nonce-Disrespecting Adversaries," reported 184 live HTTPS servers actually repeating GCM nonces -- "which fully breaks the authenticity of the connections" -- among them large corporations, financial institutions, and a credit-card company, plus more than 70,000 servers using random nonces at volume risk.

They then did the thing Joux only described: they weaponized the repeats into working forgeries and injected content into live sessions. The root cause was mundane and entirely operational -- buggy hardware and firmware nonce generators, and counters that reset. The mode's assumption failed; AES did exactly what it was told.

Note: GCM will not stop you from repeating a nonce. Never generate a nonce you might repeat across process restarts, threads, forks, or virtual-machine clones and snapshots. A saved counter that resets to zero on restart is worse than useless -- it guarantees the reuse. AES-256 offers exactly zero protection here: key size is irrelevant to nonce reuse.

Two precisions keep this honest. First, the mechanism is layer-agnostic in the worst way: this is the same keystream-reuse atom from Section 3, now carrying a forgery payload because GCM's integrity also leans on the nonce. Second, resist the tempting overstatement.Precision lock. One nonce reuse is already a break: it immediately leaks $C_1 \oplus C_2 = P_1 \oplus P_2$ and gives one root-finding equation for $H$. But uniquely pinning $H$ for reliable universal forgery generally needs at least two collisions. Say "one reuse is already catastrophic, and more reuse pins the subkey" -- never "one reuse recovers the key" [@joux-2006]. The evidence for live reuse is the Böck et al. scan, five authors, 184 servers -- not the frequently miscited IBM Domino CVE [@nonce-disrespecting-2016].

The fixes, once again, changed the usage and left the cipher alone: nonce-misuse-resistant AES-GCM-SIV, where a repeat leaks only whether two messages were equal [@rfc-8452], and TLS 1.3's deterministic per-record nonce, which deletes the implementation-chosen "explicit nonce" that RFC 5288 had exposed [@rfc-8446]. As the mode hardened, the frontier moved one final ring outward -- to the protocol.

Generation 3: the protocol reused the nonce (2017)

WPA2's 4-way handshake exists to install a fresh key on both sides. The client installs its Pairwise Transient Key after message 3, and AES-CCMP then encrypts every frame with a nonce built from a packet number that only counts up. For reliability, the standard lets message 3 be retransmitted -- and there the trap was set. In 2017, Mathy Vanhoef and Frank Piessens showed that an attacker who captures and replays message 3 forces the client to reinstall a key it is already using, resetting the CCMP packet number and replay counter to their starting values [@krack-2017]. The nonce rewinds. The keystream repeats. This is KRACK: Key Reinstallation Attack.

Installing a key that is already in use. Because installing a key also initializes its associated nonce or packet-number counter, reinstalling an in-use key *rewinds* that counter to its starting value -- forcing the same (key, nonce) pairs, and therefore the same keystream, to be used again. KRACK triggers this by replaying a handshake message the protocol was willing to accept twice. sequenceDiagram participant C as Client participant A as Access Point participant M as Attacker A->>C: Message 1 (ANonce) C->>A: Message 2 (SNonce) A->>C: Message 3 (install key) Note over C: Installs PTK, packet number starts counting up C->>A: Message 4 (acknowledge) M->>C: Replay Message 3 Note over C: Reinstalls the same key, packet number resets to start Note over C,A: Nonce reused, keystream repeats, frames become decryptable

The insight is the same shape as before, delivered one layer further out: AES-CCMP did exactly what it was told. The permutation was flawless; the state machine told it to reuse a nonce, and it obeyed. The consequence is keystream reuse -- identical (key, nonce) yields $C_1 \oplus C_2 = P_1 \oplus P_2$ -- so a known-plaintext frame yields the keystream and decrypts the colliding frame.

Scope lock. Against AES-CCMP specifically, KRACK forces nonce-reuse decryption and replay -- not forgery and not AES key recovery. Forgery arises for the TKIP and GCMP cases, not CCMP. The especially devastating all-zero-key variant was an Android and Linux wpa_supplicant implementation bug that reinstalled an all-zero key, still not a break of AES [@krack-2017].

The fix was a backwards-compatible patch to the handshake state machine -- refuse to reinstall an in-use key -- shipped across Android, Linux, Apple, Windows, and OpenBSD in 2017 [@krack-2017]. Structurally, the Wi-Fi Alliance announced WPA3 in 2018 [@wifi-wpa3-2018]; its Personal mode swaps WPA2's pre-shared-key authentication for the SAE (Dragonfly) key exchange and mandates anti-reinstallation checks plus management-frame protection. The 4-way handshake still installs the pairwise key, so KRACK immunity comes from that mandatory hardening -- the same defense WPA2 received as a patch -- not from SAE removing the handshake [@dragonblood-2019]. The protocol changed. AES did not.

The pattern, seen all at once

Put the three side by side and the shape is unmistakable. Same violated contract in three costumes; same untouched block every time.

Incident	Year	Layer	Mechanism	Root cause	Fix (usage, not cipher)
Bernstein; Osvik-Shamir-Tromer cache timing [@bernstein-2005; @osvik-shamir-tromer-2006]	2005-2006	Implementation	Secret-dependent T-table indices leak via cache/timing	A data-dependent lookup leaks the data	Constant-time bitslicing; AES-NI
Joux forbidden attack; Böck et al. scan [@joux-2006; @nonce-disrespecting-2016]	2006, 2016	Mode	Repeated GCM nonce reuses keystream and exposes $H$	Buggy nonce generators break uniqueness	AES-GCM-SIV; TLS 1.3 derived nonces
KRACK [@krack-2017]	2017	Protocol	Replayed message 3 rewinds the CCMP nonce	State machine reinstalls an in-use key	Handshake patch; WPA3-SAE
Biclique baseline [@biclique-2011]	2011	The cipher itself	Best single-key attack: $2^{126.1}$ for AES-128	--	None needed -- "no practical impact"

Seen one at a time, these look like three unrelated bugs -- a cache thing, a TLS thing, a Wi-Fi thing. Seen together, they are a single pattern: every time, a contract around the permutation was violated, real traffic or keys fell, and the 128-bit block math did not move. That pattern is the whole point, and it is worth naming out loud.

5. The Fixes Changed How AES Is Used, Never AES

Stop treating the three incidents as separate stories. Line them up and one realization collapses the subject: every field break attacked a layer around the permutation, and every fix changed how AES is used -- never AES itself.

This is not a eureka discovery. It is an engineering discipline, and it is visible only because the same shape repeats three times across 2005, 2016, and 2017. Look at what each fix actually touched:

Implementation. Constant-time bitsliced code and hardware AES-NI compute the round with no data-dependent memory access [@kasper-schwabe-2009; @intel-aes-ni]. The tables are gone; the permutation they computed is unchanged.
Mode. AES-GCM-SIV makes a repeated nonce merely detectable rather than catastrophic -- a repeat leaks only whether two messages were equal, never the subkey $H$ [@rfc-8452]. TLS 1.3 derives each nonce deterministically from the record sequence number, deleting the footgun RFC 5288 had exposed [@rfc-8446]. The nonce plumbing changed; AES did not.
Protocol. The KRACK patch forbids reinstalling an in-use key, and WPA3 makes that anti-reinstallation defense mandatory (alongside management-frame protection) while swapping WPA2's pre-shared-key authentication for the SAE key exchange; the 4-way handshake persists, hardened rather than removed [@krack-2017; @wifi-wpa3-2018; @dragonblood-2019]. The state machine changed; AES did not.

Not one of these altered the block permutation. They hardened wrappers.

Key idea: The cipher is the fixed point around which everything else evolved. Every field break attacked a layer around the permutation, and every remedy -- constant-time and AES-NI, misuse-resistant AEAD and derived nonces, patched handshakes and WPA3 -- hardened a wrapper. Soundness requires the weakest of the three layers to hold, and hardening any one of them is an exercise in usage, not cryptanalysis.

There is a dynamic hiding in the chronology, and it is no coincidence. As AES-NI closed the implementation gap around 2010, the weakest remaining link -- the attacker's frontier -- moved to the mode, where the 2016 scan found it. As misuse-resistant modes and derived nonces closed that, the frontier moved to the protocol, where KRACK found it in 2017. The layers did not take turns being weak; the attacker simply always works the current weakest one. That is why "we use a strong cipher" was never the right unit of analysis. The right unit is the weakest wrapper you are still running.

This article is the *did-break-in-the-field* story. Its companion, *How AES Would Break*, is the *would-break-in-theory* one: the key schedule, related-key attacks such as the Biryukov-Khovratovich results on AES-256 that only exist in a related-key model correct deployments never create [@biryukov-khovratovich-2009], and the slow erosion of the security margin. Different question, different article. And the general craft of constant-time code, fault resistance, and key custody belongs to a third sibling on secure implementation. This piece links out to both rather than re-teaching them, because the point here is narrow and sharp: the wrappers broke, and the wrappers were fixed.

If every fix is a species of "use AES correctly," then the state of the art is just the catalog of what "correctly" means at each layer in 2026 -- and, tellingly, where even correct-by-the-book still is not quite enough.

6. What Correct AES Deployment Looks Like in 2026

The modern answer is unglamorous, and that is exactly the point: be sound at all three layers at once, because a hardened mode does nothing for a leaky implementation, and a constant-time implementation does nothing for a protocol that rewinds its nonce. Here is the correct-deployment endpoint, keyed to the three failure loci.

Implementation. Use hardware AES -- Intel and AMD AES-NI, or ARMv8's cryptographic extension -- which runs each round in silicon with no lookup tables and data-independent latency [@intel-aes-ni]. Where the CPU lacks AES instructions, fall back to a constant-time bitsliced software implementation that never lets a secret index memory [@kasper-schwabe-2009]. Mainstream libraries typically make this selection at runtime, preferring hardware AES with a constant-time fallback.

Mode. Use a vetted AEAD, never a hand-rolled chain of primitives. AES-GCM is the performance leader when you can guarantee nonce uniqueness -- either random 96-bit nonces kept under the NIST budget of fewer than $2^{32}$ invocations per key [@sp-800-38d], or TLS 1.3's deterministic per-record nonce derived from the sequence number [@rfc-8446]. Where uniqueness cannot be guaranteed, use AES-GCM-SIV, which survives a repeat gracefully [@rfc-8452].

An authenticated-encryption scheme that does not fail catastrophically when a nonce repeats. In an MRAE scheme such as AES-GCM-SIV, a repeated (nonce, message) pair leaks only the fact that the two plaintexts were identical -- never the keystream across distinct messages, never the subkey $H$. It is the provably strongest guarantee achievable once you admit that nonces sometimes repeat.

Protocol. At the link layer, patch WPA2 against key reinstallation or move to WPA3, which mandates anti-reinstallation checks and management-frame protection to close the defect while still running a 4-way handshake to install the pairwise key [@krack-2017; @wifi-wpa3-2018; @dragonblood-2019]. At the transport layer, prefer TLS 1.3 over 1.2: it deletes the explicit-nonce footgun and the downgrade and renegotiation hazards that made 1.2 fragile [@rfc-8446].

There is one caveat that keeps this from being a victory lap, and it is a good illustration of how deep the "usage" story goes.

Note: "AES-NI is constant-time by construction" is true by design intent, but on Ice Lake and later Intel cores, and Armv8.4-A and later, data-operand-independent timing -- including for AES instructions -- is only guaranteed when the processor's data-independent-timing mode is explicitly enabled [@intel-doit; @biggers-2023]. A constant-time algorithm is necessary but not sufficient for constant-time execution; part of the guarantee lives below your software, in a mode you now have to request.

The practical upshot is that "constant-time" has quietly become a setting rather than an assumption.On recent Intel cores the mode is called DOITM (Data Operand Independent Timing Mode); on Arm it is the DIT (Data-Independent Timing) processor-state bit. Eric Biggers raised the cross-vendor issue publicly in 2023, and it is the reason security-sensitive code on the newest silicon must ask for timing guarantees rather than inherit them [@biggers-2023; @intel-doit].

"Use a vetted AEAD, use hardware AES, patch your handshake" is the whole answer for greenfield code. But engineers inherit constraints -- a fixed nonce source, a distributed system that cannot coordinate a counter, a CPU with no AES instructions. So the real question is rarely "what is best." It is "what are my options, ranked, and exactly when does each one apply?"

7. Closing Each Gap: The Competing Defenses

At two of the three layers a practitioner actually has a choice, and the honest framing is a set of trade-offs, not a single winner. Take the two design spaces in turn.

The side channel: hardware AES-NI versus software bitslicing

These two coexist because they optimize different constraints. Where the CPU has AES instructions, AES-NI is the fastest option and constant-time by construction (subject to the DOIT/DIT caveat from the previous section) [@intel-aes-ni]. Where it does not -- older cores, small embedded parts -- constant-time bitsliced software gives a verifiable timing guarantee at the cost of speed and implementation effort [@kasper-schwabe-2009]. The one option that is never acceptable in security code is the original T-table implementation.

Dimension	T-table AES (broken)	Bitsliced constant-time software	Hardware AES-NI / ARMv8
Secret-dependent memory access	Yes (about 4 KB of tables)	None (boolean logic)	None (silicon datapath)
Timing side-channel resistance	Fails [@bernstein-2005; @osvik-shamir-tromer-2006]	Constant-time by construction	Data-independent by design; DOIT/DIT mode needed on Ice Lake+/Armv8.4+ [@intel-doit]
Throughput	Fast (pre-attack)	Good when blocks are batched	Fastest; line-rate AEAD
Block-parallelism needed	No	Yes (weak for a single block)	No
Hardware requirement	None	None	CPU AES instructions
Best suited for	Nothing security-sensitive	No-AES-NI or verifiable software	Everything with the instruction

The nonce: four live strategies

This is the design space where the 2016 scan drew blood, so it deserves the careful table. The four options trade nonce size, streaming ability, and misuse tolerance against each other.

Dimension	AES-GCM, random 96-bit nonce	AES-GCM, TLS 1.3 counter nonce	AES-GCM-SIV (MRAE)	XChaCha20-Poly1305
Nonce size	96-bit	96-bit (derived)	96-bit	192-bit
Passes	1 (streaming)	1 (streaming)	2 (buffered)	1 (streaming)
On accidental repeat	Catastrophic (leaks $P_1 \oplus P_2$; two collisions give $H$ and forgery)	Structurally prevented per connection	Graceful (leaks only message equality)	Catastrophic on a true repeat, but essentially never collides at random
Safe budget per key	Under $2^{32}$ messages [@sp-800-38d]	Per-connection sequence, no reuse if the counter is sound	Effectively unbounded against misuse	About $2^{96}$ random nonces before collision risk
Relative speed	Fastest (line rate)	Fastest	About 0.92 cpb on Broadwell, 14-19% slower than OpenSSL GCM [@gueron-lindell-2015]	Fast in constant-time software, no AES-NI needed
Primitive	AES	AES	AES	ChaCha20 (not AES)

Read the table as a decision, not a ranking. If you own a reliable per-connection counter, deterministic-nonce AES-GCM is both fastest and safe -- that is what TLS 1.3 does [@rfc-8446]. If you cannot guarantee uniqueness -- distributed writers, stateless functions, restart- or clone-prone systems -- AES-GCM-SIV is the provably strongest answer under misuse, at the price of a second pass and a buffered message [@rfc-8452; @rogaway-shrimpton-2006]. And if AES is not mandated and you just want "a random nonce is always safe," XChaCha20-Poly1305's 192-bit nonce makes accidental collision astronomically unlikely [@xchacha-draft] -- a different primitive, included as the most common answer to the nonce footgun rather than as an AES deployment.

Every option here changes how AES is used -- or swaps AES out entirely -- and each buys its safety with a specific cost: a pass, a throughput hit, a hardware dependency, a different primitive. Which makes the honest way to close the technical arc a question about limits: how little does the attacker actually need, and how much can the defender actually guarantee?

8. Theoretical Limits: What Is Provably True on Both Sides

The thesis has two sides, and each has its own provable frontier. The surprise is the asymmetry: the cipher side is essentially closed, and all the hard, unavoidable limits live in the deployment.

The cipher side: the math that did not break

Biclique cryptanalysis is the entire published erosion of the full-cipher security margin. Bogdanov, Khovratovich, and Rechberger reported the first single-key attacks on the full cipher at $2^{126.1}$, $2^{189.7}$, and $2^{254.4}$ for AES-128, AES-192, and AES-256 -- with no related-key assumption [@biclique-2011]. Against brute force at $2^{128}$, $2^{192}$, and $2^{256}$, that is a gain of at most roughly 1.6 to 2.3 bits: a factor of a few, not a factor that matters.A "bit" of security is a doubling of attacker work, so shaving 2 bits makes the attack about four times faster than brute force -- still astronomically far from feasible.

Metric	AES-128	AES-192	AES-256
Brute-force cost	$2^{128}$	$2^{192}$	$2^{256}$
Best known single-key attack (biclique)	$2^{126.1}$	$2^{189.7}$	$2^{254.4}$
Margin removed	about 1.9 bits	about 2.3 bits	about 1.6 bits
Practical threat	None	None	None
Relevance to the field breaks above	Zero	Zero	Zero

There is no proof that any attack on AES must cost as much as exhaustive search -- concrete block ciphers essentially never come with such a theorem -- so confidence rests on more than two decades of open cryptanalysis since the competition, not on an impossibility result [@fips-197]. But the reading is unambiguous, and the authors said it themselves.

The best known attacks on the full AES "do not threaten the practical use of AES in any way." -- Bogdanov, Khovratovich, and Rechberger, 2011 [@biclique-2011]

Notice the defender's column in the table never moves, and key size is irrelevant to every operational break in the sections above. The cipher side is, for practical purposes, a closed question.

The deployment side: where the real limits live

Now the asymmetry. Three provable boundaries constrain real systems, and none of them is about AES's strength:

The GCM birthday bound. With random 96-bit nonces, collision risk grows by the birthday bound, so NIST caps a single key at fewer than $2^{32}$ invocations [@sp-800-38d]. This is a structural limit of random-nonce GCM, independent of the cipher -- the mathematical reason "just use random nonces at massive scale" eventually fails.
The AEAD trilemma. No single scheme is simultaneously single-pass and line-rate, fully nonce-misuse-resistant, and large-nonce. GCM gives you the first, GCM-SIV the second, XChaCha the third-and-a-half; you cannot have all three at once [@rfc-8452]. And misuse-resistant AE is provably the strongest possible guarantee once nonces may repeat -- an attacker can always at least detect that the same message was encrypted, and a well-designed SIV scheme leaks nothing more [@rogaway-shrimpton-2006].
ISA-guaranteed whole-machine constant time is impossible in general. The instruction set does not, in general, promise data-independent instruction timing, so even AES and XOR instructions may be data-dependent on recent cores unless the timing mode is enabled [@intel-doit; @biggers-2023]. A constant-time algorithm cannot by itself guarantee constant-time execution; part of the guarantee lives below the software, and the general craft of getting it right is the subject of the secure-implementation sibling.

Key idea: The cipher-secure and system-secure claims are different, and the gap between them is inherent, not accidental. The cipher side has a negligible margin nibble -- under two bits. The deployment side has the real, provable limits: the GCM birthday bound, the single-pass / misuse-resistant / large-nonce trilemma, and the structural impossibility of ISA-guaranteed constant time. Key size buys nothing against any of them.

If the cipher side is closed and the deployment side has hard limits, then the live frontier is wherever those deployment limits are still being hit in the wild. That is not a solved problem. It is an active one.

9. Open Problems: Where AES Still Breaks in the Field

The cipher side is closed; the deployment side is not. Here are the places the same three-layer pattern is still live -- each an operational frontier, consistent with the thesis that the weakest link is the wrapper, not the block.

Guaranteeing nonce uniqueness in distributed, multi-writer, restart-prone systems. This is the exact gap that produced Generation 2: buggy counters and generators on 184 live servers repeated GCM nonces [@nonce-disrespecting-2016]. The best partial answer, MRAE via AES-GCM-SIV, makes a repeat detectable rather than catastrophic [@rfc-8452] -- but the single-pass, fully misuse-resistant, large-nonce scheme the trilemma forbids remains unrealized. In a world of stateless functions, cloned VMs, and shared keys across a fleet, "just keep a counter" is still an unsolved systems problem, not a solved one.

Cross-VM cache side channels in multi-tenant clouds. The 2005-2006 threat model assumed a shared physical machine; virtualization brought it back at scale. Irazoqui, Inci, Eisenbarth, and Sunar recovered AES keys across virtual-machine boundaries using Flush+Reload with memory deduplication [@irazoqui-2014]. Hardware AES removes the table channel, which is why AES-NI and constant-time code remain load-bearing in 2026.Even instruction timing can be data-dependent on recent cores unless the timing mode is enabled, so cloud tenancy keeps the Generation-1 question open even for hardware AES [@biggers-2023].

Fault and differential-fault attacks. Inducing a computation fault -- through voltage glitching, a laser, or rowhammer-style effects -- can recover an AES key from a handful of faulty ciphertexts [@piret-quisquater-2003]. This is again an implementation and hardware failure, not a cipher failure; the depth belongs to the secure-implementation sibling, but it is a live operational locus wherever an attacker has physical or near-physical access.

The long tail of devices without hardware AES. Constant-time software is slower than AES-NI, and the performance gap quietly tempts developers back toward leaky tables on the smallest parts [@kasper-schwabe-2009]. On many of those devices the pragmatic answer is to ship a constant-time stream cipher such as ChaCha20 instead of fighting AES's software side channels [@xchacha-draft].

Formal verification of protocol state machines, so the next KRACK is caught before it ships. TLS 1.3 was co-designed with formal analysis and has verified component implementations, such as those in the HACL* library [@hacl-2017]. Wi-Fi's SAE was not fully immunized: Dragonblood found downgrade, denial-of-service, and side-channel leaks the authors argue are "inherent to Dragonfly," and even patched software remained affected by a novel leak [@dragonblood-2019]. The state of the art at the protocol layer is better, not finished.

Every open problem here is the same sentence in new clothes: a contract around the permutation is hard to keep in the real world. Which means the practical guide almost writes itself -- it is the thesis made operational, each rule routed to the incident it prevents.

10. What to Do on Monday

Everything above collapses into a short decision procedure and a shorter list of nevers, each rule tied to the incident it prevents.

flowchart TD S["Deploying AES"] --> Q1{"CPU has AES instructions?"} Q1 -->|Yes| HW["Use AES-NI or ARMv8 crypto, enable timing mode on newest cores"] Q1 -->|No| CT["Use constant-time bitsliced software"] HW --> Q2{"Can you guarantee nonce uniqueness?"} CT --> Q2 Q2 -->|Yes| GCM["AES-GCM with deterministic nonces, TLS 1.3 style"] Q2 -->|No| Q3{"Is AES mandated?"} Q3 -->|Yes| SIV["AES-GCM-SIV, misuse-resistant"] Q3 -->|No| XC["XChaCha20-Poly1305, 192-bit nonce"]

The rules behind the tree:

Implementation. Use a library that selects AES-NI or ARMv8 crypto at runtime and falls back to constant-time software; never table-based AES in security code; on the newest cores, be aware the data-independent-timing mode may need to be requested [@intel-aes-ni; @intel-doit]. Prevents Generation 1: cache-timing key recovery.
Mode and nonce. Reliable per-connection counter, as in TLS or QUIC? Use AES-GCM with deterministic nonces [@rfc-8446]. Cannot guarantee uniqueness across restarts, threads, or clones? Use AES-GCM-SIV [@rfc-8452]. Want "a random nonce is always safe" and AES is not mandated? Use XChaCha20-Poly1305 [@xchacha-draft]. Never hand-roll a mode, and never choose your own explicit GCM nonce. Prevents Generation 2: nonce reuse and forgery.
Protocol. Patch WPA2 against key reinstallation or move to WPA3, keep clients updated, and prefer TLS 1.3 over 1.2 [@krack-2017; @rfc-8446]. Prevents Generation 3: handshake-driven nonce rewind.

The single highest-value check you can add to code review is a nonce-reuse detector. It is the exact contract the 184 servers violated, and it fits in a few lines.

{` // Scan a stream of (key, nonce) pairs and flag the first repeat. function findNonceReuse(records) { const seen = new Set(); for (const r of records) { const tag = r.key + "|" + r.nonce; if (seen.has(tag)) return { reused: true, key: r.key, nonce: r.nonce }; seen.add(tag); } return { reused: false }; }

const stream = [ { key: "k1", nonce: "00000001" }, { key: "k1", nonce: "00000002" }, { key: "k1", nonce: "00000001" }, // counter reset after a restart -- the bug ];

console.log(findNonceReuse(stream)); // { reused: true, key: 'k1', nonce: '00000001' } -- catch it in review, not in an incident. `}

Now hold each pitfall up to the mirror. Every one of these confident sentences reproduces a specific, named incident.

The confident mistake	The incident it reproduces	The fix
Table-based AES is fine in security code	Bernstein; Osvik-Shamir-Tromer cache timing [@bernstein-2005; @osvik-shamir-tromer-2006]	AES-NI or constant-time software
Repeating a nonce across restarts, threads, or clones is unlikely to matter	The 184-server GCM forgery scan [@nonce-disrespecting-2016]	AES-GCM-SIV or a disciplined counter
AES-256 is safer against these attacks	Every break here -- key size is irrelevant [@nonce-disrespecting-2016]	Fix the wrapper, not the key size
Constant-time source means constant-time execution	The DOIT/DIT timing caveat [@intel-doit; @biggers-2023]	Enable the timing mode where required
An unpatched WPA2 handshake is good enough	KRACK [@krack-2017]	Patch WPA2 or deploy WPA3

When you review encryption code, find where the nonce comes from and ask exactly one question: can this value repeat across a restart, a fork, a thread, or a clone? If you cannot prove it never repeats, you are reading a latent Generation-2 incident. Reach for AES-GCM-SIV or a 192-bit-nonce AEAD instead of arguing about how improbable a collision seems.

Note: 1. AES-NI or ARMv8 crypto, with a constant-time software fallback. 2. A vetted AEAD -- deterministic-nonce AES-GCM where a per-connection counter is reliable, AES-GCM-SIV where uniqueness is hard, XChaCha20-Poly1305 where AES is not mandated. 3. Patched WPA2 or WPA3, and TLS 1.3 over 1.2.

The checklist is short because the lesson is one sentence. Before restating it, clear the handful of confident, wrong sentences that keep this bug alive in design meetings.

11. Frequently Asked Questions

No. The best publicly known attack on the full cipher, biclique cryptanalysis, costs about $2^{126}$ operations for AES-128 -- a fraction-of-a-bit improvement over brute force with zero practical impact, and its authors say it does "not threaten the practical use of AES in any way" [@biclique-2011]. Every break in this article happened in a layer around the cipher, not in the cipher. Yes -- via cache-timing side channels [@bernstein-2005; @osvik-shamir-tromer-2006]. But that is *not* a break of the cipher. The T-table implementation's memory-access pattern leaked the key; the block permutation did not. Swap the leaky tables for a constant-time implementation and the key stops leaking while AES stays byte-for-byte identical. "Unbroken cipher" and "stolen key" are both true at once. Be precise here. One reuse immediately leaks $P_1 \oplus P_2$ through keystream reuse, and it gives one equation for the GHASH subkey $H$. But *pinning* $H$ for reliable universal forgery generally needs at least two collisions [@joux-2006]. One reuse is already catastrophic -- do not understate it -- but do not say "one reuse recovers the key" either. No. Every break here is implementation, mode, or protocol; key size provides no protection against cache timing, nonce reuse, or a reinstalled handshake key [@nonce-disrespecting-2016]. For the nonce-reuse and handshake breaks AES-256 fails exactly as fast as AES-128; for cache timing it is just as vulnerable, though a longer key takes proportionally more leakage to extract. If someone proposes AES-256 as the fix for any incident in this article, they have misdiagnosed the layer. No. Against AES-CCMP, KRACK forces nonce-reuse decryption and replay, not AES key recovery [@krack-2017]. The especially damaging all-zero-key case was an Android and Linux `wpa_supplicant` implementation bug, not a weakness in AES. No block-math weakness is involved, and no AES key is recovered by the attack itself. No. A padding oracle is a mode-and-validation failure in CBC deployments -- the receiver leaks whether decrypted padding was valid -- and it never touches the AES permutation. It is the same moral as this article (a wrapper broke), in a different deployment, and it is covered in a dedicated padding-oracle sibling. AES itself is not the weak link there either.

Every correction points at the same root: the cipher was never the weak link. Time to say the sentence the whole article was built to earn.

12. To Break AES in the Field, You Never Touch AES

Return to the paradox we opened with, now resolved. The best attack on the full cipher is a fraction-of-a-bit shave with no practical impact [@biclique-2011] -- and yet Wi-Fi sessions were decrypted, HTTPS connections forged, and keys lifted from running servers, because every one of those breaks happened in a wrapper the cipher knows nothing about. The implementation leaked through cache timing [@bernstein-2005; @osvik-shamir-tromer-2006]. The mode's nonce contract was violated on 184 live servers, weaponizing Joux's decade-old forbidden attack into forgery [@nonce-disrespecting-2016; @joux-2006]. The protocol rewound its nonce when a replayed handshake reinstalled a key [@krack-2017]. Three layers, three field breaks, and the 128-bit block math untouched in all three.

And every fix changed how AES is used, never AES: constant-time code and AES-NI at the implementation, misuse-resistant AEAD and derived nonces at the mode, patched handshakes and WPA3 at the protocol [@kasper-schwabe-2009; @rfc-8452; @rfc-8446; @wifi-wpa3-2018]. The cipher is the fixed point; the engineering happened all around it.

A cipher is not a cryptosystem. When your traffic falls, do not ask whether AES broke -- ask which wrapper did: the implementation, the mode, or the protocol.

One last honesty, because the series depends on it. The claim is "almost never," not "never." Scoped to AES, the split is pristine -- the block math never fell in deployment. But some deployed primitives genuinely broke as math: DES's 56-bit key, RC4's keystream biases [@alfardan-2013], and the MD5 and SHA-1 collisions [@shattered-2017]. AES has not joined them, and naming the cases where cryptanalysis won is what keeps the thesis honest rather than triumphant.

The cipher was never the weak link -- and no bigger key would have saved a single one of these systems. That is why this is Part 1 of a series about how things break in real life, not a chapter on block-cipher cryptanalysis. The companion piece, How AES Would Break, takes up the other question: what it would take to move the block itself. This one answered the question that actually decrypts traffic. It was never the cipher. It was the wrapper, every time.

The AEAD Decision Matrix: Seven Ciphers, Three Edges, One Choice

noreply@paragmali.com (Parag Mali) — Thu, 09 Jul 2026 15:04:00 GMT

Every modern AEAD makes the same three promises, and they differ only at the sharp edges where those promises stop. Three edges decide a real deployment: the **nonce contract** (catastrophic on reuse, or misuse-resistant), the **performance and hardware profile** (AES-NI plus CLMUL, constant-time software, or a few thousand gates), and **commitment** (does one ciphertext bind to exactly one key?). "Which AEAD should I use?" is not a ranking from worst to best. It is a function: default to AES-GCM or ChaCha20-Poly1305, and escalate to AES-GCM-SIV, AES-CCM, Ascon, OCB3, or AEGIS only when a specific edge demands it. Every famous break -- invisible salamanders, nonce reuse on live TLS, `CCM_8` forgeries -- was a deployment stepping on an edge, not a broken cipher.

1. Two Failures That Should Have Been Impossible

In 2018, a team of cryptographers handed Facebook a single encrypted file that decrypted to two completely different, perfectly meaningful images, and whose authentication tag verified correctly for both, under two different keys [@dodis2018-salamander]. The cipher was AES-GCM, the internet's default authenticated encryption. Nothing about it was broken. That is the unsettling part: AES-GCM did exactly what it promised. It had just never promised the thing everyone assumed it did.

The result defeated Facebook Messenger's abuse-reporting scheme, which relied on the encrypted attachment being bound to the key that produced it. The authors called their construction "invisible salamanders" [@dodis2018-salamander]. Your reflex on reading this -- "but it is authenticated, so how did the tag pass?" -- is the entire subject of this article. The word "authenticated" carries less than you think.

Now the second failure, because one break only shows one edge. In 2016, researchers scanning the live internet found 184 HTTPS servers reusing a (key, nonce) pair under AES-GCM [@bock2016]. A repeated nonce in GCM is not a hygiene slip that costs you a little margin. It instantly leaks the XOR of the two plaintexts, and -- via an attack Antoine Joux had described to NIST a decade earlier, in 2006 -- it lets an attacker forge arbitrary messages [@joux2006]. The confidentiality half of that failure is easy to see for yourself.

{` // A stream-cipher-style AEAD (GCM, ChaCha20-Poly1305) turns the key+nonce // into a keystream, then XORs it with the plaintext. Reuse the nonce and // you reuse the keystream -- so it cancels out of the XOR of two ciphertexts. const keystream = [0x9e, 0x37, 0xb1, 0xf2, 0x4a]; // same (key, nonce) => same keystream const xor = (a, b) => a.map((x, i) => x ^ b[i]);

const p1 = [...'HELLO'].map(c => c.charCodeAt(0)); const p2 = [...'WORLD'].map(c => c.charCodeAt(0));

const c1 = xor(p1, keystream); // ciphertext 1 const c2 = xor(p2, keystream); // ciphertext 2, SAME nonce

// Attacker sees only c1 and c2, never the key or keystream: const leaked = xor(c1, c2); // == p1 XOR p2, the keystream is gone const recovered = xor(leaked, p2); // and if p2 is ever guessed, p1 falls out console.log('c1 XOR c2 leaks P1 XOR P2:', leaked.join(',')); console.log('recovered P1:', String.fromCharCode(...recovered)); `}

Neither of these was a broken cipher. AES-GCM met its specification in both cases. The salamander bound nothing to a key because AES-GCM was never designed to; the TLS servers leaked plaintext because they violated the one contract GCM cannot survive. Both failures were the same shape: a deployment reached for an AEAD and then stepped on the one sharp edge its designers had moved somewhere the deployment could not avoid.

That is the thesis of this field guide. Authenticated encryption with associated data (AEAD) fused confidentiality and integrity so completely that composing them by hand became a solved problem. The remaining hard problem is choosing among AEADs, and that choice turns on three edges: the nonce contract, the performance and hardware profile, and the commitment axis.

Part 1 of this series defined an AEAD's guarantees as IND-CPA plus INT-CTXT; commitment is a robustness property beyond both. Part 6 showed the padding-oracle cost of the botched integrity AEAD was built to remove.The nonce-reuse breaks are widely mis-cited to CVE-2016-0270. That CVE actually names IBM Domino, and the NVD entry itself warns it has been "incorrectly used for GCM nonce reuse issues in other products" [@cve-2016-0270].

Key idea: "Which AEAD should I use?" is not a ranking. It is a function over three edges: pick the construction whose failure mode your deployment can guarantee it will never trigger. The salamander triggered the commitment edge; the TLS servers triggered the nonce edge. Same lesson, two edges.

If "authenticated" does not mean "bound to one key," and "encrypted" does not survive a repeated nonce, then what exactly does an AEAD promise, and where does each promise stop? To answer that, we have to go back to the moment when "encrypt" and "authenticate" were still two separate calls.

2. From Two Calls to One

Here is a question that sounds trivial and is not: you have a cipher and you have a message authentication code (MAC). In which order do you apply them? Most engineers guess. The wrong guess shipped in SSL, IPsec, and SSH, and it took the field a decade of theory to sort out which guess was which.

There are three orderings. Encrypt-and-MAC authenticates the plaintext and appends the tag beside the ciphertext (SSH). MAC-then-Encrypt authenticates the plaintext, then encrypts plaintext and tag together (SSL and, for years, TLS). Encrypt-then-MAC encrypts, then authenticates the ciphertext (IPsec).

In 2000, Mihir Bellare and Chanathip Namprempre proved these are not interchangeable: only Encrypt-then-MAC generically preserves both privacy and integrity for any secure cipher and any secure MAC [@bn2000]. A year later, Hugo Krawczyk showed the authenticate-then-encrypt method used in SSL is not generically secure while Encrypt-then-MAC is [@krawczyk2001]. Part 6 is the sequel: MAC-then-encrypt is exactly the door a padding oracle walks through.

One keyed call that provides confidentiality of the plaintext, integrity of the plaintext, and integrity (but not secrecy) of an extra header called the associated data. The uniform interface was standardized in RFC 5116 [@rfc5116].

The lesson cut deeper than "pick Encrypt-then-MAC." If two correct primitives can combine into an insecure whole, hand-composition is a footgun no matter how good the parts are. The fix was to make a single primitive own both goals, so no protocol designer could botch the join.

Charanjit Jutla showed the way in 2001 with IAPM and IACBC, modes that delivered message integrity in essentially one pass, almost for free [@jutla2001]. The same year, Phillip Rogaway and coauthors published OCB, a one-pass block-cipher mode built for exactly this [@ocb2001]. Then, in 2002, Rogaway named the primitive: real messages carry a header -- routing bytes, version numbers, sequence counters -- that must be authenticated but not encrypted, because intermediaries need to read it. His "Authenticated-Encryption with Associated-Data" formalized that extra input [@rogaway2002-ad].

The header bytes an AEAD authenticates but does not encrypt: routing information, protocol versions, sequence numbers. Tampering with the associated data makes tag verification fail, but the associated data itself travels in the clear [@rogaway2002-ad].

By 2008, David McGrew closed the loop with RFC 5116, which defined the universal interface every construction in this article implements: AEAD-Encrypt(key, nonce, associated_data, plaintext) returns ciphertext || tag, and the matching decrypt either returns the plaintext or a single, uninformative failure [@rfc5116]. One call in, one call out, no way to reverse the order of two primitives because there is only one primitive.

A value that must be unique for every encryption under a given key. The mode, not the label, sets the exact requirement: some AEADs tolerate only uniqueness, others tolerate randomness, and a few tolerate repetition. Nonce generation is the subject of Part 2 of this series. timeline title The road to the AEAD portfolio 2000 : Encrypt-then-MAC proven the safe order 2001 : IAPM and OCB, single-pass native AE 2002 : Rogaway names AEAD and adds associated data 2003 : CCM standardized in RFC 3610 2004 : GCM published by McGrew and Viega 2006 : Joux forbidden attack, SIV misuse-resistance 2008 : RFC 5116 fixes the universal interface 2013 : CAESAR opens, AEGIS announced 2016 : Nonce reuse found on live TLS servers 2018 : Invisible salamanders break message franking 2019 : CAESAR portfolio chosen, OCB2 broken 2021 : Partitioning oracles weaponize non-commitment 2025 : NIST standardizes Ascon-AEAD128

The interface was settled by 2008. But an interface is a promise about shape, not about sharp edges. Two constructions that satisfy AEAD-Encrypt to the letter can fail in completely different ways, and the very first AEADs to ship proved it. The one that reached the most devices did not even win on technical merit. It won because of a patent.

3. The Welded Modes: CCM and GCM

The first AEAD to reach a billion devices was not chosen by a cryptographer. It was chosen, in effect, by a patent lawyer. When IEEE 802.11i (the security amendment that became WPA2) needed an authenticated mode, the elegant candidate was OCB -- but OCB was patent-encumbered, and the working group would not build a wireless standard on it. So 802.11i standardized the plodding, unpatented alternative: AES-CCM. By device count, that decision made CCM one of the most widely deployed AEADs in the world.

AES-CCM = Counter mode + CBC-MAC. Doug Whiting, Russ Housley, and Niels Ferguson specified it in RFC 3610 in 2003, and NIST blessed it as SP 800-38C the next year [@rfc3610][@sp80038c]. It runs the message through CBC-MAC for the tag, then encrypts with counter (CTR) mode: two passes, a strictly serial MAC, and the message length needed up front, which makes streaming awkward. What that price buys is frugality -- nothing but AES, a tiny code footprint, no second primitive to implement.

That profile is why CCM owns the constrained niche -- Bluetooth Low Energy [@bluetooth-core], Zigbee [@ieee802154], and the TLS CCM_8 ciphersuites. IEEE 802.11i also made CCMP the mandatory data-confidentiality protocol for WPA2 [@ieee80211i], and CCM rode WPA2/CCMP into the overwhelming majority of Wi-Fi hardware over the following decade.Zigbee and 802.15.4 use a variant called CCM*, which additionally permits integrity-only or encryption-only operation, unlike the strict RFC 3610 CCM that always does both. So the same plodding, all-AES mode anchors two very different worlds: the smallest constrained devices and the Wi-Fi layer that WPA2 secures. These are the building blocks from Part 5, welded to a MAC.

AES-GCM = Counter mode + GHASH. David McGrew and John Viega published Galois/Counter Mode in 2004, and NIST standardized it as SP 800-38D in 2007 [@mcgrew2004-gcm][@sp80038d]. GCM is everything CCM is not: one pass, fully parallelizable, and, on any CPU with AES-NI and CLMUL, blisteringly fast. It is the internet default, and AES-128-GCM is the single mandatory-to-implement (MUST) AEAD cipher suite in TLS 1.3, per RFC 8446 Section 9.1 -- a status the spec grants to no other AEAD [@rfc8446]. To understand every later failure, you need one fact about how its tag works.

An authenticator of the form $\text{tag} = H_k(\text{message}) + s$, where $H_k$ is a fast keyed universal hash and $s$ is a **one-time** secret mask. It is unforgeable only if $s$ is never reused. Repeat the mask and the algebraic structure of $H_k$ leaks. This is the shared root of both GHASH (AES-GCM) and Poly1305 (ChaCha20-Poly1305) [@bernstein-poly1305].

GCM's tag is a one-time Wegman-Carter MAC. GHASH evaluates a polynomial over the finite field $\mathrm{GF}(2^{128})$, with the ciphertext and associated-data blocks as coefficients, at a single secret point $H = \operatorname{AES}_k(0^{128})$. It then masks the result with a per-nonce keystream block:

$$T = \operatorname{GHASH}_H(A, C) \oplus \operatorname{AES}_k(J_0), \qquad H = \operatorname{AES}_k(0^{128})$$

where $J_0$ is the initial counter block derived from the nonce. The mask $\operatorname{AES}_k(J_0)$ is the one-time secret $s$. It is one-time only because the nonce is unique. Repeat the nonce and you repeat $J_0$, so you repeat the mask, and now two tags share it -- which turns GHASH's linear structure into a system of polynomial equations an attacker can solve.

The universal hash inside AES-GCM: a polynomial in the secret point $H = \operatorname{AES}_k(0^{128})$ evaluated over $\mathrm{GF}(2^{128})$. Because the polynomial is linear in its coefficients, recovering $H$ lets an attacker forge tags for chosen messages [@joux2006]. flowchart LR N["Nonce and counter"] --> CTR["AES counter mode"] K["Key"] --> CTR CTR --> KS["Keystream"] P["Plaintext"] --> X(("XOR")) KS --> X X --> C["Ciphertext"] C --> GH["GHASH polynomial at secret point H"] AD["Associated data"] --> GH K --> H["H is AES of the zero block"] H --> GH GH --> M(("XOR one-time mask")) K --> J["AES of the first counter block"] J --> M M --> T["Authentication tag"]

That single design choice hands GCM two sharp edges the rest of this article pays for. The first is the nonce contract: reuse is not a weakness, it is a detonator.

Note: For every nonce-respecting AEAD -- AES-GCM, ChaCha20-Poly1305, AES-CCM, OCB3, AEGIS, and Ascon -- one repeated (key, nonce) pair is an immediate, total break of confidentiality for those two messages, and, with a second collision, of authenticity for the whole key [@joux2006].One nonce collision leaks $P_1 \oplus P_2$ right away. Uniquely pinning the secret point $H$ for universal forgery generally needs at least two collisions, since a single pair of equations leaves multiple candidate roots. "One repeat is game over for those messages" is correct; "one repeat exposes $H$" is not quite [@bock2016].

The second edge is quieter and just as dangerous, because it is two different numbers people constantly merge into one.

Note: SP 800-38D fixes a per-message plaintext limit of $2^{39}-256$ bits (about 64 GiB), set by 32-bit counter-mode block-space exhaustion, and, separately, a per-key invocation cap of roughly $2^{32}$ messages when nonces are random 96-bit values, driven by the birthday bound on nonce collision [@sp80038d]. These are two different mechanisms, not two readings of one bound (the full derivation is in Section 8). The multi-user bounds that justify TLS 1.3's nonce randomization are tight [@htt2018-gcm]. Enforce both limits. Conflating them is the single most common accuracy error on this primitive.

GCM gave the internet a one-pass, hardware-fast AEAD, and in the same stroke handed it a mode where one repeated nonce is not a bug but a catastrophe. This is the same GCM negotiated inside shipping Windows protocols such as Schannel TLS and SMB 3 encryption [@ms-schannel-tls][@ms-smb-encryption]. Antoine Joux saw the danger in 2006 [@joux2006]. It took the rest of the world ten years, and a scan of the live internet, to believe him.

4. A Trunk With Branches

The family tree of AEAD is not a ladder from worst to best. Draw it that way and none of the modern constructions make sense, because none of them strictly dominates GCM. Draw it correctly and the whole field snaps into focus: it is a trunk with branches. The trunk is linear -- generic composition, then single-pass native AE, then the welded deployed modes CCM and GCM. Then, at GCM, the tree splits, because GCM's edges each forced a separate successor. No later generation wins. That is the entire point.

flowchart TD G0["Generic composition, Encrypt-then-MAC"] --> G1["Single-pass native AE, IAPM and OCB"] G1 --> G2["Welded deployed modes, CCM and GCM"] G2 --> E1["Nonce edge"] G2 --> E2["Hardware edge"] G2 --> E3["Commitment edge"] E1 --> S1["SIV and AES-GCM-SIV, misuse-resistant"] E2 --> S2["ChaCha20-Poly1305, constant-time in software"] E2 --> S4["AEGIS and Ascon, hardware and footprint co-design"] E3 --> S3["Committing transforms, added on top"]

The hardware edge: ChaCha20-Poly1305

GHASH is hard to make constant-time without the CLMUL instruction, and table-based AES is both slow and timing-leaky without AES-NI. Around 2013, that was the reality on most phones and ARM chips: no AES hardware, so GCM was either slow or a cache-timing side channel. Daniel Bernstein's answer kept GCM's exact nonce-respecting contract but threw out the parts that needed special silicon.

ChaCha20 is an ARX cipher -- addition, rotation, XOR -- with no S-box tables to leak timing, so it is constant-time by construction [@bernstein-chacha]. Poly1305 is a one-time Wegman-Carter MAC over a prime field rather than $\mathrm{GF}(2^{128})$, and its one-time key is derived from a ChaCha keystream block [@bernstein-poly1305].Poly1305's one-time key comes from a ChaCha-derived block, not from AES. ChaCha20-Poly1305 never calls AES at all -- a common misconception, since GCM's mask does use AES.

The IETF standardized the pair as an AEAD in RFC 8439 [@rfc8439], and it now protects TLS 1.3, WireGuard, OpenSSH, and the age file-encryption tool [@wireguard-protocol][@openssh-chacha][@age-spec]. Its normative status is widely overstated: in TLS 1.3, ChaCha20-Poly1305 is a recommended (SHOULD) cipher suite, not mandatory-to-implement, per RFC 8446 Section 9.1 -- a default by adoption, not by requirement [@rfc8446]. It is not weaker than GCM; it is the same nonce contract on a different, table-free engine.XChaCha20-Poly1305 extends the nonce to 192 bits, large enough that random nonces essentially never collide. That is a mitigation of nonce-collision anxiety, not misuse-resistance -- reuse the full 192-bit nonce and it fails exactly like GCM.

The nonce edge: misuse-resistance and SIV

Every mode so far detonates on a repeated nonce, and reuse keeps happening in the real world: cloned virtual machines that resume with identical RNG state, counters reset by a crash, embedded devices with weak entropy at first boot. If the operator cannot guarantee uniqueness, the fix is a mode that survives the operator's mistake. In 2006, Phillip Rogaway and Thomas Shrimpton formalized exactly that goal and built the first construction for it [@rs2006].

An AEAD whose failure under a repeated nonce is graceful, not catastrophic. Repeating a `(key, nonce, associated_data, plaintext)` tuple leaks only whether two encryptions were of the *same* message -- message equality -- and nothing else. It never leaks a plaintext XOR and never hands over the authentication subkey [@rs2006][@rfc8452].

The mechanism is a single clean idea: derive the initialization vector synthetically, as a pseudorandom function of the entire message, rather than accepting it from the caller. The tag is the IV.

A construction in which the initialization vector is computed as a MAC over the associated data and the full plaintext, then reused as the authentication tag. Two different messages under a repeated nonce produce different synthetic IVs, so their keystreams differ and nothing leaks [@rs2006]. flowchart TD K["Key"] --> MAC["MAC over associated data and full plaintext"] AD["Associated data"] --> MAC N["Nonce"] --> MAC P["Plaintext"] --> MAC MAC --> IV["Synthetic IV, which is also the tag"] IV --> CTR["Counter-mode encryption"] K --> CTR P --> CTR CTR --> C["Ciphertext"] IV --> T["Tag sent alongside ciphertext"]

That picture also explains the price, which returns as a theorem in Section 8: to compute the IV you must read the whole message first, so SIV cannot emit its first ciphertext byte until it has seen the last plaintext byte. It is inherently two-pass.

Two deployable forms exist. AES-SIV, standardized by Dan Harkins in RFC 5297, targets deterministic authenticated encryption and key wrapping [@rfc5297]. AES-GCM-SIV, from Shay Gueron, Adam Langley, and Yehuda Lindell in RFC 8452, keeps AES-NI and CLMUL speed while adding misuse-resistance, building on the Gueron-Lindell GCM-SIV design [@rfc8452][@gl2015-gcmsiv].AES-GCM-SIV hashes with POLYVAL, a little-endian sibling of GHASH, and derives a fresh message-authentication and encryption key per nonce -- a structure whose tight multi-user bounds were later established by Bose, Hoang, and Tessaro [@bht2018].

"...two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated." -- RFC 8452 [@rfc8452]

Read that phrasing carefully, because it is the most misquoted sentence about SIV. "Do not fail catastrophically" is not "do not fail." A repeated nonce in AES-GCM-SIV still leaks message equality: an attacker learns that two ciphertexts encrypt the same plaintext, which is a real and sometimes serious leak. SIV makes reuse survivable, never free.

The elegance detour: OCB3 and the patent that chose a standard

Two edges now had answers, each on its own branch. A third construction sits off to the side -- not because it is worse, but because history was unkind to it. OCB3, finalized by Ted Krovetz and Phillip Rogaway in 2011 and standardized as RFC 7253, is arguably the most elegant AEAD ever standardized: one block-cipher key, one pass, fully parallel, roughly one cipher call per block [@kr2011-ocb3][@rfc7253].

Its mechanism is where the elegance lives. Each block is masked by a key-derived offset -- $\text{Offset}i = \text{Offset}{i-1} \oplus L_{\text{ntz}(i)}$, a Gray-code walk over precomputed $L$ values -- and wrapped as $C_i = \text{Offset}_i \oplus \operatorname{ENCIPHER}(K, P_i \oplus \text{Offset}_i)$, while a single running plaintext checksum, $\text{Checksum} = P_1 \oplus P_2 \oplus \cdots$, produces the tag in the same pass [@rfc7253]. No second key, no separate MAC. It matches or beats GCM in software. And it lost anyway -- not for a technical reason.A widely repeated claim is that OCB3 is inverse-free. It is not. OCB-DECRYPT recovers each block as $P_i = \text{Offset}_i \oplus \operatorname{DECIPHER}(K, C_i \oplus \text{Offset}_i)$, calling the block-cipher inverse $E_K^{-1}$ (RFC 7253 Section 4.3), so a hardware implementation needs both the AES encrypt and decrypt circuits [@rfc7253]. Inverse-free is the property of the CTR, stream, and sponge modes -- AES-GCM, AES-CCM, ChaCha20-Poly1305, AEGIS, and Ascon -- and OCB is precisely the lineage that trades it away for single-primitive elegance.

OCB was patented from birth. When the 802.11i working group picked WPA2's cipher in 2003, it passed over OCB precisely because of those patents and chose the unencumbered CCM instead. Rogaway later granted free licenses for open-source and non-military use, but the damage was done: every major protocol had already standardized on GCM and ChaCha20-Poly1305 in the years the patents were live. In 2021 Rogaway released OCB into the public domain outright -- too late to matter [@kr2021-ocb]. The honest answer to "when should I reach for OCB3 in 2026?" is "almost never, and the reason is a patent grave, not a design flaw."

The dead end: OCB2 and the limits of "provably secure"

There is one more branch, and it is a warning. Between OCB1 and OCB3 sat OCB2, an ISO-standardized refinement with a security proof. In 2019, Akiko Inoue, Tetsu Iwata, Kazuhiko Minematsu, and Bertram Poettering broke it outright: universal forgery and full plaintext recovery, because OCB2 used the XEX* tweakable cipher outside the regime its proof actually covered [@inoue2019-ocb2].

The OCB2 break is the cautionary counterpoint to every "but it has a proof" argument. OCB2 was standardized by ISO/IEC and carried a published security proof, and it was still broken end to end. A proof secures a *model*; if the construction steps outside the model's assumptions, the proof guarantees nothing. Tellingly, the same attack left OCB1 and OCB3 untouched [@inoue2019-ocb2] -- a dead-end twig on a branch whose siblings survived.

Two of GCM's three edges now had dedicated successors, and the family tree looked complete. But every construction so far -- GCM, ChaCha20-Poly1305, even the misuse-resistant SIV family -- quietly shared a third assumption nobody had thought to check: that "authenticated" meant "bound to one key." In 2018, that assumption broke in production, on the desk of a Facebook security engineer holding a single file with two faces.

5. The Commitment Reckoning and the CAESAR Crucible

Now we can explain the salamanders. Recall the mechanism from Section 3: a GCM tag is a one-time Wegman-Carter value, $\operatorname{GHASH}_H(A,C) \oplus \operatorname{AES}_k(J_0)$, and GHASH is linear in its coefficients. An attacker who gets to pick two keys, $k_1$ and $k_2$, can treat "make the tag verify under both" as a system of linear equations over $\mathrm{GF}(2^{128})$ and simply solve it, producing one ciphertext that decrypts to two chosen, meaningful plaintexts and passes verification under each key [@dodis2018-salamander].

Nothing is broken. GCM guarantees confidentiality and integrity; it never promised that a ciphertext binds to a single key. That promise has a name, and until 2018 almost nobody was asking for it.

A graded robustness property beyond confidentiality and integrity. CMT-1 means a ciphertext binds to exactly one *key*; CMT-4 means it binds to the full *context* -- key, nonce, associated data, and message. Bellare and Hoang proved that CMT-1 does not imply CMT-4: committing to the key is strictly weaker than committing to everything [@bh2022-commit]. RFC 9771 standardized the vocabulary [@rfc9771].

Key idea: "Authenticated" never meant "committed." An AEAD's guarantees -- IND-CPA plus INT-CTXT -- say nothing about binding a ciphertext to one key. Commitment is a third, orthogonal axis. That is why every default AEAD was non-committing and nobody noticed for fifteen years: the property was simply outside the definition everyone was proving.

Two ideas define the modern state of the art, and both come from refusing to treat "cipher plus separate hash" as the end of the design space.

The first is robustness as an explicit goal -- against the operator and against the adversary who supplies the key. The operator side is MRAE from Section 4, elevated from a mode into a principle. The adversary side is committing AEAD, and its timeline is a tidy example of a theoretical curiosity becoming an operational threat.

Invisible salamanders (2018) showed a non-committing AEAD could defeat message franking [@dodis2018-salamander]. Then, in 2021, Julia Len, Paul Grubbs, and Thomas Ristenpart turned it into a weapon: partitioning oracle attacks use the missing commitment to recover passwords and other low-entropy keys, crafting one ciphertext that decrypts under many candidate keys and using each success or failure to bisect the key space [@len2021-partition].

Mihir Bellare and Viet Tung Hoang then built the graded CMT-1 through CMT-4 theory and cheap transforms that add full commitment with no ciphertext-size increase [@bh2022-commit]; Ange Albertini and coauthors independently catalogued the abuses and a padding-based fix [@albertini2022], with further theory from John Chan and Phillip Rogaway [@chan2022]. Sanketh Menda and coauthors then showed the gap is portfolio-wide, with context-discovery attacks against CCM, EAX, SIV, GCM, and OCB3 [@menda2023]. RFC 9771 (2025) finally fixed the vocabulary the field had been improvising [@rfc9771].

A vetted AEAD gives you confidentiality and integrity and stops there. Commitment is a third axis nobody put in the definition -- which is exactly why one ciphertext could wear two faces.

The second idea is native co-design: stop bolting a cipher to a hash and instead build the AEAD around the hardware or footprint you actually have. Hongjun Wu and Bart Preneel's AEGIS (2013) is the AES-hardware extreme [@wu2013-aegis].

It keeps a large internal state -- eight 128-bit words in AEGIS-128L -- seeded directly from the key and nonce; the AES round function updates that state as it absorbs associated data and plaintext, encryption squeezes a keystream out of the state, and the tag comes from the finalized state. One primitive, one pass, no separate hash, and the IETF draft records that all variants are inverse-free and built from the AES encryption round [@aegis-draft18].

That structure is why AEGIS outruns GCM on AES silicon, and why nonce reuse is catastrophic: the whole state is a function of (key, nonce), so a repeat lets an attacker unwind it. Its commitment story is a nuance, not a headline -- a 128-bit AEGIS tag delivers only about 64-bit committing security, while a 256-bit tag pushes cross-key collisions out of reach, so AEGIS is partially committing by tag length, neither fully committing nor flatly broken [@aegis-draft18].

At the other extreme, Ascon -- by Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer -- uses a single lightweight permutation in a sponge, giving a tiny gate count and a side-channel-friendly structure for constrained hardware [@ascon2021].

flowchart LR KN["Key and nonce"] --> ST["Large internal state, eight 128-bit words"] ST --> UP["AES round function update"] AD["Associated data"] --> UP P["Plaintext"] --> UP UP --> KS["Squeezed keystream"] P --> X(("XOR")) KS --> X X --> C["Ciphertext"] UP --> FIN["Finalized state"] FIN --> T["Authentication tag"] A mode built from one public permutation whose state is split into a "rate" (absorbs input and is squeezed for output) and a "capacity" (the hidden security margin). A single permutation absorbs the key, nonce, associated data, and plaintext, then squeezes keystream and a tag -- no separate cipher and hash. Ascon is a sponge [@ascon2021].

What forced this whole portfolio into existence was a contest. The CAESAR competition (2013-2019), organized by Daniel Bernstein, was a public, multi-year, break-it-in-the-open bake-off [@caesar-home]. Its most important decision was structural: rather than crown a single winner, it selected a portfolio across three use cases -- itself the thesis of this article. The winners were Ascon and ACORN for lightweight use, AEGIS-128 and OCB for high-performance use, and Deoxys-II (first choice) and COLM for defense in depth [@caesar-portfolio].Deoxys-II is built on the TWEAKEY framework for tweakable block ciphers, by Jérémy Jean, Ivica Nikolić, Thomas Peyrin, and Yannick Seurin [@caesar-portfolio].

Note carefully: Deoxys-II is a CAESAR winner, not an also-ran -- it simply was never deployed at scale. The real also-rans are the candidates eliminated during the competition, including MORUS, which took a certificational break from Tomer Ashur, Maria Eichlseder, and coauthors and did not make the final portfolio [@morus2018].

The competition ended in 2019 with no single champion, on purpose. So where does that leave a working engineer in 2026, staring at seven names in a crypto library's documentation? To choose well, you need the current map: exactly what each construction is, where it wins, and where it bites.

6. The 2026 Portfolio, Precisely

The current portfolio has a stable shape: two defaults and five specialists. By deployment, the two internet defaults are AES-GCM and ChaCha20-Poly1305 -- but normatively they are not equals. In TLS 1.3 only AES-128-GCM is mandatory-to-implement (MUST); AES-256-GCM and ChaCha20-Poly1305 are both recommended (SHOULD), the same normative level as each other, per RFC 8446 Section 9.1 [@rfc8446]. Everything else is a deliberate escalation. Here is each construction on its edges.

AES-GCM. Counter mode plus a one-time GHASH tag; one pass, parallel, O(1) online state [@mcgrew2004-gcm]. Excels on any CPU with AES-NI and CLMUL, which is every server and most modern clients. Struggles on hardware without those instructions and, above all, on nonce discipline: reuse is fatal and the two ceilings are easy to breach [@sp80038d]. Adoption: the internet default.

ChaCha20-Poly1305. ARX stream cipher plus a prime-field one-time MAC; constant-time in pure software with no lookup tables [@rfc8439]. Excels precisely where GCM struggles -- phones, embedded ARM, any target without AES hardware. Same nonce contract as GCM, so it struggles on the exact same reuse cliff. Adoption: TLS 1.3, WireGuard, OpenSSH [@wireguard-protocol][@openssh-chacha].

AES-CCM. Counter mode plus CBC-MAC; two passes, serial, needs the length up front, but all-AES and tiny [@rfc3610]. Excels in constrained stacks (BLE [@bluetooth-core], Zigbee [@ieee802154]) and inside WPA2 [@ieee80211i]. Struggles on throughput and streaming, and the truncated CCM_8 tag trades a real forgery budget for eight bytes [@rfc3610]. Adoption: enormous by device count.

AES-GCM-SIV and AES-SIV. Synthetic-IV misuse-resistant modes; two-pass by necessity [@rfc8452][@rfc5297]. Excel when nonce uniqueness cannot be guaranteed: reuse degrades to leaking message equality rather than catastrophe. Struggle on streaming (they must buffer) and still leak equality, so they are survivable, not free. AES-GCM-SIV runs near AES-GCM speed on server hardware, around 0.92 cycles per byte on Broadwell in the original design [@gl2015-gcmsiv]. Adoption: growing where reuse risk is real.

OCB3. One block-cipher key, one pass, fully parallel, roughly one cipher call per block -- technically superb [@kr2011-ocb3][@rfc7253]. Excels on elegance and software speed. Struggles on adoption, for the patent reasons in Section 4; it is nonce-respecting like GCM; and, unlike the CTR and stream modes, it is not inverse-free -- decryption calls the AES inverse circuit (RFC 7253 Section 4.3), a genuine hardware cost [@rfc7253]. Adoption: minimal, despite standardization.

AEGIS. Keystream and authentication driven straight from the AES round function over a large nonce-seeded state; the throughput frontier, around 0.48 cycles per byte for AEGIS-128L on 4 KB messages, faster than CCM, GCM, and OCB [@wu2013-aegis][@aegis-v11]. Excels on raw speed when you control both endpoints. Struggles on maturity and contract: nonce-respecting (catastrophic on reuse, since its whole state is nonce-seeded) and only partially committing -- about 64-bit committing security at a 128-bit tag, stronger at a 256-bit tag [@aegis-draft18].

Critically, AEGIS is still an active Internet-Draft, draft-irtf-cfrg-aegis-aead-18 from October 2025, not an RFC -- it states plainly that it "is not an IETF product and is not a standard," and it expires on 8 April 2026 [@aegis-draft18].

Ascon-AEAD128. A single 320-bit lightweight permutation in a sponge; tiny state, side-channel-friendly [@ascon2021]. Excels on constrained hardware and gate count. Struggles on server throughput, where AEGIS and GCM win. It is nonce-respecting, but -- unlike the CTR and stream modes -- it commits to its inputs without any added transform: the tag is squeezed from the sponge's large hidden capacity after that capacity has already absorbed the key, so one ciphertext binds natively to the key it was produced under. RFC 9771 lists Ascon-AEAD128 as both key-committing and full-committing as-is, not merely as a candidate for a bolt-on fix [@rfc9771]. The currency fact matters here: NIST SP 800-232 is final (August 2025) and standardizes Ascon-AEAD128, a tweaked variant of CAESAR Ascon-128 using a larger data-absorption rate -- widely reported as 128-bit, up from the CAESAR design's 64-bit, with the exact parameter in the SP 800-232 body [@sp800232][@nist-ascon-2023]. It is not byte-identical to CAESAR Ascon [@ascon-site].

A profile only helps if you can actually call the construction, so here is where each one ships as of mid-2026, with each cell cited to that project's official documentation.

Construction	Where it ships (libraries and frameworks)
AES-GCM	OpenSSL/BoringSSL [@openssl-aes][@boringssl-aead], Go `crypto/cipher` [@go-cipher], Java JCA [@java-jca], .NET CNG [@dotnet-aesgcm], WebCrypto (the only AEAD in the browser) [@webcrypto], libsodium (hardware-gated) [@libsodium-aegis]
ChaCha20-Poly1305 / XChaCha20	OpenSSL/BoringSSL [@openssl-chacha][@boringssl-aead], libsodium (default for random-nonce APIs) [@libsodium-aegis], Go `x/crypto` [@go-chacha], WireGuard [@wireguard-protocol], OpenSSH [@openssh-chacha], `age` [@age-spec]
AES-CCM	mbedTLS [@mbedtls-ccm], wolfSSL [@wolfssl-ccm], Wi-Fi [@ieee80211i] / BLE [@bluetooth-core] / Zigbee [@ieee802154] firmware
AES-GCM-SIV	BoringSSL/OpenSSL [@boringssl-aead][@openssl-aes] and several bindings; less universal than the defaults
AES-SIV	`miscreant`-lineage (deterministic / key-wrap) libraries [@miscreant]
OCB3	some libraries (public domain since 2021 [@kr2021-ocb]); rarely a default
AEGIS	libsodium (`crypto_aead_aegis128l` / `aegis256`) [@libsodium-aegis] and a growing set of high-performance libraries; not a TLS suite
Ascon-AEAD128	reference and third-party implementations [@ascon-site]; adoption ramping since SP 800-232 [@sp800232]

Two entries on that map decide real architectures. In the browser, AES-GCM is the only AEAD you can call.WebCrypto's SubtleCrypto.encrypt recognizes RSA-OAEP, AES-CTR, AES-CBC, and AES-GCM, and AES-GCM is the only one of those that authenticates. Browser JavaScript that needs an AEAD without bundling a crypto library therefore has exactly one option [@webcrypto]. And AEGIS, still pre-RFC, is nonetheless callable in production today through libsodium's crypto_aead_aegis128l and crypto_aead_aegis256 APIs -- deployability and standardization are not the same axis [@libsodium-aegis].

Note: Eight constructions -- the seven cipher families, with the SIV line counted in its two deployable forms (AES-GCM-SIV and AES-SIV) -- all linear-time, all vetted, and not one strictly dominates the others. CAESAR chose a portfolio across three use cases on purpose, and NIST added Ascon for the constrained end. There is no "best AEAD," and any article or vendor that names one is hiding an assumption about your deployment [@caesar-portfolio].

Two more items complete the 2026 map. The CAESAR defense-in-depth winners, Deoxys-II and COLM, remain excellent and essentially undeployed [@caesar-portfolio]. And committing transforms -- the fix for the commitment edge -- exist and are cheap, but as of mid-2026 none is mandated in a shipping standard; RFC 9771 supplies vocabulary, not a required construction [@rfc9771][@bh2022-commit].

Laid side by side, those eight look interchangeable. They are not, and the tool that makes the difference legible is a single table built on the three edges.

7. The Decision Matrix

This is the one screen to memorize. Everything in the previous six sections collapses into two tables and a flowchart, all built on the same three edges.

The first table answers the only question that matters at selection time: for each construction, what happens on the first repeated nonce, what hardware does it want, and does one ciphertext bind to one key?

Construction	First repeated nonce	Hardware profile	Commitment
AES-GCM	Catastrophic: leaks P1 XOR P2, enables forgery	AES-NI + CLMUL fast	Not committing
ChaCha20-Poly1305	Catastrophic: same one-time-MAC cliff	Constant-time in software	Not committing
AES-CCM	Catastrophic	All-AES, tiny footprint	Not committing
AES-GCM-SIV	Graceful: leaks message equality only	AES-NI + CLMUL	Not committing
AES-SIV	Graceful: leaks message equality only	All-AES, two-pass	Not committing
OCB3	Catastrophic	Fast one-pass software	Not committing
AEGIS	Catastrophic	AES round function, fastest	Not fully committing
Ascon-AEAD128	Catastrophic	A few thousand gates	Committing from the sponge, no transform

Read down the commitment column and the reckoning of Section 5 gets sharper than a flat "nobody commits." Every deployed CTR, stream, and welded construction -- AES-GCM, ChaCha20-Poly1305, AES-CCM, the SIV family, and OCB3 -- is non-committing by default, which is exactly what the salamander and the portfolio-wide context-discovery attacks exploit [@dodis2018-salamander][@menda2023]. Two constructions break the pattern, and it is no accident that both fuse the tag with the cipher state instead of bolting on a separate hash: AEGIS partially commits through tag length, and Ascon commits natively from its sponge [@aegis-draft18][@rfc9771]. So commitment is not a uniform failure across the portfolio -- the commitment edge is a real axis of variation, with Ascon at the strong end, AEGIS in between, and the CTR, stream, and welded modes needing a bolt-on transform. Read the nonce column and only the SIV family survives a repeat, and only by leaking equality [@rfc8452]. The second table adds the structural and performance facts you need once the edges are settled.

Construction	Passes / parallel	Online state	Nonce	Tag	Reported speed	Inverse-free?	Best suited for
AES-GCM	1 pass, parallel	`O(1)`	96-bit	128-bit	~1 cpb with AES-NI	Yes	The default, server and client
ChaCha20-Poly1305	1 pass	`O(1)`	96-bit	128-bit	Fast in pure software	Yes	Targets without AES hardware
AES-CCM	2 pass, serial	`O(1)`	7 to 13 byte	128-bit (`CCM_8`: 64)	Modest	Yes	Constrained stacks, WPA2
AES-GCM-SIV	2 pass	`O(n)` buffered	96-bit	128-bit	~0.92 cpb on Broadwell	Yes	Nonce-reuse risk
AES-SIV	2 pass	`O(n)` buffered	None or supplied	128-bit	Modest	Yes	Key wrap, deterministic AE
OCB3	1 pass, parallel	`O(1)`	up to 120-bit	up to 128-bit	Fast in software	No (needs AES decrypt)	Elegance (now patent-clear)
AEGIS	1 pass, parallel	`O(1)`	128 or 256-bit	128 or 256-bit	~0.48 cpb (AEGIS-128L)	Yes	Maximum throughput, both endpoints
Ascon-AEAD128	1 pass	`O(1)`	128-bit	128-bit	Small, not server-fast	Yes	New constrained designs

Reported speeds are platform-dependent and should be read against live cross-platform benchmarks rather than a single headline number; the AEGIS and GCM-SIV figures come from their design papers, and the ECRYPT benchmarking project tracks the rest across many CPUs [@wu2013-aegis][@gl2015-gcmsiv][@bench-aead]. One column earns a second look: OCB3 is the only full-treatment construction that is not inverse-free, so it alone needs the AES decrypt circuit in hardware -- the honest cost behind its elegance [@rfc7253].

The tables classify. To choose, turn them into a procedure. The flowchart below is the thesis rendered as a decision tree: branch on the nonce guarantee first (it is the edge that fails hardest), then on hardware, and treat commitment as an orthogonal final step because no default provides it.

flowchart TD Q1{"Can you guarantee a unique nonce per key?"} Q1 -->|No| SIV["AES-GCM-SIV: move on the nonce edge"] Q1 -->|Yes| Q2{"AES-NI and CLMUL on both endpoints?"} Q2 -->|Yes| GCM["AES-GCM"] Q2 -->|No| Q2b{"Server or mobile software, or a constrained device?"} Q2b -->|Software| CC["ChaCha20-Poly1305"] Q2b -->|Constrained| ASC["Ascon-AEAD128"] SIV --> Q3{"Must one ciphertext bind to exactly one key?"} GCM --> Q3 CC --> Q3 ASC --> Q3 Q3 -->|Yes| ADD["Add a key-commitment transform, unless it already commits like Ascon"] Q3 -->|No| DONE["Ship it"]

The argument is now explicit and testable. "Which AEAD?" reduces to "which edge can your deployment guarantee it never triggers?" If you cannot guarantee nonce uniqueness, move right on the nonce edge to the SIV family. If you have no AES hardware, move on the hardware edge to ChaCha20-Poly1305 or, for a constrained device, Ascon. If a ciphertext must bind to exactly one key, you must add something on the commitment edge, because none of the defaults gives it to you. You can even write the function down.

{` // "Which AEAD?" is a function of three edges, not a ranking. function chooseAEAD({ nonceUnique, hasAesHardware, constrained, mustCommitToKey }) { let pick; if (!nonceUnique) { pick = 'AES-GCM-SIV'; // edge 1: cannot guarantee unique nonces } else if (hasAesHardware) { pick = 'AES-GCM'; // the internet default when AES-NI + CLMUL are present } else if (constrained) { pick = 'Ascon-AEAD128'; // edge 2: no AES hardware, only a few thousand gates } else { pick = 'ChaCha20-Poly1305'; // edge 2: no AES hardware, constant-time in software } // edge 3 is orthogonal: most picks do not commit, so you must ADD a transform -- // except Ascon, which already commits natively from its sponge (RFC 9771). const alreadyCommits = pick === 'Ascon-AEAD128'; return (mustCommitToKey && !alreadyCommits) ? pick + ' + key-commitment transform (this construction does not bind to one key)' : pick; }

console.log(chooseAEAD({ nonceUnique: true, hasAesHardware: true, constrained: false, mustCommitToKey: false })); console.log(chooseAEAD({ nonceUnique: false, hasAesHardware: true, constrained: false, mustCommitToKey: false })); console.log(chooseAEAD({ nonceUnique: true, hasAesHardware: false, constrained: false, mustCommitToKey: false })); console.log(chooseAEAD({ nonceUnique: true, hasAesHardware: true, constrained: false, mustCommitToKey: true })); `}

"Which AEAD should I use?" is not a ranking from worst to best. It is a function: pick the one whose failure mode your deployment can guarantee it will never trigger.

The table tells you which edge to move. It does not tell you why you sometimes cannot move all of them at once -- why there is no row that is graceful on reuse and single-pass and fully committing and fastest. That absence is not a gap in the engineering. It is a theorem.

8. The Limits Are Theorems

Everything so far has been a design choice: move an edge here, pay for it there. Now the hard walls -- the places where no cleverness helps, because a proof says so. There are four, and each maps to an edge; the standard graduate references develop these bounds in full [@boneh-shoup][@katz-lindell].

GCM's two ceilings, correctly attributed (the nonce edge). GCM's two limits from SP 800-38D are not conservative engineering guesses; they are where the security proof runs out -- and they come from two different mechanisms people constantly merge into one.

The per-message limit of $2^{39}-256$ bits (about 64 GiB) is 32-bit counter-mode block-space exhaustion, not a GHASH property: with a 96-bit nonce GCM forms the initial counter block $J_0 = \mathrm{IV} \parallel 0^{31} \parallel 1$, the increment function advances only the low 32 bits, so counter mode emits at most $2^{32}-2$ keystream blocks, and $(2^{32}-2)\times 128$ bits $= 2^{39}-256$ bits; exceed it and the counter wraps, repeating a keystream block -- a two-time pad (SP 800-38D Section 5.2.1.1) [@sp80038d].

The per-key cap of roughly $2^{32}$ messages under random 96-bit nonces is a different quantity entirely: the birthday bound on nonce collision, where with $q$ messages the probability of a repeat scales as $q^2 / 2^{96}$, so $q \approx 2^{32}$ keeps it negligible (SP 800-38D Section 8.3) [@sp80038d]. Hoang, Tessaro, and Thiruvengadam proved these multi-user bounds tight, validating the nonce-randomization mechanism TLS 1.3 uses [@htt2018-gcm].

Tag length obeys its own bound: for a one-time Wegman-Carter MAC, forgery probability grows with the number of attempts and shrinks with tag length -- exactly why a 64-bit CCM_8 tag is a genuine, quantifiable forgery budget rather than a free optimization [@rfc3610].

Misuse-resistance cannot be online (the nonce edge, again). This is the deepest limit in the article, and it explains a design decision that otherwise looks like laziness. Rogaway and Shrimpton proved that a deterministic, nonce-misuse-resistant AEAD cannot be online or single-pass [@rs2006]. The reason is forced by the definition: to be misuse-resistant, the ciphertext must depend on the entire plaintext (otherwise two messages sharing a prefix under a repeated nonce would leak that prefix), so the encryptor cannot emit even the first ciphertext byte until it has read the last plaintext byte. There is no implementation trick around it.

Key idea: You cannot have both streaming and misuse-resistance. It is a theorem, not a missing feature: a misuse-resistant AEAD must read the whole message before it can output any ciphertext. That single impossibility is why AES-GCM-SIV is two-pass, and why "just make GCM misuse-resistant without slowing it down" is a request for something that provably does not exist [@rs2006].

Commitment is an orthogonal axis (the commitment edge). A conventional CTR-based AEAD like GCM is provably not key-committing -- the property is simply absent from IND-CPA and INT-CTXT, so no amount of using GCM "correctly" produces it. Worse, commitment is not one property but a lattice: Bellare and Hoang proved CMT-1 (bind to the key) does not imply CMT-4 (bind to the full context), a separation RFC 9771 later codified [@bh2022-commit][@rfc9771].

And the attacks are cheaper than the naive birthday intuition suggests: Menda and coauthors found context-discovery attacks against CCM, EAX, SIV, GCM, and OCB3, including an $O(2^{n/3})$ attack on SIV using Wagner's k-tree algorithm -- well below the $2^{n/2}$ a birthday bound would suggest [@menda2023].

Releasing plaintext early is a strictly weaker world (all edges). The fourth limit is about what your decrypt function is allowed to do before it finishes.

What an implementation exposes if it emits decrypted plaintext before checking the authentication tag. The formal integrity notion for this setting, INT-RUP, is codified in RFC 9771 Section 4.3.10; security that survives releasing unverified plaintext is strictly stronger than standard AEAD security, and most fast one-pass modes satisfy it only weakly -- which is why the safe API contract is verify-then-release: never act on plaintext until the tag checks out [@rfc9771].

Now assemble the thought experiment. Imagine the ideal AEAD: graceful on nonce reuse and fully committing and online/single-pass and fastest at both the server and constrained extremes. The second limit rules out "misuse-resistant and online" together. The third makes commitment an add-on that the CTR, stream, and welded defaults lack -- Ascon, uniquely, commits natively. The performance extremes pull in opposite directions -- AES round function for servers, a few thousand gates for sensors. You cannot have all of it in one construction, and this is not because nobody has been clever enough. It is because the properties provably conflict.

Note: No single construction closes all three edges at once. That is not a temporary state of the art -- it is a set of theorems about online-ness, commitment, and hardware. The portfolio is not a failure to converge on a winner; it is the mathematically necessary shape of the solution [@rs2006][@bh2022-commit].

So that is settled, provably. Which turns the interesting question inside out. Not "which mode wins?" but "can we make the robustness the default instead of the expert's opt-in?" That is exactly where the field is fighting right now.

9. Where AEAD Still Bites

The classical problem is closed. For confidentiality and integrity, the bounds are tight and the constructions are vetted. The entire live frontier is about robustness: turning the properties nobody used to ask for into defaults nobody has to remember. Six problems are open, and every one of them has the same shape.

Committing AEAD by default. Salamanders and partitioning oracles still bite wherever a committing transform is omitted, which today means almost everywhere [@dodis2018-salamander][@len2021-partition]. The frustrating part is that the fix is cheap: Bellare and Hoang give transforms that add full commitment with no ciphertext-size increase, and Albertini and coauthors give a padding-based alternative [@bh2022-commit][@albertini2022]. Yet as of mid-2026, none is mandated by a shipping standard. RFC 9771 gives the field a shared vocabulary for the property but does not require any construction to have it [@rfc9771]. The open question is not "how?" but "why is it still opt-in?"

Misuse-resistance by default. If nonce reuse is a recurring operational reality, why is the misuse-resistant mode the escalation rather than the default? The answer is the theorem from Section 8: defaulting to SIV means defaulting to two-pass, non-streaming encryption, and a great deal of infrastructure assumes it can encrypt a stream as it arrives [@rs2006]. Whether that trade is worth making by default is an active argument, not a settled one.

The release-of-unverified-plaintext trade space. Between "buffer everything and verify first" and "stream plaintext out immediately" is a design space that streaming media, large-file transfer, and constrained receivers all care about, and the security definitions there -- INT-RUP and its relatives -- are still maturing [@rfc9771].

Hardware co-design versus conservative margin. AEGIS already beats AES-GCM on AES-NI hardware, and the appetite for line-rate encryption keeps growing [@wu2013-aegis]. Newer AES-round designs push the throughput frontier even higher, but they trade cryptanalytic maturity for speed, and their standardization status is unsettled -- AEGIS itself is still only an Internet-Draft, not an RFC [@aegis-draft18]. How much margin to spend for how much throughput is an open judgment call.

Post-quantum reality, minus the myth. This one is mostly a matter of correcting a widespread misconception.

For symmetric authenticated encryption the honest answer is: no, and you mostly need to change nothing. Grover's algorithm offers at most a square-root speedup on key search, which halves the effective key length [@grover1996], so a 128-bit key gives about 64 bits of margin against a hypothetical quantum attacker. The remedy is simply to prefer 256-bit keys -- ChaCha20 already uses one, and AES-256 is a configuration flag -- and to size tags with a margin. The post-quantum upheaval lives in key exchange and signatures, not the AEAD record layer, as developed in the post-quantum-cryptography-on-Windows post in this collection. Your record encryption survives the transition largely intact.

Constant-time without special hardware. GHASH is hard to implement in constant time without CLMUL, and table-based AES leaks timing without AES-NI -- the exact side-channel pressure that motivated both ChaCha20-Poly1305 and Ascon [@bernstein-chacha][@ascon2021]. On the smallest devices, where neither special instruction exists and power analysis is a live threat, side-channel-resistant AEAD is still an open engineering problem, and it is much of the reason NIST ran a lightweight competition at all.

None of these has a finished answer. But notice the shape of every one: they are all attempts to move an edge to a place where the deployer cannot step on it by mistake -- misuse-resistance you do not have to remember, commitment you do not have to add, side-channel safety you do not have to hand-tune. Which brings us back to the only rule that actually travels.

10. The Field Guide: Rules and Parameters

Everything above collapses into one default and a short list of deliberate escalations. Follow the ladder and you will never again pick an AEAD by folklore.

Note: Default to AES-GCM with a 96-bit nonce that is unique per key (prefer a counter over a random value), a hard cap well under $2^{32}$ messages per key, at most 64 GiB per message, and a full 128-bit tag. Use ChaCha20-Poly1305 under the same contract when you lack AES hardware. Leave the default only when a specific edge forces you, and only in the direction that edge points [@sp80038d][@rfc8439].

The escalation ladder, each rung mapped to the edge it moves:

Cannot guarantee a unique nonce? Escalate on the nonce edge to AES-GCM-SIV [@rfc8452]. Cloned VMs, counters that reset on crash, weak first-boot entropy -- if any of these is in your threat model, the graceful failure is worth the second pass.
A stack mandates it, or the device is tiny? Use AES-CCM where WPA2, BLE, or Zigbee require it [@rfc3610], and Ascon-AEAD128 for new constrained designs, now that it is a NIST standard [@sp800232].
Deterministic encryption or key wrapping? Use AES-SIV, which needs no nonce at all and is built for exactly this [@rfc5297].
You want one-pass, single-primitive elegance? OCB3 is now patent-clear, though rarely the right call given how entrenched the defaults are [@rfc7253][@kr2021-ocb].
You control both endpoints and need maximum throughput? AEGIS is the fastest option, if you can accept a pre-RFC specification [@aegis-draft18][@wu2013-aegis].
Must a ciphertext bind to exactly one key? Add a key-commitment transform -- for password-based encryption, key rotation, message franking, or multi-recipient encryption -- because no default provides it [@bh2022-commit].

Nonce generation itself is the subject of Part 2 of this series; do not re-derive it here, but do treat "unique per key" as a hard contract, not a hope. On Windows, the CNG architecture post in this collection shows AES-GCM exposed through the BCryptEncrypt API with an authenticated-cipher-mode information structure -- a concrete example of the parameters below appearing in a real API.

Pair the ladder with the support map from Section 6 when you check feasibility: browser JavaScript means AES-GCM through WebCrypto, and a target with no AES hardware means ChaCha20-Poly1305 or, if it is also tiny, Ascon-AEAD128 [@webcrypto].

The exact operational contract, per construction:

Construction	Nonce	Tag	Per-key limit	Per-message limit	On nonce reuse
AES-GCM	96-bit, unique	128-bit	~`2^32` msgs (random nonce)	`2^39 - 256` bits, ~64 GiB	Catastrophic
ChaCha20-Poly1305	96-bit, unique	128-bit	~`2^32` msgs (random nonce)	~256 GiB	Catastrophic
AES-CCM	7 to 13 byte	up to 128-bit (`CCM_8`: 64)	Set by nonce length	Set by length field	Catastrophic
AES-GCM-SIV	96-bit	128-bit	Improved (per-nonce derived keys)	~64 GiB	Graceful: message equality
AES-SIV	None or supplied	128-bit	Large	Large	Graceful: message equality
OCB3	up to 120-bit	up to 128-bit	Large	Large	Catastrophic
AEGIS	128 or 256-bit	128 or 256-bit	Large (wide nonce)	Large	Catastrophic
Ascon-AEAD128	128-bit	128-bit	Per SP 800-232	Per SP 800-232	Catastrophic

The only two numeric limits you must hard-code are GCM's, because they are the ones people breach silently: cap messages per key well under $2^{32}$ and messages under 64 GiB each [@sp80038d]. ChaCha20-Poly1305's own ~256 GiB per-message ceiling comes the same way, from its 32-bit block counter over 64-byte blocks ($2^{32}\times 64$ bytes $= 2^{38}$ bytes), per RFC 8439 [@rfc8439]. AES-GCM-SIV's per-nonce key derivation buys better multi-user bounds, which is the whole reason RFC 8452 derives fresh keys rather than reusing one [@bht2018][@rfc8452].

Every rung of that ladder has a mirror image: a misuse pattern that punishes the deployment for stepping on the edge it ignored. Each row below maps a real-code mistake to the named break that catches it.

Misuse seen in real code	Edge it triggers	Named break
Reusing a `(key, nonce)` in GCM or AEGIS	Nonce	Nonce-Disrespecting Adversaries, 2016
Assuming an AEAD binds a ciphertext to one key	Commitment	Invisible salamanders; partitioning oracles
Truncating the tag to save bytes (`CCM_8`)	Integrity budget	Wegman-Carter forgery bound
Treating AES-GCM-SIV reuse as "free"	Nonce	SIV leaks message equality
Hand-rolling Encrypt-and-MAC	Composition	Bellare-Namprempre; Krawczyk
Conflating GCM's two ceilings	Nonce	The two SP 800-38D limits

The evidence for each is in the sections above: nonce reuse on live servers [@bock2016], the salamander and its weaponization [@dodis2018-salamander][@len2021-partition], the tag-length forgery budget [@rfc3610], the SIV equality leak [@rfc8452], the composition theorems [@bn2000][@krawczyk2001], and the two ceilings [@sp80038d]. One extra caution on attribution: the live-TLS nonce-reuse break is repeatedly mis-cited to CVE-2016-0270, which actually names IBM Domino and which the NVD itself flags as commonly misapplied to other products [@cve-2016-0270].

Search your codebase for any AEAD decryption that runs under an attacker-influenced key: password-based encryption, key wrapping, token decryption, or multi-recipient envelopes. If a decrypt path lets the caller supply or guess the key and then branches on whether decryption succeeded, you are exposed to a partitioning oracle and need a key-commitment transform on top of the AEAD [@len2021-partition][@bh2022-commit].

That ladder is your inoculation against folklore. But folklore is sticky, so let us take the most common misconceptions head-on.

11. Seven Beliefs That Get Deployments Broken

No. For every nonce-respecting mode -- AES-GCM, ChaCha20-Poly1305, AES-CCM, OCB3, AEGIS, and Ascon -- a single repeated `(key, nonce)` is an immediate, total break: it leaks the XOR of the two plaintexts, and a second collision hands over the authentication subkey for universal forgery [@joux2006][@bock2016]. Only the SIV family degrades gracefully, and only to leaking message equality [@rfc8452]. No. It makes reuse *survivable*, not free. A repeated nonce still leaks message equality -- an attacker learns that two ciphertexts encrypt the same plaintext -- which can matter a great deal in the right context. Use it as a safety net, not a license to stop managing nonces [@rfc8452][@rs2006]. No to both misreadings. It is a different trade-off on the hardware edge, not a weaker cipher: constant-time in pure software with no lookup tables, which makes it the *stronger* choice on hardware without AES-NI, where table-based AES leaks timing. And it is not mandatory-to-implement in TLS 1.3 -- it is a *recommended* (SHOULD) cipher suite, while only AES-128-GCM is the MUST, per RFC 8446 Section 9.1 [@rfc8446]. Recommended, not weaker, not mandatory. No. Random 96-bit nonces are collision-safe only up to roughly $2^{32}$ messages per key, by the birthday bound. That per-key invocation cap is a different number from the per-message limit of about 64 GiB; enforce both, and prefer a counter over a random nonce when you can [@sp80038d][@htt2018-gcm]. No. Most AEADs are not key-committing. One AES-GCM ciphertext can be built to decrypt to two different meaningful plaintexts under two different keys, with the tag valid both times -- the invisible-salamanders result. If a ciphertext must bind to one key, add a commitment transform [@dodis2018-salamander][@bh2022-commit]. No. AEGIS leads on raw throughput, but it is nonce-respecting (catastrophic on reuse), not fully key-committing, and still an active Internet-Draft rather than an RFC -- it states plainly that it "is not a standard" and expires on 8 April 2026. Fastest is not the same as best for your deployment [@aegis-draft18][@wu2013-aegis]. No. Symmetric authenticated encryption survives the quantum transition. Grover's algorithm only halves effective key length [@grover1996], so prefer 256-bit keys and size tags with margin. The post-quantum upheaval is in key exchange and signatures, not the AEAD record layer. Separately, note that NIST's Ascon-AEAD128 is a tweaked variant of the CAESAR Ascon-128, not byte-identical [@sp800232].

The Function, Not the Ranking

Seven ciphers, one interface, three edges. Every break here was a deployment triggering an edge its designers deliberately moved elsewhere. The invisible salamanders triggered the commitment edge that AEAD never promised to close [@dodis2018-salamander]. The 184 TLS servers triggered the nonce edge that GHASH cannot survive [@bock2016]. The CCM_8 forgery budget is the tag-length edge priced in bits [@rfc3610]. The SIV equality leak is the residue of the one edge SIV does close -- even the fix has a seam [@rfc8452]. And OCB3's near-total absence is the patent grave, an edge that was never technical at all [@kr2021-ocb].

Put them together and the thesis is earned rather than asserted. "Which AEAD should I use?" is not a ranking from worst to best, because Section 8 proved there is no best -- no single construction can be misuse-resistant and single-pass and fully committing and fastest at once. It is a function: pick the construction whose failure mode your deployment can guarantee it will never trigger.

Master the three edges and you can place any construction on the map, predict any misuse before it ships, and evaluate whatever the next competition invents -- key-derivation-bound AEADs, the TLS record layer's next mode, or a lightweight winner that does not exist yet. The names will change. The edges will not.

One Number, Used Twice: How a Repeated Nonce Hands Over Your Private Key -- and How Determinism Takes It Back

noreply@paragmali.com (Parag Mali) — Thu, 09 Jul 2026 10:13:36 GMT

Reuse one number and you can lose everything. A **repeated** ECDSA signing nonce leaks your private key with grade-school algebra: two signatures under the same nonce, one subtraction, one modular inverse, and the key falls out. That is how the Sony PlayStation 3 master key was recovered [@f0f]. A **repeated** AES-GCM initialization vector is just as fatal: it instantly leaks $P_1 \oplus P_2$ and hands an attacker the material to forge authenticated ciphertext [@joux] [@nda]. The fix for both is one counter-intuitive move: stop trusting runtime randomness for the once-per-operation number. Derive it (RFC 6979, EdDSA, hedged signatures) [@rfc6979] [@rfc8032], or make a repeat non-catastrophic (AES-GCM-SIV) [@rfc8452]. One distinction separates understanding from folklore: a *biased* nonce is a *different*, statistical attack needing many signatures, not one [@ns] [@ladderleak].

1. One Number, Used Twice

In December 2010, on stage at the 27th Chaos Communication Congress in Berlin, three researchers working under the name fail0verflow explained how they had recovered the master private key that anchors the entire PlayStation 3 chain of trust [@f0f]. There was no brute force, no exotic side channel, no supercomputer grinding for months. There were two signatures and the kind of algebra you learned before you were old enough to drive. Sony had signed its code with ECDSA, the elliptic-curve digital signature algorithm, and Sony had signed every firmware image with the same secret per-signature number.Two events that are often merged into one: fail0verflow disclosed the constant-nonce flaw at 27C3 in December 2010; George Hotz, known as geohot, separately published an extracted PS3 root key in January 2011 [@geohot]. The talk revealed the mechanism; the key release came afterward. Keep them distinct.

Sit with how strange that is. The console's security rested on a signature scheme that most cryptographers would call sound. AES was not broken. The elliptic curve was not broken. The signature math was not broken. One input was reused, and the entire trust anchor fell out of a schoolbook manipulation that a motivated teenager could reproduce on paper.

Now the mirror image, in a completely different primitive. In 2016, a team scanning the live internet found 184 public HTTPS servers repeating a different one-time number -- the AES-GCM initialization vector -- and reported that this "fully breaks the authenticity of the connections" [@nda]. Not the confidentiality of a lab toy: the authenticity of real TLS sessions on the open web, letting an attacker forge messages the server would accept as genuine.

Same disease, entirely different organ. One is a signature that proves who you are; the other is the cipher that guards most of the web's traffic. Both staked everything on a number that was supposed to be used correctly exactly once.

That shared bet is the subject of this article. Both primitives depend, silently, on a value that must be unique and unpredictable -- once, per key. The precise question: what, exactly, does each stake on that number, and what is the exact cost of getting it wrong? For the repeat case, the answer is total and immediate -- and the algebra is short enough to print in full.

In cryptography, reusing one number can cost you everything.

That is the punchline, and by the end you will have earned it rather than taken it on faith -- the full key-recovery algebra, Antoine Joux's cipher attack, the statistical cousin that needs only a fraction of a leaked bit, and the deterministic designs that dissolve the whole failure family. But how can two signatures undo an entire console's chain of trust? To see it, we first have to meet the number both of these primitives are quietly betting everything on.

2. The Secret Number Both Primitives Depend On

Two algorithms, designed decades and a world apart -- a discrete-logarithm signature and a block-cipher mode of authenticated encryption -- turn out to share a single point of failure. Before we can watch it break, we need to know where the number comes from and why it has to exist at all.

The signature side is the older lineage. ElGamal's 1985 signature scheme introduced a per-signature secret exponent [@elgamal], and when the United States standardized the Digital Signature Algorithm as FIPS 186 in 1994 [@fips186], that per-signature secret came along for the ride. Its elliptic-curve descendant, ECDSA, keeps it. The value is called the signing nonce, written $k$, and it is regenerated fresh for every single signature.

The per-signature secret scalar in (EC)DSA. For each signature the signer draws a new $k$ in the range $[1, n-1]$, where $n$ is the order of the curve's base point. It must be unique, secret, and uniformly distributed -- exactly once per key. It is never transmitted, yet every signature is computed from it.

The cipher side is younger. When NIST standardized Galois/Counter Mode in SP 800-38D in 2007, the specification required that the initialization vector -- the $\text{IV}$, GCM's nonce -- be distinct for every message encrypted under a given key [@sp80038d]. Same structural demand, opposite secrecy requirement: the signing nonce must be secret, while the GCM nonce may be completely public. What both must be is fresh.

The per-message value GCM mixes in so that encrypting under a fixed key never repeats its keystream. Uniqueness under a given key -- not secrecy -- is the entire contract. A public counter is a perfectly good GCM nonce; a *repeated* one is a catastrophe.

Now put the two governing equations side by side. An ECDSA signature on a message whose hash (as an integer) is $z$, under private key $d$, is the pair $(r, s)$:

$$r = (k \cdot G)_x \bmod n, \qquad s = k^{-1},(z + r,d) \bmod n$$

Here $G$ is the fixed base point, $n$ its prime order, $d$ the private key, and $r$ is the x-coordinate of the curve point $k \cdot G$ reduced modulo $n$. The AES-GCM authentication tag on ciphertext $C$ with additional data $A$ is:

$$T = E_K(J_0) \oplus \mathrm{GHASH}_H(A, C), \qquad H = E_K(0^{128})$$

$E_K$ is AES under key $K$; $J_0$ is a pre-counter block derived from the IV; $\mathrm{GHASH}_H$ is a polynomial hash over the field $\mathrm{GF}(2^{128})$ keyed by the secret subkey $H$, which is simply AES applied to the all-zero block.

Look at what both equations hide inside them. The signing equation multiplies the private key $d$ by the public $r$ and masks it behind $k$. The tag equation masks the keyed hash behind the one-time pad $E_K(J_0)$, which is a deterministic function of the nonce. In each case, one freshly chosen value is the only thing standing between a routine operation and a full disclosure. That gives us the single shared contract, short enough to fit on one line: the number must be unique and unpredictable, exactly once, per key.

This is the in-depth sequel to [Part 2](/blog/predictable-or-repeated-the-only-two-ways-cryptographic-rand), which surveyed the two ways cryptographic randomness betrays you -- predictability and repetition -- across many primitives at breadth. Part 2 owns the general taxonomy; this post goes deep on two specific victims, the ECDSA nonce and the GCM IV, and derives the exact algebra of each collapse. We will not re-teach the two-knobs framework here; we will spend it.

None of this was a secret to the designers. Bellare, Goldwasser, and Micciancio analyzed the danger of a poorly generated DSA nonce as early as their 1997 CRYPTO paper, "The DSS case" [@bgm], showing that a linear-congruential nonce generator breaks the scheme.Terminology drifts across modes, so fix it now: a nonce need only be unique (CTR, GCM); an IV for CBC must additionally be unpredictable; a salt is unique and public and feeds a KDF. The mode dictates which property is load-bearing. Part 2 and the block-cipher-modes installment work through the distinctions; here we only need "fresh, once, per key." The contract was understood from the beginning; nobody misunderstood the rule. They simply could not always keep it.

The contract says "never repeat." So begin with the crudest possible violation -- the same number, twice -- and watch precisely how much it costs.

3. Two Signatures, One k, and Your Private Key

This is the entire thesis compressed into one page of algebra -- no lattice, no side channel, no probability, just subtraction and one division. How little work does complete key recovery actually take?

Start from the fact that makes it possible. The first signature component, $r = (k \cdot G)_x \bmod n$, depends only on the nonce $k$ and the fixed public base point $G$. It does not depend on the message. So if you sign two different messages under the same $k$, both signatures carry the identical $r$. That repeated $r$ is the visible tell -- a fingerprint an attacker can spot by scanning a signature log, with no secret knowledge at all.This is exactly what fail0verflow read off the PlayStation 3: every firmware signature carried the same $r$, the public fingerprint of a constant $k$. You do not need to break anything to notice it; you just look for two signatures with a matching first half.

Now write the two signing equations under that shared $k$:

$$s_1 = k^{-1}(z_1 + r,d) \pmod n, \qquad s_2 = k^{-1}(z_2 + r,d) \pmod n$$

Subtract the second from the first. The private key appears only inside the identical $r,d$ term, so it cancels completely:

$$s_1 - s_2 = k^{-1}\big((z_1 + r,d) - (z_2 + r,d)\big) = k^{-1}(z_1 - z_2) \pmod n$$

Every quantity on the right except $k$ is public: the two message hashes $z_1, z_2$ and the two signature halves $s_1, s_2$. So solve for the nonce directly:

$$k = (z_1 - z_2),(s_1 - s_2)^{-1} \bmod n$$

One subtraction on top, one modular inverse on the bottom. With $k$ in hand, substitute back into the first equation -- multiply through by $k$, subtract $z_1$, and divide by the public $r$:

$$s_1 k = z_1 + r,d \implies d = (s_1 k - z_1),r^{-1} \bmod n$$

That is the private key. Count the cost to the attacker: two signatures, a handful of modular operations,Constant work here means a fixed number of field operations, independent of the key size. A 256-bit curve is no harder to break this way than a 160-bit one, because the attack never touches the key's length. and the recovery is certain -- not probable, not "on average," but exact, every time, the moment the repeat occurs. It solves a two-by-two linear system that the reuse handed over for free.

flowchart TD A["Two signatures made under the same nonce k"] --> B["They share the same r, because r depends only on k and G"] B --> C["Subtract the two s equations"] C --> D["The r times d term cancels, leaving k as the only unknown"] D --> E["One modular inverse recovers k"] E --> F["Put k back into either s equation"] F --> G["The private key d falls out, with certainty"]

You do not have to take the algebra on faith -- here is the whole attack as runnable code over a toy curve order, recovering the private key from public values alone:

{` // Recover the ECDSA private key d from two signatures sharing nonce k. function egcd(a, b) { if (b === 0n) return [a, 1n, 0n]; const [g, x, y] = egcd(b, a % b); return [g, y, x - (a / b) * y]; } function modInv(a, n) { a = ((a % n) + n) % n; const [g, x] = egcd(a, n); if (g !== 1n) throw new Error('no inverse'); return ((x % n) + n) % n; }

const n = 1103n; // toy prime "curve order" (real curves use ~256-bit n) const d = 937n; // the SECRET key the attacker must not know const k = 421n; // the reused nonce (identical for both signatures) const r = 668n; // r = (k*G).x mod n -- SHARED because k is shared const z1 = 123n, z2 = 456n; // two different message hashes

// Victim signs both messages with the SAME k: const s1 = (modInv(k, n) * (z1 + r * d)) % n; const s2 = (modInv(k, n) * (z2 + r * d)) % n;

// Attacker sees only public (r, s1, z1, s2, z2). Recover k, then d: const kRec = ((((z1 - z2) % n) + n) % n) * modInv((((s1 - s2) % n) + n) % n, n) % n; const dRec = ((((s1 * kRec - z1) % n) + n) % n) * modInv(r, n) % n;

console.log('shared r :', r.toString()); console.log('recovered k :', kRec.toString(), '(true k =', k.toString() + ')'); console.log('recovered d :', dRec.toString(), '(true d =', d.toString() + ')'); console.log(dRec === d ? 'PRIVATE KEY RECOVERED from two signatures.' : 'mismatch'); `}

Key idea: Two signatures sharing one nonce equal certain, instant, total key recovery -- by hand, with pure algebra. Reuse is not a slope that gradually weakens security; it is a cliff. "Reuse one number equals everything" is a literal statement about ECDSA, not a rhetorical flourish.

This is not a museum piece. The PlayStation 3 fell to exactly this -- a constant $k$ across every firmware signature, two images sharing one $r$, the master key recovered [@f0f]. Section 5 catalogs the rest of the real-world chain, from that constant-nonce break down to biases of less than a single bit.

Certainty from a literal repeat is the easy case -- easy for an attacker to run, and, as we will see, easy for a defender to eliminate. So attackers asked a sharper and far more dangerous question. What if the nonces are never equal, only slightly, invisibly skewed?

4. From Repeat to Bias: The Hidden Number Problem

You do not need the nonces to be equal. You only need them to be a little bit predictable -- and then to collect enough of them. This is where the story turns, because it dismantles the comforting fix you probably just thought of. If a literal repeat is the danger, surely "make sure the nonces are always different" closes it? It does not come close.

Here is the shift in viewpoint. In Section 3, a repeat gave us an exact equation and we solved it. Now suppose each nonce is merely skewed -- say the top few bits are always zero, or the generator leans slightly toward small values. No two nonces are equal, so the certainty attack never triggers. But each signature is now a noisy linear equation relating the public data to the secret key $d$ modulo $n$, with the unknown nonce constrained to a smaller range than it should occupy. One such equation tells you almost nothing.

Stack hundreds or thousands of them as the rows of a lattice, though, and the secret $d$ shows up as one unusually short vector hiding in that grid. A reduction algorithm hunts it down, and the key reads straight out.

The problem of recovering a hidden integer -- here, the private key -- from many samples that each reveal only a few most-significant bits of a related product modulo $n$. Dan Boneh and Ramarathnam Venkatesan introduced it in 1996, and it is the framework underneath every biased-nonce attack on (EC)DSA [@hnp]. An integer grid of points formed by adding and subtracting a fixed set of basis vectors. Biased-nonce recovery constructs a lattice whose unusually short vector encodes the secret key; a reduction algorithm finds that vector. We stay conceptual here -- the internals of LLL and the closest-vector problem belong to their own discussion.

The genealogy is worth knowing, because each step needed less leakage than the last. Boneh and Venkatesan framed the Hidden Number Problem in 1996 [@hnp]. Around 2000, Daniel Bleichenbacher showed that even a tiny statistical bias in DSA nonces is exploitable through a Fourier-analytic version of the same idea.Bleichenbacher's seminal biased-nonce result was never published as a standalone paper. It survives as a 2000 IEEE P1363 presentation and a 2005 CRYPTO rump-session talk, "Experiments with DSA," and is reconstructed through the reference lists of later work such as Nguyen-Shparlinski and LadderLeak. A standalone Bleichenbacher paper on this would be a fabrication; the history genuinely has this shape.

Nick Howgrave-Graham and Nigel Smart made the lattice attack practical in 2001, recovering keys from partially known nonces [@hgs]. Phong Nguyen and Igor Shparlinski then proved rigorous polynomial-time ECDSA key recovery from just a few leaked nonce bits per signature in 2003 [@ns]. Two decades on, LadderLeak pushed the frontier to its logical extreme, breaking ECDSA with less than one bit of nonce leakage per signature [@ladderleak].

Now the distinction that everything downstream depends on. The biased case is not the repeat case with weaker numbers. It is a different kind of attack with a different cost profile, and conflating them is the single most common way this topic gets mistold.

Note: A repeated nonce leaks the key from two signatures, with certainty (Section 3). A biased nonce leaks nothing usable from any single signature; it takes many signatures -- hundreds, thousands, or more -- aggregated by a lattice or Fourier reduction before the key emerges. "One biased signature reveals your key" is false. Keep the two cases apart or you will misquote the entire failure family.

Laid out side by side, the contrast is stark:

	Repeated nonce	Biased nonce
Leak per signature	The entire nonce (matches another)	A few bits, or a fraction of one
Signatures needed	Two	Many (hundreds to millions, per bias)
Method	Subtraction and one modular inverse	Lattice reduction or Fourier analysis (HNP)
Result	Certain and exact	Statistical, high-probability
Work	Schoolbook algebra by hand	Serious computation on aggregated data
Defeated only by	Distinct nonces	Removing the bias, not just repeats

flowchart TD A["Many signatures, each nonce slightly biased"] --> B["Each is a noisy linear equation in the secret d"] B --> C["Stack the equations as rows of a lattice"] C --> D["The secret d hides in one unusually short vector"] D --> E["Lattice reduction finds that short vector"] F["Read the private key d straight out of it"] E --> F

The lesson lands hard. If even a fraction of one bit of bias, harvested across enough signatures, surrenders the key, then "never literally repeat $k$" is nowhere near enough of a rule, and "use a better random number generator" is a treadmill, not a fix. The only question left is how bad this got in real, shipped hardware -- devices built by careful engineers who knew all of this.

5. The Catastrophes in the Wild: ECDSA

The theory is alarming; the field results are worse. What follows is the evolution told as a body count, and the number to watch is the leak the attacker needed. It shrinks with almost every entry, from an entire repeated nonce down to a fraction of a single bit, and every generation still won.

The 2010 PlayStation 3 break sits at one end: a constant nonce across all firmware signatures, the maximum possible leak, two signatures sufficient [@f0f]. In 2013 the Android SecureRandom defect produced repeated and predictable signing nonces on mobile devices; because Bitcoin wallets sign transactions with ECDSA, attackers drained the vulnerable ones [@bitcoin]. Google's own writeup traced the root cause to improper initialization of the underlying PRNG in the Java Cryptography Architecture [@securerandom].The often-repeated figure of roughly 55 BTC stolen in the 2013 Android incident comes from secondary news reporting [@hackernews]. The primary bitcoin.org advisory [@bitcoin] names the flaw and the affected wallet apps but states no loss total. Treat the number as reported, not official.

Then the leak starts shrinking. Minerva (2020) attacked real smart cards and cryptographic libraries that leaked the bit-length of the nonce through timing -- a whisper of bias, not a repeat -- and recovered keys from "just 500 signatures for simulated leakage data, 1200 for real cryptographic library data, and 2100 for smartcard data" [@minerva].

TPM-Fail (disclosed 2019, published at USENIX Security 2020) turned a timing side channel in Intel's firmware TPM (CVE-2019-11090) and an STMicroelectronics TPM (CVE-2019-16863) into nonce-bit leakage. It recovered an ECDSA key from the Intel fTPM in 4 to 20 minutes and, remotely, "the authentication key of a virtual private network (VPN) server in 5 hours" [@tpmfail] [@moghimi].

LadderLeak (2020) then broke ECDSA with less than one bit of nonce leakage per signature, exploiting a Montgomery-ladder side channel in OpenSSL [@ladderleak], a result published at ACM CCS 2020 [@ladderleak_doi]. And in 2024, PuTTY's use of P-521 exposed a structural bias so clean it needs almost no data at all (CVE-2024-31497) [@putty].

"The first 9 bits of each ECDSA nonce are zero. This allows for full secret key recovery in roughly 60 signatures." -- the PuTTY P-521 disclosure [@putty]

Sixty signatures. An attacker who had watched roughly sixty SSH handshakes, or collected sixty signed Git commits, could reconstruct the user's private key. The affected PuTTY versions ran from 0.68 through 0.80 (fixed in 0.81), and the same biased generator shipped in FileZilla, WinSCP, TortoiseGit, and TortoiseSVN [@putty]. Collect them into one table and the trend is impossible to miss:

Year	Target	Repeat or bias	Leak per signature	Signatures needed	Source
2010	Sony PS3 firmware	Repeat (constant k)	The entire nonce	2	[@f0f]
2013	Android Bitcoin wallets	Repeat / predictable k	Nonce reused or guessable	A few	[@bitcoin] [@securerandom]
2020	Minerva (cards, libraries)	Bias (nonce bit-length)	Timing reveals length	500 to 2100	[@minerva]
2019-2020	TPM-Fail (Intel, STMicro TPMs)	Bias (timing)	Nonce high bits via timing	Many	[@tpmfail] [@moghimi]
2020	LadderLeak (OpenSSL ladder)	Bias (sub-bit)	Less than one bit	Many	[@ladderleak]
2024	PuTTY P-521 (CVE-2024-31497)	Bias (structural)	First 9 bits fixed at zero	~60	[@putty]

flowchart LR A["1996 HNP framework: bias is exploitable in principle"] --> B["2010 PS3: a constant nonce, the whole value repeats"] B --> C["2013 Android: predictable and repeated nonces"] C --> D["2020 Minerva and TPM-Fail: a few biased bits via timing"] D --> E["2020 LadderLeak: less than one bit per signature"] E --> F["2024 PuTTY P-521: nine fixed bits, about 60 signatures"]

Note: Read the arc left to right and one lesson dominates: the leakage an attacker needs keeps shrinking, from an entire repeated nonce to less than a single bit. No generator is perfectly unbiased, and -- as Part 2 argued -- you can never prove one is. Any residual bias, given enough signatures, eventually surrenders the key. "Harden the random number generator" buys time; it does not close the hole. That conclusion is the synthesis of the whole table, and it is what forces the search for a structural answer.

Every entry above is a signature scheme bleeding out its private key through the nonce. You would be forgiven for thinking this is an ECDSA problem. It is not. The exact same structural flaw -- one number that must be used once and is fatal on reuse -- was hiding inside a completely different primitive, the cipher that protects most of the traffic on the modern web.

6. The Other Primitive: AES-GCM's Forbidden Attack

Different math, a different decade, a different threat model -- and the exact same fatal dependency on one number used once. The puzzle here is sharper: AES-GCM's nonce is public, so how can reusing a value the attacker already knows leak a forgery key? The answer is Antoine Joux's forbidden attack, and it mirrors the signature story beat for beat.

Recall the tag from Section 2: $T = E_K(J_0) \oplus \mathrm{GHASH}_H(A, C)$, where $H = E_K(0^{128})$. Two facts about that formula are load-bearing. First, $H$ depends only on the key, so it is fixed for the whole life of that key. Second, $E_K(J_0)$ depends only on the key and the nonce, through the pre-counter block $J_0$. Reuse the nonce and $E_K(J_0)$ comes back identical.

The secret 128-bit value $H = E_K(0^{128})$ -- AES applied to the all-zero block -- that keys GCM's polynomial authenticator over $\mathrm{GF}(2^{128})$. It never changes for a given key, and recovering it lets an attacker forge authentication tags at will.

Now reuse one $(\text{key}, \text{IV})$ pair on two messages. Two things break, and they break separately.

The confidentiality break, from a single collision. GCM encrypts with counter mode: the ciphertext is the plaintext XORed with a keystream generated from $J_0$. Same key, same IV means the same $J_0$, means the same keystream. So for two messages encrypted under the reused pair, $C \oplus C' = P \oplus P'$. The keystream cancels and the XOR of the two plaintexts falls out immediately, from just one collision, with no further work. If the attacker knows or guesses one plaintext, the other is fully revealed. Here is that leak as runnable code:

{` // Reuse one (key, IV) in a keystream mode -> C XOR C' leaks P XOR P'. // GCM encrypts with AES-CTR: same (key, IV) reproduces the SAME keystream. function xor(a, b) { return a.map((x, i) => x ^ b[i]); } const bytes = s => Array.from(new TextEncoder().encode(s)); const hex = a => a.map(x => x.toString(16).padStart(2, '0')).join('');

// A fixed keystream stands in for AES-CTR(key, IV): identical for both messages. const keystream = [0x9e,0x37,0x5a,0xc1,0x02,0xbb,0x44,0xd0,0x71,0x6f,0x88,0x2a];

const P1 = bytes('transfer=10 ').slice(0, keystream.length); const P2 = bytes('transfer=9999').slice(0, keystream.length);

const C1 = xor(P1, keystream); // ciphertext 1 const C2 = xor(P2, keystream); // ciphertext 2, SAME keystream

// Attacker never sees the key or keystream -- only C1 and C2: const leak = xor(C1, C2); // == P1 XOR P2, the keystream cancels console.log('C1 XOR C2 :', hex(leak)); console.log('P1 XOR P2 :', hex(xor(P1, P2)), '(identical -> keystream is gone)');

// If the attacker also knows P1, then P2 falls out immediately: console.log('recover P2:', new TextDecoder().decode(new Uint8Array(xor(leak, P1)))); `}

The authenticity break, from the tag difference. This is Joux's contribution. Write the two tags under the reused pair and XOR them. The identical blind $E_K(J_0)$ cancels exactly:

$$T \oplus T' = \mathrm{GHASH}_H(A, C) \oplus \mathrm{GHASH}_H(A', C')$$

Every block of $A, C, A', C'$ is observable on the wire, and $\mathrm{GHASH}_H$ is a polynomial in $H$ over $\mathrm{GF}(2^{128})$ with those blocks as coefficients. So the right-hand side is a known polynomial in the one unknown $H$, and it equals the observed left-hand side. Move everything to one side and you have a polynomial equation whose roots are candidate values for $H$; factoring it over $\mathrm{GF}(2^{128})$ yields that candidate set [@joux].

Recover $H$ and, since $E_K(J_0) = T \oplus \mathrm{GHASH}_H(A, C)$ falls out too, the attacker can compute a valid tag for any ciphertext they like under that nonce. That is a universal forgery.

Antoine Joux's 2006 attack on GCM: reusing a $(\text{key}, \text{IV})$ pair cancels the tag's $E_K(J_0)$ blind, turning the difference of two tags into a known polynomial over $\mathrm{GF}(2^{128})$ whose roots are candidates for the subkey $H$. The name reflects that GCM's unique-IV rule is not a suggestion -- breaking it is forbidden [@joux]. flowchart TD A["Tag T equals E_K(J0) XOR GHASH_H of the message"] --> B["J0 comes from the IV, H comes only from the key"] B --> C["Reuse the same key and IV on a second message"] C --> D["E_K(J0) is identical in both tags, so it cancels under XOR"] D --> E["T XOR T-prime is a known polynomial in H over GF(2 to the 128)"] E --> F["Its roots are the candidate values for the subkey H"] F --> G["Two or more collisions pin H, enabling universal forgery"]

Note: A single $(\text{key}, \text{IV})$ collision leaks $P_1 \oplus P_2$ immediately and unconditionally -- confidentiality is gone at once. Recovering the subkey $H$ is a separate step: one collision yields a set of candidate roots, and pinning $H$ uniquely generally needs two or more collisions. "One reuse instantly recovers the authentication key" overstates it. "One reuse instantly destroys confidentiality and opens the road to forgery" is exact.

This is not confined to whiteboards. In 2016 the Nonce-Disrespecting Adversaries team scanned live TLS and "identified 184 HTTPS servers repeating nonces, which fully breaks the authenticity of the connections" [@nda].Joux's result is his 2006 public comment to NIST, whose embedded document title reads "Authentication Failures in NIST version of GCM" [@joux]. It is sometimes miscited as IACR ePrint 2006/187 -- but that number is a different paper, on HMAC and NMAC, by Kim, Biryukov, Preneel, and Hong [@eprint187]. Cite the NIST comment, not the ePrint. These were production HTTPS endpoints, not lab toys, and their nonce reuse let anyone forge authenticated records against them.The canonical live-TLS evidence for GCM nonce reuse is that paper [@nda], not CVE-2016-0270, which concerns IBM Domino rather than OpenSSL. If you see that CVE cited as the OpenSSL GCM-reuse bug, it is a misattribution.

Two primitives, one disease: a once-per-operation number that is death on reuse. If the flaw is structural rather than a coding slip, then "be more careful with your randomness" cannot be the cure -- Section 5 already showed that treadmill has no end. The fix has to be architectural. What would that even look like?

7. Make the Number Deterministic

The cure for a randomness disaster turned out to be less randomness. That sentence should feel wrong -- we have spent five sections watching bad randomness destroy keys, so surely the answer is better randomness. It is not, and seeing why is the moment the whole subject clicks into place.

Go back to what actually failed. The signing equation needs a $k$ that is unique and unpredictable. Every real break came from the runtime source of that $k$: a constant, a repeated PRNG output, a biased generator, a timing leak. So Thomas Pornin's RFC 6979 asks a disarming question -- what if we never draw $k$ from a runtime source at all? Instead, derive it, deterministically, from two things the signer already holds: the private key and the message [@rfc6979].

A signature whose per-message nonce is computed as a pseudorandom function of the private key and the message, using no runtime randomness at all. The same $(\text{key}, \text{message})$ pair always yields the same nonce, and therefore the same signature. RFC 6979 specifies this for (EC)DSA; EdDSA builds it into the scheme [@rfc6979] [@rfc8032].

Concretely, RFC 6979 runs an HMAC-based deterministic random bit generator, seeded from the private key $x$ and the message hash, and rejection-samples its output into the valid range $[1, n-1]$. The two helper encodings simply turn the key and the hash into fixed-width byte strings so the HMAC has well-defined inputs:

h  = H(message)                              # hash the message
V  = 0x01 0x01 ... 0x01                       # hlen bytes of 0x01
K  = 0x00 0x00 ... 0x00                       # hlen bytes of 0x00
K  = HMAC(K, V || 0x00 || int2octets(x) || bits2octets(h))
V  = HMAC(K, V)
K  = HMAC(K, V || 0x01 || int2octets(x) || bits2octets(h))
V  = HMAC(K, V)
loop:
    T = ""                                     # accumulate qlen bits of output
    while bitlen(T) < qlen:                    # one HMAC block if qlen <= hlen; more if longer
        V = HMAC(K, V);  T = T || V
    k = bits2int(T)
    if 1 <= k <= n-1:  return k               # in range -> use it
    K = HMAC(K, V || 0x00);  V = HMAC(K, V)    # else reseed and retry

Look at what this buys. The generator is seeded by the private key and the message, and nothing else, and two consequences close the generation side of the Part-A attack surface.

The repeat case dies because two different messages produce two unrelated nonces, while the same message reproduces the same signature harmlessly -- there is no runtime generator whose collision could hand you a shared $k$. The bias case dies wherever the bias was born in a generator: with no runtime generator in the loop, there is nothing to skew and no entropy pool to under-initialize. Every Section-5 break that lived in the generator -- the repeated $k$ on the PS3, the predictable $k$ from a weak SecureRandom -- has simply been removed from the design, because there is no generator left to fail.

Deterministic signers "do not need access to a source of high-quality randomness." -- RFC 6979 [@rfc6979]

And the compatibility story is almost too good: a verifier cannot even tell. The verification equation is unchanged, because a signature is still just a valid $(r, s)$ pair; only the signer's method of choosing $k$ changed. Deployments can switch to deterministic signing unilaterally. You do not have to take the "same input, same output" claim on trust either:

{// Deterministic nonce k = PRF(private key, message). // Real RFC 6979 uses HMAC-DRBG; this toy uses a small deterministic mixer // only to show the SHAPE: same (key,msg) => same k; different msg => unrelated k. const MASK = (1n << 64n) - 1n; const n = (1n << 61n) - 1n; // toy prime modulus, k in [1, n-1] function rotl(x, r) { return ((x << r) | (x >> (64n - r))) & MASK; } function prf(key, msg) { // deterministic, consults no RNG let h = 1469598103934665603n; // 64-bit offset basis for (const ch of (key + '|' + msg)) { h = (h ^ BigInt(ch.charCodeAt(0))) & MASK; h = (h * 1099511628211n) & MASK; // FNV-style multiply h = rotl(h, 13n) ^ (h >> 7n); // extra diffusion so 1 char avalanches } return (h % (n - 1n)) + 1n; // map into [1, n-1] } const sk = 'private-key-0xA1B2'; console.log('k(pay Bob 10) :', prf(sk, 'pay Bob 10').toString()); console.log('k(pay Bob 10) :', prf(sk, 'pay Bob 10').toString(), '<- identical, no RNG consulted'); console.log('k(pay Bob 11) :', prf(sk, 'pay Bob 11').toString(), '<- unrelated'); console.log('No source of runtime randomness was consulted.');}

The same idea has a sibling that was born deterministic. EdDSA, and its popular instantiation Ed25519, does not bolt determinism on -- it designs the runtime randomness out from the start, computing its per-signature secret as a hash of a key-derived prefix and the message [@rfc8032].That is why Ed25519 has no separate "use RFC 6979" mode: there is no runtime nonce anywhere in the scheme to bias or repeat. Determinism is not an option you enable; it is the definition.

Standards bodies followed the evidence: FIPS 186-5, the current US signature standard, now approves deterministic ECDSA "as specified in IETF RFC 6979" [@fips1865] [@fips1865pdf]. There is even a quiet operational bonus. A deterministic signer is testable: you can ship known-answer test vectors and check byte-for-byte that an implementation is correct, which a randomized signer can never offer.

Key idea: The fix for a randomness failure was to remove the randomness. Derive the nonce from the private key and the message, and there is no runtime generator left to repeat or bias -- both failure modes vanish together.

Determinism looks like a clean, total victory. It is narrower than that, and the boundary matters. What it closes is the generation side of Part A. It does nothing for the usage side: recall that Minerva, TPM-Fail, and LadderLeak never touched a generator -- they read the nonce's leading bits out of the timing of the scalar multiplication $k \cdot G$, and that leak is present no matter how $k$ was chosen [@minerva] [@tpmfail] [@ladderleak]. Determinism fixes generation, not usage; the defense against that class is a constant-time scalar multiplication, a separate discipline that RFC 6979 neither provides nor promises. Worse, determinism can even add exposure: by making signing perfectly repeatable, we hand a fault-injection attacker a perfectly repeatable target, a hazard RFC 6979's own security considerations acknowledge [@rfc6979]. If Go's standard library knows this well enough to refuse pure determinism on purpose, we had better find out what it is afraid of.

8. The Catch, and the Hedge

Here is a fact that should stop you: Go's standard library signs ECDSA non-deterministically on purpose, and its source code says so in a comment. After seven sections arguing that runtime randomness is the enemy, one of the most widely used standard-library signers refuses to remove it. That is not carelessness. It is a second threat model.

Determinism closed the randomness door, but it opened a different one. A deterministic signer computes the same signature every time for a given input, which means an attacker who can run it twice on the same message gets two identical computations to compare -- and comparison is exactly the lever a fault attack pulls.

An attack that induces a hardware fault -- a voltage glitch, a clock glitch, a laser pulse -- during a computation, then compares the faulty output against a correct one to solve for the secret. Against a *deterministic* signer the attacker can obtain a correct signature and a faulted signature for the identical input, which is precisely what makes the difference exploitable.

This is not hypothetical. Aranha, Orlandi, Takahashi, and Zaverucha proved that de-randomized Fiat-Shamir schemes -- EdDSA among them -- are vulnerable to differential fault attacks [@hedged]. And the standard itself agrees: FIPS 186-5 warns that fault attacks are "of particular concern for ... deterministic signature schemes, as well as embedded or IoT devices and smartcards" [@fips1865pdf]. The very property that made determinism testable and repeatable -- same input, same output -- is what hands a fault attacker a fixed target to hammer.

The resolution is not to retreat to randomized signing, which reintroduces every repeat and bias failure. It is to take a small step back toward randomness, on purpose and in a controlled way: hedged signatures.

A signature whose nonce is derived from the private key, the message, *and* a fresh random value $r$: $k = H(sk, m, r)$. If the random source fails, the construction degrades to the deterministic -- still safe -- case. If a fault is injected, the fresh $r$ means the signer is no longer a fixed, replayable target.

Read that definition twice, because it is the whole trick. Hedging is not "randomized signing with extra steps." It is a design that is safe whichever thing goes wrong. Lose your entropy source entirely and you fall back to RFC 6979's determinism, which we already proved kills repeat and bias. Keep your entropy and you also get a moving target that defeats the fault attack determinism exposed. The randomness is present but no longer load-bearing.

"Signatures generated by this package are not deterministic, but entropy is mixed with the private key and the message, achieving the same level of security in case of randomness source failure." -- Go `crypto/ecdsa` [@goecdsa]

That is why Go hedges by default, and it is not alone. BoringSSL's FIPS module passes "a SHA512 hash of the private key and digest as additional data into the RBG ... a hardening measure against entropy failure" [@boringssl]. RFC 6979 itself sanctions hedged variants in its Section 3.6 [@rfc6979], and FIPS 186-5 specifies an "Extra Random Bits" method that draws a nonce at least 64 bits longer than needed so any statistical bias becomes negligible [@fips1865pdf].

The honest caveats: hedging still consumes some entropy, and its security proofs cover specific fault classes rather than all conceivable faults. It is a well-chosen trade, not a free lunch.

The right mental model is three parallel choices selected by threat model, not a podium with one winner:

Property	Randomized	Deterministic (RFC 6979 / EdDSA)	Hedged
RNG needed at signing time	Full	None	Some (not load-bearing)
Immune to repeats	No (RNG can collide)	Yes	Yes
Immune to bias	No	Yes	Yes
Resists fault injection	Yes (moving target)	No (fixed target)	Yes
Known-answer test vectors	No	Yes	No
Standardized	Yes	Yes (RFC 6979, FIPS 186-5)	Yes (RFC 6979 3.6; FIPS 186-5)
Shipped by default in	Legacy code	Many libraries	Go `crypto/ecdsa`, BoringSSL FIPS
Best when	Rarely the right pick	No fault threat in scope	Hardware, embedded, smartcard, HSM

Note: For any new (EC)DSA signer -- especially on hardware, embedded, smartcard, or HSM targets where fault injection is realistic -- hedge it: derive the nonce from the key, the message, and a little fresh entropy. You keep repeat and bias immunity even if the random source fails, and you deny the fixed target a fault attack needs.

So the signature side does not settle on a single champion. It settles on a matched set of choices, each correct for a different adversary. That is a satisfying place to land -- but it is only half the patient. What is the symmetric-encryption analogue for the cipher we left bleeding in Section 6?

9. Fixing the Cipher: Nonce-Misuse-Resistant AEAD

The signature fix was "derive the number." The cipher's fix rhymes: derive the IV from the message itself, so that the worst a repeat can leak is the fact that two messages were byte-for-byte identical. Same instinct, symmetric setting.

The idea predates AES-GCM-SIV. Phillip Rogaway and Thomas Shrimpton gave it a provable-security treatment in 2006, defining deterministic authenticated encryption and the Synthetic IV construction that realizes it [@rs_eprint] [@rs_doi]. It was standardized as AES-SIV in RFC 5297 [@rfc5297].

An initialization vector computed *from the message* -- together with the key and associated data -- rather than drawn at random. Because the IV is a function of the plaintext, two different plaintexts get different IVs automatically, and only byte-identical messages ever collide. An authenticated cipher that, if a nonce is ever repeated, leaks at most whether two identical $(\text{key}, \text{nonce}, \text{plaintext}, \text{associated data})$ inputs were the same -- never the key, never arbitrary plaintext. Reuse degrades it gracefully rather than catastrophically.

The modern instantiation is AES-GCM-SIV (RFC 8452) [@rfc8452]. It computes a keyed hash of the entire plaintext and associated data using POLYVAL, and folds that into a synthetic IV that doubles as the authentication tag; the synthetic IV then seeds ordinary AES-CTR encryption.POLYVAL is a little-endian relative of GHASH, chosen deliberately so AES-GCM-SIV can reuse the same carry-less multiplication hardware that already accelerates AES-GCM. The parallel to GCM is by design, not coincidence.

Two more refinements matter: fresh message-authentication and message-encryption keys are derived per nonce from the master key, which also pushes back the birthday bound that limits plain GCM and raises the safe message limit to roughly $2^{50}$ per key [@gcmsiv_spec]. The price is structural and unavoidable: because the tag depends on the whole plaintext, you cannot emit the first ciphertext byte until you have read the last plaintext byte. AES-GCM-SIV is inherently two-pass and not online.

flowchart TD A["Master key and nonce"] --> B["Derive per-message auth and encryption keys"] P["Plaintext and associated data"] --> C["POLYVAL hash under the derived auth key"] B --> C C --> D["Synthetic IV, which doubles as the authentication tag"] D --> E["Seed AES-CTR encryption with the synthetic IV"] B --> E E --> F["Output ciphertext and tag"]

Now state precisely what "misuse-resistant" earns you, because the phrase invites overclaiming. On a nonce repeat, AES-GCM-SIV discloses only whether the two messages "were equal or not," which RFC 8452 identifies as "the minimum amount of information that a deterministic algorithm can leak" [@rfc8452]. Compare that to Section 6, where a single GCM repeat surrendered $P_1 \oplus P_2$ and set up universal forgery. The SIV construction converts a catastrophe into a whisper.

On nonce reuse, a misuse-resistant AEAD discloses only "whether the messages were equal or not ... the minimum amount of information that a deterministic algorithm can leak." -- RFC 8452 [@rfc8452]

Note: "Misuse-resistant" does not mean reuse is harmless. On a repeat, AES-GCM-SIV still leaks that two identical messages were sent under the same nonce -- the provable minimum, but not nothing. You get graceful degradation, not immunity. It is a safety net, not a license to reuse nonces deliberately.

There is a parallel path worth knowing, though it solves a slightly different problem. XChaCha20-Poly1305 extends the nonce to 192 bits, which makes random nonce selection collision-safe and lets systems stay stateless without a counter [@xchacha]. That is genuinely useful, but it is not true misuse resistance: an exact nonce repeat still breaks Poly1305 the way any keystream reuse does. A big nonce makes accidental collisions astronomically unlikely; it does not make a deliberate repeat safe. Collect the options:

Scheme	Passes / online	On nonce reuse	Misuse-resistant?	Nonce size	Notes
AES-GCM	1 pass, online	Catastrophic (Section 6)	No	96-bit	Fastest with a reliable unique counter
AES-GCM-SIV	2 pass, not online	Leaks only message equality	Yes	96-bit	POLYVAL and per-nonce keys [@rfc8452]
AES-SIV	2 pass, not online	Leaks only message equality	Yes	Vector input	Deterministic key-wrap [@rfc5297]
XChaCha20-Poly1305	1 pass, online	Random reuse unlikely; exact reuse breaks	No	192-bit	Stateless random nonces [@xchacha]

Two families, one move. On the signature side we stopped trusting runtime randomness by deriving the number; on the AEAD side we stop trusting it by making a repeat non-catastrophic. It feels, at last, like the problem is solved. It is not -- and the reasons are not missing features anyone can build. Some of them are walls that no amount of engineering can move.

10. Theoretical Limits and the Open Frontier

Some of the walls we keep hitting are not missing features that a cleverer engineer will one day supply. They are proofs that you cannot have everything at once.

First: an online cipher cannot be misuse-resistant. To leak only equality on a repeat, the first bit of ciphertext must depend on the *entire* plaintext, which forces a second pass -- so "streaming" and "misuse-resistant" cannot both hold [@rfc8452]. Second: pure determinism cannot resist faults. The very repeatability that kills nonce reuse is the property a fault attack exploits, so resisting faults means reintroducing some randomness to hedge [@hedged]. Neither wall is a missing feature. Both are theorems. There is no single perfect primitive -- only a matched pair chosen per threat model.

Those two impossibilities explain the shape of everything in Sections 7 through 9. AES-GCM-SIV is two-pass because it has to be. Hedged signatures exist because determinism alone cannot cover the fault case. We did not fail to find the one perfect design; the one perfect design is provably not there.

A third limit is epistemic, and it is the quiet engine under this entire article.

Note: You can never prove a generator is unpredictable; you can only fail to prove it predictable. That asymmetry -- argued in Part 2 -- is why "harden the random number generator" was never a structural fix. LadderLeak made the point unforgettable by winning with less than one bit of bias [@ladderleak]. Deriving the number sidesteps the unprovable question entirely: there is nothing left to certify.

And the biased-nonce frontier is still descending: LadderLeak's sub-one-bit result is the current floor, not a proven bottom [@ladderleak]. The theoretical minimum bias that remains exploitable is an open question, and history says to bet on "smaller than you think."

Then there is the genuinely open ground, where the same disease is re-emerging one abstraction level up. In threshold and multi-party ECDSA, several parties must jointly produce a nonce that is unbiased and secret from all of them, even when some participants misbehave. That is the Hidden Number Problem wearing a new coat: get the joint nonce generation subtly wrong and the biased-nonce attacks come straight back [@threshold]. On the AEAD side, none of the four ciphers we surveyed is key-committing, and that gap is exploitable.

An authenticated cipher whose ciphertext binds to exactly one key, so it cannot be decrypted to a different valid plaintext under a different key. None of AES-GCM, AES-GCM-SIV, AES-SIV, or XChaCha20-Poly1305 is key-committing, which is precisely what enables partitioning-oracle attacks.

Julia Len, Paul Grubbs, and Thomas Ristenpart showed that this non-committing property turns certain systems into partitioning oracles that recover passwords and keys [@len]. There is no drop-in standard for committing AEAD yet -- an active research front. It is worth being precise about what is not open, though: AES-GCM-SIV and AES-SIV already sit exactly at the minimum-leakage lower bound for the misuse case, because "leaks only equality" is provably optimal for any deterministic scheme [@rfc8452]. That specific gap is closed; you cannot do better, and you do not need to.

Step back and the emotional arc completes. We began thinking nonce reuse was sloppy hygiene, discovered it was a cliff, thought determinism sealed the cliff, learned determinism opened a fault door, and now find that some of the remaining doors are welded shut by theorems while others open onto genuinely unexplored rooms. None of that theory, however, changes what an engineer should actually do on Monday morning. After all of it, what do you type?

11. What a Practitioner Does Today

Everything above collapses into a decision tree that fits on an index card. You do not need to re-derive Joux's polynomial in a code review; you need two questions for signing and two for encryption.

For signing: for any (EC)DSA or DSA signer, derive the nonce with RFC 6979 or a hedged variant rather than drawing it at runtime [@rfc6979]. For greenfield systems, prefer Ed25519, which is deterministic by construction [@rfc8032]. If fault injection is a realistic threat -- smart cards, HSMs, IoT silicon an attacker can hold -- hedge, so an entropy failure degrades to safe determinism and a glitch still faces a moving target [@hedged] [@boringssl] [@goecdsa]. And never compute a nonce as rand() mod n from a raw PRNG without the anti-bias margin FIPS 186-5 specifies as Extra Random Bits [@fips1865pdf]. On hardware whose timing an attacker can measure -- smart cards, TPMs, co-located VMs -- pair all of this with a constant-time scalar multiplication: RFC 6979 fixes how $k$ is generated, not how it is used, so the Minerva, TPM-Fail, and LadderLeak timing leaks close only when $k \cdot G$ itself runs in constant time [@minerva] [@tpmfail] [@ladderleak].

For AEAD: if you can guarantee a unique nonce -- a reliable, non-resetting counter -- AES-GCM is the fastest choice, provided you cap invocations per key against the birthday bound and rekey before you approach it [@sp80038d] [@rfc8452]. If nonce uniqueness is even slightly uncertain -- multiple writers sharing a key, VM snapshots that replay state, forked or stateless workers -- reach for AES-GCM-SIV [@rfc8452] or the 192-bit-nonce XChaCha20-Poly1305 [@xchacha]. For deterministic key-wrapping, AES-SIV is purpose-built [@rfc5297].

flowchart TD S["Signing (EC)DSA or DSA"] --> Q1{"Fault injection in scope, such as smartcard or HSM or IoT"} Q1 -->|Yes| H["Hedge: nonce from key, message, and fresh entropy"] Q1 -->|No| G{"Greenfield design"} G -->|Yes| ED["Prefer Ed25519"] G -->|No| R6["Deterministic RFC 6979"] A["Choosing an AEAD"] --> Q2{"Reliable unique nonce counter"} Q2 -->|Yes| GCM["AES-GCM, cap invocations and rekey"] Q2 -->|No| MR["AES-GCM-SIV or XChaCha20-Poly1305"]

The same choices read cleanly as a do-and-do-not table:

Situation	Call this	Never this
Signing, general	RFC 6979 deterministic or hedged	`rand() mod n` from a raw PRNG
Signing, greenfield	Ed25519	Home-rolled DSA nonce logic
Signing, hardware or embedded	Hedged (key, message, entropy)	Pure determinism on a fault-exposed device
Signing, measurable hardware	Constant-time scalar multiplication	Variable-time scalar multiplication an attacker can time
AEAD, reliable counter	AES-GCM, capped per key and rekeyed	AES-GCM past its invocation limit
AEAD, uncertain uniqueness	AES-GCM-SIV or XChaCha20-Poly1305	Plain AES-GCM with hopeful nonces
Deterministic key-wrap	AES-SIV (RFC 5297)	A data-plane GCM key reused for wrapping

These abstractions land on concrete Windows components. Signature and nonce generation run through the Cryptography API: Next Generation stack, whose internals the [CNG architecture article](/blog/cng-architecture-bcrypt-ncrypt-ksps) works through. TLS record nonces are the responsibility of [SChannel](/blog/rotating-every-cipher-schannel-and-the-twenty-year-algorithm), the platform's TLS implementation. And every one of those values ultimately draws on the [Windows RNG](/blog/a-key-is-only-as-unguessable-as-the-dice-that-made-it-inside), whose seeding and clone-defense decide whether the "unique and unpredictable, once, per key" contract actually holds in practice. Read those three together and this article's rules become a specific call stack.

Note: Signing: derive the nonce (RFC 6979), prefer Ed25519, hedge on hardware. AEAD: use AES-GCM only with a guaranteed-unique counter and an invocation cap; otherwise reach for AES-GCM-SIV or a 192-bit-nonce cipher. One instinct sits under both: never trust a runtime draw to be unique and unpredictable "just once."

Sign the same message twice, with the same key, and compare the two signatures. If they are byte-for-byte identical, the signer is deterministic (RFC 6979 or Ed25519). If they differ, it is randomized or hedged. Ed25519 in most libraries will match exactly; Go's `crypto/ecdsa` will not, by design. That one comparison tells you which row of the Section 8 table you are standing in -- and whether an entropy failure at runtime would be survivable.

Two rules for two primitives, resting on a single instinct. That instinct is strong enough to design around -- but a handful of persistent myths still surface in code review and threat models, and each one hides a real misunderstanding of the mechanism. Let us dismantle them one at a time.

12. Frequently Asked Questions

No, and this distinction matters more than almost anything else here. A *repeated* nonce leaks the key from *two* signatures with certainty, through the subtraction in Section 3. A *biased* nonce is statistical: each signature is one noisy equation, and recovery needs *many* of them aggregated by a lattice or Fourier reduction [@ns] [@ladderleak]. One biased signature on its own leaks nothing you can use. "One biased signature reveals your key" is the single most common misstatement in this area. Not against every adversary. Determinism removes the repeat and generation-side bias failures completely (it does not stop a side-channel leak of $k$ during the scalar multiplication $k \cdot G$, which needs a *constant-time* implementation, not determinism), but it turns the signer into a fixed, replayable target for differential fault analysis -- proven for de-randomized Fiat-Shamir schemes including EdDSA [@hedged], and flagged by FIPS 186-5 as a special concern for deterministic schemes on embedded and smartcard devices [@fips1865pdf]. That is exactly why hedged signatures exist. No. It degrades gracefully instead of catastrophically. On a repeat it discloses only whether two messages were identical -- the provable minimum for any deterministic scheme -- never the key and never arbitrary plaintext [@rfc8452]. "Graceful" is not "free." Do not reuse nonces on purpose in the belief that the SIV mode makes it costless. No, and precision matters. A single collision instantly leaks $P_1 \oplus P_2$ and destroys confidentiality [@joux]. Recovering the authentication subkey $H$ is a *separate* step: one collision yields a set of candidate roots, and pinning $H$ uniquely generally needs two or more collisions [@joux]. Live TLS servers doing this were found forgeable in 2016 [@nda], but the mechanism is "confidentiality gone at once, forgery after enough collisions," not "one reuse equals the key." Because you cannot certify unpredictability, only fail to falsify it -- and sub-bit bias is still fatal across enough signatures. LadderLeak won with less than one bit of leakage [@ladderleak]. Hardening the generator raises the bar; it does not change the structure. Deriving the number does. Only within the birthday bound, and only if uniqueness genuinely holds. Random 96-bit nonces start colliding near $2^{48}$ messages, which is why usage caps per key exist [@rfc8452]. Worse, multi-writer keys, VM clones, and process forks silently re-emit the same nonce no matter how carefully you generated it. If uniqueness is uncertain, switch to AES-GCM-SIV [@rfc8452] or XChaCha20-Poly1305's 192-bit nonce [@xchacha]; this reuse has been observed in the wild [@nda]. No. Lattice- and Fiat-Shamir-based post-quantum signatures inherit the same sensitivity to per-signature randomness; several are precisely the de-randomized Fiat-Shamir schemes shown vulnerable to fault attacks [@hedged]. Migrating to post-quantum cryptography re-instantiates nonce discipline -- it does not retire it.

13. One Cure for Two Catastrophes

Return to that stage in Berlin in 2010, but now you can see the whole shape of the thing. The PlayStation 3 master key did not fall to a broken cipher or a weak curve; it fell to one number, used twice, and two signatures' worth of subtraction [@f0f]. The same shape swept real Bitcoin wallets when Android's generator repeated nonces [@bitcoin].

Then the required leak kept shrinking -- bit-length timing on smart cards [@minerva], side channels in TPMs [@tpmfail], less than a single bit in LadderLeak [@ladderleak], nine fixed bits and sixty signatures in PuTTY [@putty] -- and the very same disease surfaced in a cipher, where 184 live TLS servers reusing a GCM nonce were shown forgeable [@nda].

Every one of those failures shares a single sentence. Both primitives bet everything on a number that had to be unique and unpredictable exactly once, and both collapsed the moment that bet was lost. And the cures share a single sentence too. Deterministic signing derives the number from the key and the message so there is nothing left to repeat or bias [@rfc6979], while a constant-time scalar multiplication closes the side-channel leaks that determinism never touched; hedged signing keeps a sliver of entropy so a fault has no fixed target [@hedged]; misuse-resistant encryption derives the IV from the message so a repeat leaks only that two messages matched [@rfc8452].

Key idea: Two primitives, one disease, one cure: stop trusting runtime randomness for the once-per-operation number. Derive it, or make a repeat non-catastrophic. Everything else in this article is a footnote to that sentence.

Part 2 of this series taught the two ways randomness betrays you; this was the promised descent into what those betrayals actually cost and how the field designed them away. The punchline you were promised at the start has been earned line by line: in cryptography, reusing one number can cost you everything -- so build systems that never require you to trust yourself to use it only once.