Parag Mali - tag: authenticated-encryption

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 Tag Verified, the Cipher Held, the Forgery Went Through: A Field Guide to Message Authentication and Safe Composition

noreply@paragmali.com (Parag Mali) — Sat, 11 Jul 2026 01:12:01 GMT

A MAC makes forgery hard; three deployment assumptions keep it hard, and every famous break -- Flickr [@flickr-advisory], Lucky Thirteen [@cve-2013-0169], POODLE [@cve-2014-3566], the SSH plaintext-recovery attack [@apw-2009], and 184 nonce-repeating HTTPS servers [@woot16-bock] -- broke one of those assumptions, not the math. Pick the right family (PRF-based HMAC and KMAC take a reusable key and need no nonce; Wegman-Carter GMAC and Poly1305 run at line rate but demand a one-time key [@wc-1981]), verify in constant time, and always Encrypt-then-MAC over the ciphertext with an independent key and a strongly unforgeable tag [@bn-2000]. This guide traces the primitive from Carter-Wegman universal hashing in 1979 [@cw-1979] to committing AEAD in 2025 [@rfc-9771], names every failure by root cause, and ends with a decision tree and a paste-in review checklist. The one rule underneath all of it: authenticate the ciphertext, the length, and the context -- not just the message.

1. A Forgery Without a Broken Cipher

In 2009, two researchers forged valid Flickr API signatures without knowing Flickr's secret key, without finding a single MD5 collision, and without touching a cipher [@flickr-advisory]. Flickr had done what feels obviously correct -- prepend a secret to each request and hash the result -- and that one instinct silently handed signing power to anyone who had ever seen a single signed URL. The hash worked exactly as designed. The way Flickr used it was the vulnerability.

That gap -- between a primitive that is sound and a deployment that is not -- is the subject of this article, and it is worth stating as a claim you can test against every page that follows.

Key idea: A message authentication code makes forgery hard; keeping it hard is the surrounding protocol's job. Every deployed MAC ships a proof, and every proof quietly assumes three things the deployment must supply: (1) the right key discipline for its family, (2) a constant-time verify, and (3) composition over the right bytes, in the right order, binding the right context. Read that way, the entire failure catalogue is one sentence repeated -- the math never broke; a deployment broke one of these three assumptions.

Before we can prove that thesis, we need the object it is about. Informally, a MAC is a small tag you attach to a message so the receiver can tell the message came from someone who holds the shared secret key, and that nobody altered it in transit.

A MAC is a keyed algorithm that takes a secret key and a message and produces a short fixed-size tag. Anyone holding the same key can recompute the tag to verify that the message is authentic and unmodified. Unlike a plain hash, a MAC is keyed, so an attacker without the key cannot produce a valid tag; unlike a digital signature, the same secret both makes and checks the tag, so there is no public verifiability and no non-repudiation.

Now pair Flickr with a second break that fails a different assumption. In 2013, Lucky Thirteen recovered plaintext from TLS connections that used a perfectly correct HMAC -- the attack timed how the MAC was checked, not whether the MAC was strong [@cve-2013-0169]. Two production systems, two respected primitives, two failures -- and in neither case did the cryptography break. Flickr fed the hash the wrong bytes in the wrong construction; TLS checked a correct tag on a timing-leaky path.

Note: MD5 is badly broken for collision resistance, yet the Flickr forgery did not use a collision. HMAC was and is unbroken, yet Lucky Thirteen still bled plaintext. In both cases the primitive met its specification and the deployment violated an assumption the specification silently depended on. Hold onto that pattern -- it is the whole catalogue in miniature.

By the end of this field guide you will have a decision procedure and a review checklist that catch every failure in this article before it ships.The original Flickr advisory by Duong and Rizzo is no longer served from its source host; the citation here points to a 2009 Wayback Machine snapshot, which is the durable primary record [@flickr-advisory]. But a checklist without the underlying model is just cargo-culting. So start with the model. If the hash was not broken, what exactly is a MAC supposed to promise, and against whom?

2. What a MAC Actually Is

Strip away the mystique and a MAC is three algorithms and one game.

The three algorithms are KeyGen, Tag, and Verify. KeyGen samples a secret key $k$. Tag maps a key and a message $m$ to a tag $t$. Verify takes $k$, $m$, and a candidate $t$ and returns accept or reject. The whole design question is: how hard is it for someone without $k$ to make Verify say accept on a message the key-holder never authorized?

"How hard" was made precise in 1988. Shafi Goldwasser, Silvio Micali, and Ronald Rivest gave the first rigorous adversarial definition of authentication -- existential unforgeability under adaptive chosen-message attack -- while analyzing digital signatures, and MACs inherit it directly [@gmr-1988]. The game is deliberately generous to the attacker.

The adversary may ask for tags on any messages it likes, adaptively, as many as it wants. It wins if it then outputs a valid tag on any *new* message it never queried. A MAC is EUF-CMA secure if every efficient adversary wins only with negligible probability. The name is exact: "existential" means the forgery can be on any message the attacker chooses, and "adaptive chosen-message" means it sees each answer before picking its next query.

EUF-CMA is the usual bar, but composition needs a slightly stronger one, and the difference will decide whether a whole protocol stands or falls in Section 6.

SUF-CMA forbids even a *new tag on an old message*. The adversary wins if it outputs any message-tag pair that verifies and was not itself the result of a tag query -- including a second, different valid tag on a message it already asked about. Every SUF-CMA MAC is EUF-CMA, but not conversely: a MAC with malleable tags can be existentially unforgeable yet still let an attacker maul a valid tag into another valid tag.

Formally, if we write the tag oracle as $\mathsf{Tag}_k(\cdot)$ and let $Q$ be the set of message-tag pairs it returned, the strong-forgery advantage is

$$\mathsf{Adv}^{\text{suf-cma}}_{\mathsf{MAC}}(\mathcal{A}) ;=; \Pr!\left[,(m,t) \leftarrow \mathcal{A}^{\mathsf{Tag}_k(\cdot)} : \mathsf{Verify}_k(m,t)=\text{accept} ;\wedge; (m,t)\notin Q,\right].$$

A MAC is good when this probability stays negligible for every efficient $\mathcal{A}$. That single inequality is the promise Flickr's construction could not keep -- an attacker produced an accepted tag on a message that was never in $Q$.

Four primitives live near this definition, and confusing them is the source of real bugs. An unkeyed hash has no $k$, so anyone can recompute it -- it detects accidental corruption, never a motivated forger; this series covers hashes and their length-extension quirk in Part 10.

A MAC is symmetric: the same secret makes and checks the tag. A digital signature is asymmetric -- a private key signs, a public key verifies -- which buys public verifiability and non-repudiation that a MAC deliberately does not provide (Part 3 develops what the authenticated bytes must actually cover). An AEAD bundles a MAC together with encryption so one call delivers secrecy and integrity at once; Part 7 is the decision matrix for choosing among AEADs, and this article is the authentication half underneath it.

Note: Because a MAC key both signs and verifies, a valid tag proves only that someone holding the shared key produced it -- it cannot tell you which party, and it cannot be shown to a third party as proof. If you need "Alice, and only Alice, provably sent this," you need a signature, not a MAC. Reaching for a MAC where you needed non-repudiation is a design error no amount of key length fixes.

The definitions say a good MAC is unforgeable. Yet the very first keyed MACs people built were forgeable in ways the definition had not yet been written to outlaw. Stranger still, the airtight, provably unforgeable answer arrived before the practical, broken ones. Where did the idea come from?

3. Origins: Universal Hashing and One-Time Authentication

Here is the twist that reorders the whole story. The provably secure MAC was invented first, in 1979 and 1981, and then the field spent two decades shipping forgeable ones anyway. Keep that inversion in mind as the arc unfolds.

timeline title Message authentication, 1979 to 2025 1979 : Carter-Wegman universal hashing 1981 : One-time authentication, tag is hash plus one-time pad 1985 : CBC-MAC standardized in FIPS 113 1996 : HMAC nests the hash to stop length extension 2000 : Encrypt-then-MAC formalized by Bellare and Namprempre 2001 : Krawczyk indicts the SSL and SSH orderings 2004 : GMAC revives Wegman-Carter at line speed 2005 : Poly1305 brings it to fast software 2006 : HMAC proven a PRF without collision resistance 2009 : Flickr forgery and the SSH plaintext recovery 2013 : Lucky Thirteen timing oracle 2016 : KMAC keyed sponge and 184 nonce-repeating servers 2018 : TLS 1.3 record layer becomes AEAD-only 2023 : Terrapin breaks a correct channel 2025 : RFC 9771 standardizes commitment vocabulary

The starting point is a purely combinatorial object. Larry Carter and Mark Wegman, at IBM Research, asked what happens if you pick a hash function at random from a carefully built family, rather than fixing one function everyone knows [@cw-1979].

A universal family of hash functions has the property that, for any two fixed distinct inputs, a function drawn uniformly at random from the family maps them to the same output with only small, bounded probability. The bound comes from counting the functions in the family, not from any assumption about how much computing power an attacker has. It is combinatorial security, not cryptographic security -- which is exactly why it needs no unproven hardness conjecture.

Two years later, Wegman and Carter turned that object into an authenticator [@wc-1981]. The construction is startlingly small: draw a secret hash $h$ from a strongly universal family, draw a secret one-time pad $s$, and send

$$t ;=; h(m) ,\oplus, s.$$

The pad $s$ hides the value $h(m)$ completely, like a one-time pad hides a plaintext, and the universal property bounds an attacker's chance of guessing a valid tag for a different message. The result is unconditional: it holds against an adversary with unlimited computing power, assuming nothing about factoring, discrete logs, or the strength of any cipher.

Authenticate a message as the exclusive-or of a universal hash of the message and a fresh secret pad: the tag reveals nothing about the hash key, and forging a tag on a new message requires guessing a value the universal bound keeps small. The security is information-theoretic and tight -- but the pad must be used exactly once. Authenticate a second message under the same pad and the guarantee evaporates.

Take the smallest instance. Fix a prime $p$, keep a secret pair $(a, b)$, and tag a message $m$ as $t = (a\cdot m + b) \bmod p$. An attacker who sees one pair $(m_1, t_1)$ learns one linear equation in two unknowns; every candidate slope $a$ has exactly one consistent $b$, so the tag on any different $m_2$ stays uniform over all $p$ values. The best forgery succeeds with probability $1/p$. Beautiful, and useless twice: a second pair $(m_2, t_2)$ gives a second equation, the line is pinned, and every future tag is computable.

Note: "One-time" is not a restriction bolted onto Wegman-Carter authentication -- it is the security proof. The pad's single use is what buys the information-theoretic guarantee. That makes it a feature in 1981 and a landmine in 2004, when the same construction is revived at network line speed and a fast deployment reuses the pad. Every GMAC and Poly1305 nonce rule you will ever read is this 1981 constraint wearing modern clothes.

So the airtight answer existed. Yet it authenticates only one message per key, which is impractical for a general-purpose MAC.The two ideas are separate papers: the 1979 work introduced universal classes of hash functions as a combinatorial tool [@cw-1979]; the 1981 follow-up applied them to authentication and set equality [@wc-1981]. Universal hashing came first; authentication was the application. If the unconditional construction was this good but this restrictive, what did engineers reach for instead -- and why did the "obvious" keyed hashes they built break?

4. Early Approaches and Why They Broke

When engineers needed a keyed MAC in the 1990s, most reached for the hash they already had and glued a secret to it. The most natural glue is to put the key in front: compute H(secret || message) and ship the digest as the tag. It looks unforgeable -- you cannot compute the hash without the secret. It is also exactly what Flickr shipped, and it is broken by a property of the hash that has nothing to do with its collision resistance.

The property is length extension, and it is a direct consequence of how Merkle-Damgard hashes -- MD5, SHA-1, and most of SHA-2 -- are built [@length-ext-wiki]. Such a hash absorbs the message block by block into an internal state, and it emits that entire internal state as the digest. The digest is therefore a complete, resumable snapshot: given H(secret || message), you can set a fresh hash's state to that value and keep absorbing more bytes, as if you had known the secret all along.

Given the digest of `secret || message` and the length of the secret, an attacker can compute the digest of `secret || message || padding || extra` for attacker-chosen `extra`, without knowing the secret. The attack works because a Merkle-Damgard digest is the hash's full internal state, so it can be resumed. The only wrinkle is the glue `padding` the original hash appended internally, whose bytes are fully determined by the known lengths.

The forgery is mechanical once you see the state as resumable.

sequenceDiagram participant A as Attacker participant V as Verifier A->>V: Observe one signed request, message m and tag t Note over A: The tag t is the full hash state after absorbing key and m A->>A: Resume from t, append glue padding then chosen extra bytes A->>A: Keep hashing to get t2 for the extended message, no key used A->>V: Submit extended message with tag t2 Note over V: Verifier recomputes over key plus the extended message V-->>A: State matches, forged request accepted

The demonstration below builds a toy Merkle-Damgard hash whose digest is its internal state -- the essential property -- and forges a secret-prefix tag with no secret, then shows that nesting the hash (the HMAC idea) shuts the door.

Toy Merkle-Damgard hash: absorb one byte at a time; the digest IS the state. (The mixer is illustrative, not secure -- the STRUCTURE is the point.)

def compress(state, byte): return ((state * 1000003) ^ byte) & 0xFFFFFFFFFFFF # 48-bit toy state

def toy_hash(data, iv=0xA5A5A5A5A5A5): state = iv for byte in data: state = compress(state, byte) return state # digest == resumable internal state

secret = b"opensesame" # attacker does NOT know this... def prefix_mac(msg): # ...but does know len(secret) == 10 return toy_hash(secret + msg)

1) Attacker observes ONE legitimate (message, tag) pair:

seen = b"amount=10" tag = prefix_mac(seen)

2) Attacker resumes from the tag and appends -- the secret is never touched:

extra = b"&amount=1000000" forged = tag for byte in extra: forged = compress(forged, byte)

3) The verifier recomputes over secret + (seen + extra):

print("secret-prefix forgery accepted:", forged == prefix_mac(seen + extra))

The HMAC-style fix: nest, so the outer pass re-absorbs the inner digest.

def nested_mac(msg): inner = toy_hash(secret + msg) return toy_hash(secret + inner.to_bytes(6, "big"))

resumed = nested_mac(seen) for byte in extra: resumed = compress(resumed, byte) print("nested (HMAC-style) forgery accepted:", resumed == nested_mac(seen + extra)) `}

The first line prints True, the second False. That single flip is the difference between the Flickr construction and HMAC, and it is Aha number one for this article.

Note: H(secret || message) over any Merkle-Damgard hash is not a MAC. It authenticates nothing an attacker who has seen one tag cannot forge, regardless of how strong the underlying hash is. MD5's collision weakness is irrelevant here -- the Flickr forgery used no collision at all [@flickr-advisory]. If you find md5(secret + data) or sha256(secret + data) in a code review, you have found a length-extension forgery waiting to happen.

The mirror construction, secret-suffix H(message || secret), resists length extension because the secret is absorbed last.Secret-suffix is not safe either: since an attacker who finds two messages colliding under the raw hash gets a tag collision for free, H(m || k) reduces to the hash's collision resistance, so it dies with MD5 and SHA-1 -- the opposite failure mode from secret-prefix, same verdict [@length-ext-wiki]. Neither ad-hoc glue is a MAC.

The block-cipher world made a parallel mistake. CBC-MAC, standardized as FIPS 113 in 1985, runs a block cipher in CBC mode with a zero IV and keeps the final ciphertext block as the tag [@fips-113]. It carries an unstated assumption: every message is the same fixed length. Bellare, Kilian, and Rogaway turned the failure of that assumption into a theorem in 1994 -- secure for fixed-length messages, trivially forgeable once lengths vary [@bkr-1994].

The splice is mechanical. Query the tag of a one-block message $m_1$ to get $t_1 = E_k(m_1)$; then the two-block message $m_1 ,\Vert, (m_1 \oplus t_1)$ has tag $E_k\big((m_1 \oplus t_1)\oplus t_1\big) = E_k(m_1) = t_1$ -- a valid tag on a message never queried, produced with no key.

Both failures teach the same lesson, and it organizes the rest of this guide: a raw hash is not a MAC, and raw CBC-MAC is not a MAC for variable-length messages. Both fixes point the same direction -- stop exposing resumable internal state, and make the tag depend on length. From here the field split into two lineages. Which one wins?

5. The Evolution: Two Lineages Diverge

The field did not pick one winner. It split into two families that both survive today, and choosing between them is still the single most consequential decision a practitioner makes about authentication. One family keeps a computational assumption and buys a reusable key; the other keeps the 1981 one-time pad and buys blazing speed.

The PRF lineage: HMAC and CMAC

Bellare, Canetti, and Krawczyk fixed the secret-prefix disaster in 1996 by nesting the hash so the attacker never sees a resumable inner state [@bck-1996]. Standardized a year later as RFC 2104, HMAC computes two keyed passes [@rfc-2104]:

$$\mathsf{HMAC}(k, m) ;=; H\big((k \oplus \text{opad}) ,\Vert, H((k \oplus \text{ipad}) ,\Vert, m)\big).$$

The outer hash re-absorbs the inner digest, so a resumed inner state is useless -- length extension cannot reach the output.

RFC 2104 also fixes how the key becomes block-sized before those two XORs: a key longer than the hash's block size is first hashed down to a digest, and a shorter key is zero-padded up to the block size [@rfc-2104]. That is why HMAC accepts a key of any length -- it normalizes every key to exactly one block before mixing in `ipad` and `opad`. flowchart TD K[Secret key k] --> IP[k XOR ipad] M[Message m] --> INNER[Inner hash of ipad key then message] IP --> INNER INNER --> ID[Inner digest, never emitted directly] K --> OP[k XOR opad] ID --> OUTER[Outer hash of opad key then inner digest] OP --> OUTER OUTER --> T[HMAC tag]

The deepest fact about HMAC is also the most misunderstood, and it took another decade to prove. In 2006 Bellare showed HMAC is a pseudorandom function under the sole assumption that the hash's compression function is a PRF -- collision resistance is not required at all [@bellare-2006].

A keyed function is a PRF if no efficient adversary, allowed to query it on inputs of its choice, can distinguish its outputs from those of a truly random function. A PRF makes an immediate MAC: to forge a tag on a fresh message is to predict a value that, by assumption, looks uniformly random, which succeeds only with negligible probability. Unforgeability falls out of pseudorandomness.

This is why the collision breaks of MD5 and SHA-1 never touched HMAC-MD5 or HMAC-SHA-1. Collisions attack collision resistance; HMAC never needed it.

Note: The folklore "HMAC needs a collision-resistant hash" is false, and it has been false since 2006 [@bellare-2006]. HMAC needs the compression function to behave like a PRF -- a different, and for MD5 and SHA-1 still-standing, assumption. This is not a licence to use MD5 in new systems, but it is why the practical world did not catch fire when SHA-1 collisions arrived.

The block-cipher branch got the same repair. CMAC, from Iwata and Kurosawa's OMAC and standardized as NIST SP 800-38B, derives two subkeys from the block cipher and mixes one into the final block, killing the variable-length splice that sank raw CBC-MAC while keeping a single key [@omac-2003] [@sp-800-38b]. It is the block-cipher PRF-MAC, useful where a device already has AES hardware but no hash.

The survival of HMAC-SHA-1 is the cleanest real-world confirmation of the 2006 proof: SHA-1's collision resistance collapsed publicly, yet no HMAC-SHA-1 forgery followed, because the security reduction never invoked collision resistance in the first place [@bellare-2006].

The sponge refinement: KMAC

SHA-3 changed the substrate. A Keccak sponge splits its state into a public rate and a secret capacity, and it never emits the capacity [@fips-202]. That single property makes the HMAC nesting trick unnecessary: you can key a sponge by simply absorbing the key first.

A sponge function absorbs input into a large internal state divided into a public "rate" (the bytes that interact with input and output) and a secret "capacity" (bytes never revealed). Because the capacity is never output, prepending a key and absorbing it yields a keyed authenticator with no length-extension surface and no double hashing -- the key is protected by the same hidden capacity that protects the hash.

NIST SP 800-185 builds KMAC on cSHAKE this way: prepend the key, absorb, squeeze [@sp-800-185]. Keying is native, domain separation is built in through customization strings, and the tag length is a free parameter because the sponge is an extendable-output function. It is, conceptually, the cleanest MAC in the standard catalogue -- but conceptual cleanliness is not deployment.

KMAC is a real, standardized primitive [@sp-800-185], implemented in OpenSSL 3.0 and later (as the `KMAC-128`/`KMAC-256` EVP_MAC) [@openssl-kmac], as well as BouncyCastle [@bouncycastle-kmac] and Botan [@botan-kmac]. It is not academic-only. But its production footprint is thin next to HMAC, GMAC, and Poly1305, for reasons that are historical inertia rather than cryptography: SHA-2 and HMAC are welded into TLS, IPsec, JWT, HKDF, and hardware everywhere, and SHA-3 adoption trails. This guide gives KMAC full conceptual treatment and makes no claim about its market share -- no reliable quantitative figure exists in a primary source.

Both HMAC and KMAC share a decisive operational property: a reusable key, no nonce, an unbounded stream of messages under one secret. That is the easy side of assumption one. The other lineage trades it away for speed.

The Wegman-Carter lineage: GMAC and Poly1305

In 2004 and 2005, two designs dragged the 1981 one-time construction into high-speed networking. Both keep the pattern tag = universal_hash(m) + one_time_pad, and both solve the "fresh pad per message" problem the same way -- derive the pad from a cipher keystream instead of shipping new randomness.

GHASH, the core of GCM, is a polynomial universal hash over the finite field $\mathrm{GF}(2^{128})$: it evaluates $\sum_i m_i \cdot H^{,L-i+1}$ at a secret point $H = E_k(0)$, then masks the result with an AES-encrypted counter block [@mcgrew-viega-2004]. Run GCM with an empty plaintext and you get GMAC, an authentication-only MAC over associated data, standardized in NIST SP 800-38D [@sp-800-38d]. Poly1305 evaluates a message polynomial modulo the prime $2^{130}-5$ under a secret $r$, then adds a one-time pad $s$; deployed as ChaCha20-Poly1305, it draws a fresh $(r, s)$ from the cipher keystream for every message [@rfc-8439].

flowchart TD N[Nonce and key] --> KS[Cipher keystream block] KS --> R[One-time hash key r] KS --> S[One-time pad s] M[Message m] --> P[Polynomial hash of m under r] R --> P P --> ADD[Add the one-time pad s] S --> ADD ADD --> T[Authentication tag] T -.reuse the same nonce.-> LEAK[Two tags cancel the pad, leaking hash of m1 minus hash of m2]

This is where the 1981 constraint re-enters as a deployment contract. The pad is safe only if the $(key, nonce)$ pair never repeats. Reuse it and the pad cancels out of the difference of two tags, exactly as the toy line did in Section 3 -- except now the "hash" is a polynomial an attacker can then start solving.

A one-time Wegman-Carter MAC: tag = poly_hash(m, r) + s (mod p). Use (r, s) ONCE.

p = (1 << 130) - 5 # the Poly1305 prime, 2**130 - 5

def poly_hash(msg, r): acc = 0 for i in range(0, len(msg), 16): chunk = msg[i:i+16] limb = int.from_bytes(chunk, "little") + (1 << (8 * len(chunk))) acc = ((acc + limb) * r) % p return acc

In ChaCha20-Poly1305 both r and s come fresh from the keystream, per message.

r = 0x1bf54941aff6bf4afdb1f2a3c4d5e6f7 s = 0x0102030405060708090a0b0c0d0e0f10

def one_time_tag(msg): return (poly_hash(msg, r) + s) % p

THE MISTAKE: two messages under the SAME (r, s).

m1, m2 = b"transfer 10 dollars now", b"transfer 9999 bucks now" t1, t2 = one_time_tag(m1), one_time_tag(m2)

The pad s cancels in the difference -- a relation that does not depend on s at all:

lhs = (t1 - t2) % p rhs = (poly_hash(m1, r) - poly_hash(m2, r)) % p print("pad cancelled, tag difference is key-independent:", lhs == rhs) `}

It prints True: subtract two tags produced under the same one-time key and the secret pad vanishes, handing the attacker a clean algebraic relation in the hash key. That is the first step of the "forbidden attack" the failure catalogue will name -- and it is why the distinction below is not pedantry.

The master key versus one-time key split is the heart of the fork. HMAC and KMAC take a master key and authenticate forever under it. GMAC and Poly1305 take a one-time key per message; the ChaCha20-Poly1305 keystream manufactures that one-time key so the master key stays put, but the per-message pad is still strictly single-use. Confuse the two and you get a catastrophe, not a slow degradation.

The whole construction catalogue, side by side:

Table 1 -- MAC constructions, and what each one assumes.

Construction	Year	Core idea	Key model	Strength	Weakness	Status
Carter-Wegman one-time [@wc-1981]	1981	$\mathsf{UH}(m) \oplus \text{pad}$	One-time pad per message	Information-theoretic, no hardness assumption	Pad is strictly single-use	Foundational, revived
Secret-prefix $H(k \Vert m)$ [@length-ext-wiki]	1990s	Prepend key, hash	Reusable	Trivial to build	Length-extension forgeable	Superseded, insecure
Secret-suffix $H(m \Vert k)$ [@length-ext-wiki]	1990s	Append key, hash	Reusable	No length extension	Reduces to a hash collision	Superseded, insecure
CBC-MAC [@fips-113]	1985	CBC chain, keep last block	Reusable	First standardized block-cipher MAC	Variable-length splicing forgery	Historical
HMAC [@rfc-2104]	1996	Nested keyed hash	Reusable, no nonce	PRF not collision resistance, length-ext immune	Serial, no line-rate shortcut	Active, default PRF-MAC
CMAC [@sp-800-38b]	2005	CBC-MAC plus final subkey	Reusable, no nonce	Fixes CBC-MAC with one key	Block-cipher birthday ceiling	Active, niche
GMAC / GHASH [@sp-800-38d]	2004	Polynomial hash over $\mathrm{GF}(2^{128})$	One-time pad per message	Carry-less-multiply hardware (PCLMULQDQ/PMULL)	Nonce reuse is fatal	Active, inside GCM
Poly1305 [@rfc-8439]	2005	Polynomial hash mod $2^{130}-5$	One-time key per message	Fast in pure software, cipher-agnostic	One-time key per message	Active, inside ChaCha20-Poly1305
KMAC [@sp-800-185]	2016	Keyed sponge, cSHAKE	Reusable, no nonce	Native keying, domain separation, XOF tag	Lightly deployed	Active, niche

You can now build an unforgeable tag two ways: a reusable-key PRF or a one-time-key universal hash. But a perfect tag attached in the wrong place, in the wrong order, or over the wrong bytes is still useless. How do you combine a MAC with a cipher without reopening the door you just closed?

6. Composition Done Right, and the Verification Contract

SSL chose one order for combining its cipher and its MAC. SSH chose another. Both were quietly indicted by a theorem years before either was broken in the field. This section is where the second aha moment lands: strength was never the variable -- discipline and order were.

Bellare and Namprempre formalized the question in 2000 by splitting integrity into two notions [@bn-2000]. Integrity of plaintexts (INT-PTXT) says an attacker cannot make the receiver accept a plaintext the sender never sent. Integrity of ciphertexts (INT-CTXT) is stronger: the attacker cannot even produce a new ciphertext the receiver will accept. Their result is the load-bearing one: applying the MAC to the ciphertext -- Encrypt-then-MAC -- yields both IND-CCA confidentiality and INT-CTXT, and it is the only one of the three generic orders that reaches those strong notions.

Encrypt the plaintext, then compute the MAC over the resulting *ciphertext* (plus any associated data and length), and send ciphertext and tag together. On receipt, verify the tag *before* touching the ciphertext; if it fails, discard without decrypting. EtM is the only generic composition order that provably delivers integrity of ciphertexts, and it does so only under two preconditions: the MAC must be strongly unforgeable and the encryption and MAC keys must be independent.

Those two preconditions are not decoration. If the MAC is only EUF-CMA rather than SUF-CMA, the guarantee weakens from INT-CTXT down to INT-PTXT, because a malleable tag lets an attacker produce a different valid ciphertext for the same plaintext [@bn-2000]. And the keys must be independent -- reusing one key for both encryption and authentication voids the proof.

A year later Krawczyk sharpened the verdict [@krawczyk-2001]. He proved that any secure-channel protocol required to work with any secure cipher and any secure MAC must use Encrypt-then-MAC, and he built a perfectly secret cipher that becomes totally insecure under MAC-then-Encrypt -- SSL's order -- and under Encrypt-and-MAC -- SSH's order.

"[A]ny secure channels protocol designed to work with any combination of secure encryption ... and secure MAC must use the encrypt-then-authenticate method." -- Hugo Krawczyk, The Order of Encryption and Authentication for Protecting Communications, 2001 [@krawczyk-2001]

Here is the precision that separates an expert from a slogan-repeater: Krawczyk also proved that MAC-then-Encrypt is secure for specific cipher modes, namely CBC and CTR [@krawczyk-2001]. MtE is therefore fragile and not generically secure -- it holds only when you can prove something extra about the exact cipher -- but it was never unconditionally "broken." Say "MtE is broken" in an interview and you are wrong; say "MtE is not generically secure, so do not use it in new designs" and you are exactly right.

flowchart TD subgraph EtM["Encrypt-then-MAC, generically secure"] E1[Plaintext] --> E2[Encrypt] E2 --> E3[Ciphertext] --> E4[MAC the ciphertext] E4 --> E5[Receiver verifies tag first, then decrypts] end subgraph MtE["MAC-then-Encrypt, fragile"] M1[Plaintext] --> M2[MAC the plaintext] M2 --> M3[Encrypt plaintext and tag together] M3 --> M4[Receiver decrypts first, only then verifies] end subgraph EM["Encrypt-and-MAC, fragile"] A1[Plaintext] --> A2[Encrypt] A1 --> A3[MAC the plaintext, tag sent in the clear] A2 --> A4[Receiver decrypts, and the tag leaks plaintext] end

The diagram shows the mechanism behind every padding-oracle and SSH break at once: in the two fragile orders, the receiver must decrypt or parse before it can verify, so the very act of processing attacker-chosen bytes leaks information. Encrypt-then-MAC verifies first and refuses to decrypt a single byte of an unauthenticated ciphertext.

Key idea: Authenticate the ciphertext, not the plaintext. Encrypt-then-MAC over the ciphertext -- with an independent key, a strongly unforgeable tag, and coverage of the associated data and length -- is the only generic order that lets the receiver reject a forgery before it decrypts anything. Every composition break in the catalogue is a system that decrypted or parsed before it verified.

Table 2 -- Composition orders, ranked by what they generically guarantee.

Order	Idea	Generic security	Weakness	Status
MAC-then-Encrypt [@krawczyk-2001]	MAC the plaintext, then encrypt both	Not generic, secure only for CBC or CTR	Decrypt-before-verify padding and timing oracles	Superseded, fragile
Encrypt-and-MAC [@apw-2009]	Encrypt, and MAC the plaintext separately	Not generic	Tag over plaintext leaks, MAC-covered length field abused	Superseded, fragile
Encrypt-then-MAC [@bn-2000]	MAC the ciphertext	IND-CCA plus INT-CTXT	Needs SUF-CMA, independent keys, constant-time verify	Active, canonical
AEAD [@rfc-8446]	EtM internalized plus nonce management	IND-CCA plus INT-CTXT by construction	Key-commitment gap	Active, default
Committing AEAD [@rfc-9771]	AEAD plus key and context commitment	Adds commitment	Still standardizing, cost profiling	Frontier

The order is only half of correct composition. The other half arrived not from a theorem but from a field disclosure. In 2009 Nate Lawson found that Google's Keyczar library compared HMAC tags byte by byte and returned as soon as two bytes differed [@keyczar-2009]. That early exit turns verification time into a side channel: a forged tag that matches more leading bytes takes measurably longer to reject, so an attacker can recover the correct tag one byte at a time by timing responses.

Q0 -- Yes --> ASCON[Ascon, SP 800-232]
Q0 -- No --> Q1&#123;"Is there a ciphertext to authenticate?"&#125;
Q1 -- No --> HMAC[HMAC-SHA-256, reusable key, no nonce]
Q1 -- Yes --> Q2&#123;"Can you guarantee a unique nonce per key?"&#125;
Q2 -- No --> SIV[AES-GCM-SIV, misuse-resistant]
Q2 -- Yes --> Q3&#123;"Is AES-NI hardware available?"&#125;
Q3 -- Yes --> GCM[AES-GCM, rekey before the per-key ceiling]
Q3 -- No --> CHACHA[ChaCha20-Poly1305]

Read the tree as the three assumptions in order. If there is no ciphertext to bind -- key derivation, a token, a one-time password -- use HMAC-SHA-256 with a key of at least 128 bits, a full-length tag, and a constant-time verify; there is no nonce to mismanage, so assumption one is nearly free. This is the right tool for HKDF [@rfc-5869], JWT's HS256 [@rfc-7518], TOTP, HOTP, and PBKDF2.

If there is a ciphertext, do not hand-roll a MAC plus cipher -- reach for an AEAD, which internalizes Encrypt-then-MAC so you cannot mis-order it. Pick ChaCha20-Poly1305 when you lack AES hardware acceleration, especially on mobile and embedded targets, where its per-key budget is effectively unbounded [@rfc-8439]. Pick AES-GCM when you have AES-NI, and rekey before the $2^{23}$-packet ceiling on high-volume links [@rfc-9001]. If you cannot guarantee nonce uniqueness at scale, step down to AES-GCM-SIV, which degrades gracefully instead of catastrophically on reuse [@rfc-8452].

Two niche branches sit off the main tree. Use GMAC for authentication-only data, such as MACsec framing, with a guaranteed-unique nonce [@sp-800-38d] [@ieee-802-1ae]. Use KMAC when you are already in a Keccak or SHA-3 stack, or when you need domain separation or variable-length tags [@sp-800-185]. And on constrained or side-channel-sensitive hardware, use Ascon [@sp-800-232].

Then there are the rules that apply always, regardless of which box the tree lands in: Encrypt-then-MAC or an AEAD that internalizes it; independent encryption and MAC keys; a constant-time compare; a tag of at least 128 bits with documented truncation floors [@rfc-4868]; authentication that covers the associated data, the length, the version, and the session context; a committing AEAD when one ciphertext might be opened under multiple keys [@bellare-hoang-2022]; and a misuse-resistant AEAD when nonce uniqueness cannot be guaranteed [@rfc-8452].

Key idea: Review authentication code against the checklist and its negation. The checklist tells you what a correct design does; the misuse list tells you what every named CVE did instead. Run any authentication path past both -- if it matches even one line of the misuse list, you have found your next vulnerability before an attacker does.

The negation is the misuse catalogue -- each row is a line of the checklist inverted, and it maps one-to-one onto a named break from Section 7.

Table 6 -- Common misuse, the break it produced, and the fix.

Misuse in real code	Named break it caused	Fix
Secret-prefix $H(k \Vert m)$ MAC	Flickr length extension [@flickr-advisory]	Use HMAC or KMAC
Reusing a GCM nonce or Poly1305 one-time key	Joux, Nonce-Disrespecting [@woot16-bock]	Guarantee uniqueness or use AES-GCM-SIV
`==` or `memcmp` tag comparison	Keyczar timing leak [@keyczar-2009]	Use a constant-time compare
MAC-then-Encrypt or Encrypt-and-MAC in new code	Lucky Thirteen, POODLE, SSH recovery [@cve-2013-0169]	Use an AEAD (Encrypt-then-MAC)
Over-truncated tags	Forgery near the $2^{-t}$ floor [@rfc-4868]	Keep the tag at least 128 bits
One shared key for encryption and MAC	Voids the Encrypt-then-MAC proof [@bn-2000]	Derive independent keys
MACing the plaintext instead of the ciphertext	Padding oracles [@vaudenay-2002]	MAC the ciphertext
Forgetting AD, length, version, context	Terrapin [@terrapin-site]	Bind the full context
Treating "MAC verified" as "key committed"	Invisible salamanders [@bellare-hoang-2022]	Use a committing AEAD

Note: Run every authentication path past these ten lines: - Is the tag over the ciphertext (Encrypt-then-MAC), never the plaintext? - Are the encryption and MAC keys independent? - Is the MAC strongly unforgeable (SUF-CMA), not merely EUF-CMA? - Is the tag comparison constant-time (compare_digest, timingSafeEqual, ConstantTimeCompare)? - Is the whole decrypt-and-verify path constant-time, not just the compare? - Is the tag at least 128 bits, with any truncation documented against the birthday bound? - For a one-time-key MAC (GMAC, Poly1305), is nonce uniqueness guaranteed, or are you on a misuse-resistant mode? - Does the authenticated data cover length, version, ordering, and session context? - Is there any H(secret || message) secret-prefix construction? (Replace with HMAC or KMAC.) - Could one ciphertext open under two keys? If so, use a committing AEAD. Any single failure here is a plausible next CVE.

That checklist and its negation are the working payoff of the whole field guide. Before the conclusion ties them back to the thesis, seven specific beliefs produce most of the remaining real-world authentication bugs -- and each is a corollary of the same one sentence.

13. Frequently Corrected Misconceptions

No. As Section 5 established, Bellare's 2006 proof rests HMAC's security on a single property of the underlying compression function -- that it is itself a PRF -- and not on collision resistance [@bellare-2006]. Since a collision attack targets a property the proof never relies on, HMAC-SHA-1 and HMAC-MD5 kept standing when the SHA-1 and MD5 collision breaks landed. Use HMAC-SHA-256 in new systems for margin, but understand that the reason is prudence, not a collision threat. No, and the difference is the most dangerous one to miss. HMAC takes a reusable key with no nonce. GMAC and Poly1305 are Wegman-Carter one-time-key MACs [@wc-1981]: they need a fresh, unique per-message key, and reusing it is catastrophic, not a gentle degradation. The 184 HTTPS servers caught repeating GCM nonces were forgeable precisely because a one-time construction was treated like a reusable one [@woot16-bock]. Same tag length, completely different key contract. No. HMAC exists to defeat length extension on Merkle-Damgard hashes, but a Keccak sponge never emits its capacity, so it has no length-extension surface and keys natively -- just use KMAC [@sp-800-185]. In fact you cannot build HMAC on a SHAKE extendable-output function anyway; Python's `hmac` module notes that XOFs such as SHAKE-128 and SHAKE-256 cannot be used with HMAC [@python-hmac]. KMAC is the SHA-3-native answer. No -- it is fragile, which is a different and more precise claim. Krawczyk proved MAC-then-Encrypt is *not generically secure*, yet also proved it *is* secure for CBC and CTR modes specifically [@krawczyk-2001]. So it was never unconditionally broken; it is simply deprecated for new designs, where a modern AEAD or Encrypt-then-MAC removes the cipher-specific precondition it depends on. Reach for one of those instead, but do not call MtE "broken." Not by itself, and the overstatement matters. A single $(key, nonce)$ reuse immediately leaks a tag relation and the XOR of the two plaintexts [@joux-2006]. Recovering the subkey $H$ outright is a taller order: a single reuse leaves a root-finding equation with several possible solutions for $H$, so narrowing them to the one true value takes at least a second collision, and usually more. So "one reuse recovers the key" is wrong; "one reuse is already a break, and more reuse recovers the key" is right. No -- there is a real-world counterexample. In 2009 Google's Keyczar library did a byte-wise tag comparison with an early exit, and that timing difference let an attacker recover valid tags one byte at a time [@keyczar-2009]. The comparison time leaked the secret the MAC existed to protect. Constant-time compare is a correctness requirement, not an optimization, and every major platform ships a named primitive for it. No. AEAD handles the encrypted channel, but plenty of jobs have no ciphertext to bind and still need authentication. HKDF key derivation [@rfc-5869], JWT's `HS256` [@rfc-7518], TOTP and HOTP one-time passwords, and PBKDF2 are all standalone HMAC. The standalone MAC did not disappear with AEAD; it moved to the places where you are authenticating keys, tokens, or messages rather than protecting a ciphertext.

Every myth here is a corollary of one sentence, which the conclusion now restates with the whole catalogue behind it.

14. The Math Never Broke

Return to Flickr, now fully understood. Two researchers forged valid API signatures with no key, no collision, and no cipher work, because Flickr's secret-prefix H(secret || params) construction handed out its resumable hash state as the tag [@flickr-advisory]. The hash met its specification exactly. The deployment broke assumption three -- the wrong construction over the wrong bytes -- and that was enough.

Line up the rest of the catalogue and the pattern is total. Lucky Thirteen and POODLE broke order and timing, decrypting before verifying [@cve-2013-0169] [@cve-2014-3566]. The SSH plaintext-recovery attack broke order, authenticating the plaintext and acting on a MAC-covered length field [@apw-2009]. The 184 nonce-repeating GCM servers broke key discipline, reusing a one-time pad [@woot16-bock]. Terrapin broke context, leaving the transcript and sequence numbers unbound even though the cipher, the MAC, and the order were all correct [@terrapin-site]. Not one of them broke AES, SHA-2, or a polynomial hash. Every single failure broke the contract around the primitive.

That is the whole thesis, proven by the evidence rather than asserted: a MAC makes forgery hard, and three deployment assumptions -- the right key discipline, a constant-time verify, and composition over the right bytes in the right order binding the right context -- are what keep it hard. The decision tree and the checklist in Section 12 are simply those three assumptions made executable. Carry them, and their negation, into every review.

The frontier moves the bar again: soon "the tag verified" should also mean "this ciphertext commits to one key and one context," the committing-AEAD work this series develops further in Part 7. And the deeper machinery lives in the siblings -- the security definitions of Part 1, the one-time-key generation of Part 2, the canonicalization discipline of Part 3, the block modes of Part 5, the padding oracles of Part 6, and the AEAD decision matrix of Part 7. This part is the authentication spine that runs through all of them.

The math never broke; a deployment broke one of three assumptions. Authenticate the ciphertext, the length, and the context -- not just the message.

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.

The Ciphertext Was Unbreakable. The Attacker Rewrote It Anyway: A Field Guide to Block Cipher Modes

noreply@paragmali.com (Parag Mali) — Wed, 08 Jul 2026 21:51:08 GMT

A block cipher only enciphers one fixed-size block. A "mode of operation" is the wrapper that turns it into a scheme for real messages -- and every mode answers only one of two questions: can the attacker *read* it (confidentiality), or can the attacker *change* it (integrity)? The five SP 800-38A modes -- ECB, CBC, CFB, OFB, CTR -- are all malleable, so an attacker who cannot decrypt your ciphertext can still predictably edit the plaintext, and ECB additionally leaks structure outright (the penguin, Adobe's 153 million passwords). This field guide hands you one lens -- *which question did this mode answer, and was its IV/nonce contract honored?* -- and uses it to walk each mode's exact contract, a named failure catalog (Vaudenay, BEAST, Lucky Thirteen, POODLE, Sweet32, Efail, GCM nonce reuse), and the fix: authenticated encryption, whose dominant AES instances (GCM equals CTR plus GHASH, CCM equals CTR plus CBC-MAC) are literally these modes plus a MAC. It closes with the 2024-2026 state of the art (IR 8459, the ECB sunset, Ascon, nonce-misuse-resistant AES-GCM-SIV) and a decision guide for using these primitives correctly.

1. Two Lines of Code

A bank encrypts the message "transfer $9" with AES and a 256-bit key and sends the ciphertext across a network an attacker completely controls. He cannot read a single byte of it. AES is unbroken and will stay unbroken. Yet by flipping a few bits he cannot even decrypt, he turns the message into "transfer $9,000,000," and the receiver accepts the change as authentic. The encryption was never broken. It simply answered the wrong question.

How can a ciphertext be unreadable and freely editable at once? The trick is not a flaw in AES but a property of the mode -- the wrapper that stretches a one-block cipher across a longer message. Many modes turn the cipher into a keystream generator and combine it with the plaintext by XOR, so $C = P \oplus \text{keystream}$. Rearrange the algebra: $P = C \oplus \text{keystream}$. An attacker who XORs a chosen delta into the ciphertext XORs exactly that delta into the recovered plaintext. He needs no key, reads nothing, and the receiver decrypts a perfectly well-formed forgery. That is one half of the story: the integrity question was never answered.

The other half is uglier, because it fails the first question too. In 2013, attackers exposed roughly 153 million Adobe account records. The passwords were not hashed. They were encrypted, with 3DES in ECB mode and no salt [@troyhunt-adobe-2013]. ECB enciphers each block independently, so identical passwords produced identical ciphertext. Combined with the unencrypted password hints Adobe stored beside them, enormous numbers of passwords were reconstructed without anyone ever breaking 3DES [@troyhunt-adobe-2013]. The cipher was fine. The mode leaked the plaintext.

Two stories, one shape. In each, the cipher did exactly what it promised and the attacker still won. That is because a mode of operation answers up to two independent questions, and the five most famous modes answer only one:

Can the attacker read it? That is confidentiality.
Can the attacker change it? That is integrity.

The five modes standardized for decades -- ECB, CBC, CFB, OFB, CTR -- answer only the first question. ECB answers even that one wrongly. Every named break in this field, past or future, reduces to one diagnostic sentence: which of the two questions did this mode answer, and was its IV/nonce contract honored? Hold that sentence in your head and the whole subject becomes legible.

flowchart TD Mode["A block cipher mode of operation"] Mode --> C["Question 1: can the attacker READ it? (confidentiality)"] Mode --> I["Question 2: can the attacker CHANGE it? (integrity)"] C --> Cans["Answered only if the IV or nonce contract is honored"] I --> Ians["Never answered by the five SP 800-38A modes"] Cans --> BreakA["Break type A: violated IV/nonce contract (BEAST, GCM nonce reuse)"] Ians --> BreakB["Break type B: missing integrity answer (Efail, bit-flipping, truncation)"]

This is Part 5 of a field guide for protocol designers. It leans on two earlier parts without re-deriving them: Part 1 gave us the security definitions this article keeps invoking -- IND-CPA, IND-CCA2, INT-CTXT -- and Part 2 gave us the discipline of generating initialization vectors and nonces. Here we spend those definitions on a single primitive: the block cipher mode.

If AES was never broken in either story, what actually failed? To answer, you first have to know what a block cipher can and cannot do on its own, and why a mode was mandatory from the very first day it shipped.

2. A Cipher That Only Speaks in Blocks

A block cipher is smaller than you think. DES (1977) enciphers exactly 64 bits at a time. AES (2001) enciphers exactly 128. Feed it more and it simply refuses. It is a keyed permutation on one fixed-size block and physically cannot accept a message longer than that.

A keyed, invertible permutation on one fixed-size block of bits, written $E_k : \{0,1\}^n \to \{0,1\}^n$ for a key $k$ and block size $n$ (64 bits for DES, 128 for AES). It maps one $n$-bit input to one $n$-bit output and back. It has no notion of a message, a length, or a stream.

Because real messages are almost never exactly one block long, every use of a block cipher needs a wrapper: a rule for chopping the message into blocks, deciding what each block's input should be, and stitching the outputs back together. That wrapper is the mode of operation.

The algorithm that lifts a one-block cipher to messages of arbitrary length. It specifies how plaintext is partitioned, what feeds into each block cipher call, and how the results combine into a ciphertext. The mode -- not the cipher -- decides whether identical plaintext leaks, whether the scheme is parallel, and what the initialization-vector or nonce rule is.

The primitive came first. Horst Feistel's work at IBM in the early 1970s produced the Feistel network that became DES, a 64-bit keyed permutation blessed as a federal standard in 1977 [@feistel-1973][@fips-46-3]. The 64-bit block chosen here is the exact quantity that dies, 39 years later, to the Sweet32 attack.

The first wrapper followed almost immediately. In 1976, William Ehrsam, Carl Meyer, John Smith, and Walter Tuchman at IBM filed the patent on Cipher Block Chaining -- the idea of feeding each plaintext block the previous ciphertext block before encryption, so that identical plaintext blocks stop producing identical ciphertext (US Patent 4,074,066, granted 1978) [@cbc-patent-4074066].The patent's actual title is "Message verification and transmission error detection by block chaining" [@cbc-patent-4074066]. That is historically ironic: CBC as a confidentiality mode provides no message verification -- no integrity -- at all, which is the very gap this article is about.

Counter mode arrived on paper three years later. Whitfield Diffie and Martin Hellman described encrypting a counter to make a keystream in their 1979 survey "Privacy and Authentication," turning a block cipher into a parallelizable stream cipher [@diffie-hellman-1979][@rogaway-modes-2011].Counter mode was described "just as early as the basic-four modes," in Rogaway's words, "yet for some reason it was not included in the initial batch" [@rogaway-modes-2011]. It waited 22 years for a federal standard. The exact page in Proc. IEEE 67(3) is gated behind IEEE Xplore, so the DOI is the stable handle and Rogaway's 2011 survey carries the attribution [@diffie-hellman-1979][@rogaway-modes-2011].

Then the standard fixed the toolkit. In December 1980 the National Bureau of Standards published FIPS 81, DES Modes of Operation, sanctioning four ways to stretch DES across real traffic: ECB, CBC, CFB, and OFB [@fips-81]. Counter mode was left out. It did not enter a NIST standard until Morris Dworkin's SP 800-38A re-specified all five modes for the AES era in December 2001, finally adding CTR as the fifth -- 22 years after Diffie and Hellman [@nist-sp-800-38a].

flowchart LR A["1976: CBC invented at IBM"] --> B["1979: Counter mode, Diffie-Hellman"] B --> C["1980: FIPS 81 standardizes ECB, CBC, CFB, OFB"] C --> D["1997: BDJR concrete-security proofs"] D --> E["2000-2001: Encrypt-then-MAC proven, SP 800-38A adds CTR"] E --> F["2004-2007: GCM and CCM, CTR plus a MAC"] F --> G["2011-2018: BEAST, Lucky Thirteen, POODLE, Sweet32, Efail"] G --> H["2024-2025: NIST IR 8459, Ascon"]

Here is the load-bearing historical fact. Every one of these five modes is a confidentiality construction. Integrity -- the second question, "can the attacker change it?" -- was filed under a separate heading called a message authentication code, and in practice it was usually forgotten. FIPS 81 and SP 800-38A specify no integrity mechanism for any of the five [@fips-81][@nist-sp-800-38a]. That separation of concerns, confidentiality here and integrity somewhere else, is the original sin the rest of this story pays for.

So the toolkit was frozen by 1980 (four modes) and completed by 2001 (a fifth), every one a way to hide data and none a way to protect it from change. The most obvious of the four is also the most broken, and seeing exactly why is the fastest route into the whole subject.

3. ECB, and Why "Just Encrypt Each Block" Fails

The most obvious wrapper is to apply the one-block permutation to each block on its own: $C_i = E_k(P_i)$. This is Electronic Codebook mode, and it is the design every beginner reinvents in an afternoon. It is also broken in a way you can see with your eyes.

The flaw is that ECB is deterministic. It has no initialization vector, no chaining, and no state, so the same plaintext block always encrypts to the same ciphertext block: $P_i = P_j \Rightarrow C_i = C_j$. The plaintext's block-level structure survives encryption intact. Rogaway's survey states it flatly: ECB "leak[s] equality of blocks across both block positions and time" and "does not achieve any generally desirable security goal in its own right" [@rogaway-modes-2011].

flowchart TD P1["Block A: LOVE"] --> C1["Ciphertext 7a3f"] P2["Block B: HATE"] --> C2["Ciphertext 9b2e"] P3["Block C: LOVE"] --> C3["Ciphertext 7a3f"] C1 -.->|"equal blocks leak"| C3

That leak is not a metaphor.The famous "ECB penguin" -- an image of Tux encrypted block-by-block whose outline stays perfectly visible -- is community folklore (the Tux image is by Larry Ewing, 1996) with no research primary. The load-bearing evidence for ECB's failure is the Adobe 2013 breach and the BDJR theorem, not the meme. In 2013, roughly 153 million Adobe records showed it at scale: passwords encrypted with 3DES in ECB, no salt, so identical passwords produced identical ciphertext and the plaintext structure reconstructed itself without 3DES ever being broken [@troyhunt-adobe-2013].

Underneath the meme is a theorem. ECB is not IND-CPA.

The baseline security goal for encryption. An adversary who may request encryptions of any plaintexts it chooses still cannot tell which of two equal-length messages a challenge ciphertext hides. Bellare, Desai, Jokipii, and Rogaway (1997) proved the consequence: any IND-CPA scheme must be randomized or stateful, so a deterministic mode like ECB cannot qualify [@bdjr-1997][@katz-lindell-2020].

The proof is a one-line adversary. Ask the challenger to encrypt a pair of equal blocks $(X, X)$ versus an unequal pair $(X, Y)$ and simply look for a repeated ciphertext block; ECB gives itself away every time [@bdjr-1997]. This is the same reasoning Part 1 develops in general. ECB is also malleable at block granularity: because blocks are independent, an attacker can cut, paste, and reorder them undetected. It fails both questions at once.

Note: ECB is deterministic, so identical plaintext blocks become identical ciphertext blocks and structured or repeated data leaks through untouched -- the ECB penguin, and Adobe's roughly 153 million exposed passwords [@troyhunt-adobe-2013]. Reach for ECB only as a raw one-block building block, never to encrypt a message.

That "never" needs one careful qualifier -- it is easy to overstate.

The rule is *never ECB for messages* -- multi-block, structured, or low-entropy plaintext. The raw single-block permutation is still a legitimate building block: it is the block operation every other mode calls, and it sits at the core of NIST AES Key Wrap and of CMAC/CBC-MAC. NIST's SP 800-131A Revision 3, the initial public draft published on October 21, 2024, formalizes this by moving ECB to "legacy use" and disallowing it for encrypting secret data, with legacy (decrypt-only) use retained -- a demotion, not a claim that ECB has no valid use anywhere [@nist-sp-800-131a-r3].

You can watch the determinism happen. The toy below is not a real cipher, but like ECB it transforms each block with the same deterministic function, so a repeated plaintext block produces a repeated ciphertext block:

{` // A toy deterministic block transform. Not a real cipher -- the point is // only that the same input block always yields the same output block. function toyBlockCipher(block) { return block.split('').reverse().map(function (c) { return String.fromCharCode((c.charCodeAt(0) + 7) % 128); }).join(''); }

// ECB: split into 4-char blocks and transform each one independently. function ecb(message) { var out = []; for (var i = 0; i < message.length; i += 4) { out.push(toyBlockCipher(message.slice(i, i + 4))); } return out; }

var blocks = ecb('LOVEHATELOVE'); // block 1 and block 3 are identical console.log(blocks); console.log('Block 1 equals block 3? ' + (blocks[0] === blocks[2])); // True. The repeated plaintext block leaks as a repeated ciphertext block, // with no key required to notice the pattern. `}

One clarification before moving on.These five are the SP 800-38A confidentiality-only modes, not "all block cipher modes." Disk encryption (XTS-AES, SP 800-38E), authentication (CMAC, SP 800-38B), and authenticated encryption (GCM in SP 800-38D, CCM in SP 800-38C) live in separate NIST publications because they pursue different goals. ECB is the degenerate member of the family, and its failure points straight at the fix.

BDJR's theorem is also the cure. To be IND-CPA, encryption must be randomized or stateful. So add an initialization vector, and make each block's encryption depend on the previous one, so that identical plaintext diverges. That is Cipher Block Chaining -- and the start of a forty-year evolution that improves everything except the one thing that matters.

4. From CBC to CTR, Generation by Generation

Four modes remain, and they line up as a sequence of fixes -- each one repairing the previous mode's limitation, and none of them repairing the missing integrity answer. The field got faster, more flexible, and better specified. It stayed exactly as forgeable as the day it started.

CBC: chain the blocks

CBC seeds the chain with an initialization vector and feeds each plaintext block the previous ciphertext block before encryption: $C_i = E_k(P_i \oplus C_{i-1})$, with $C_0 = \text{IV}$. Decryption runs $P_i = D_k(C_i) \oplus C_{i-1}$. Because every ciphertext block now depends on all plaintext before it, identical plaintext blocks diverge, and ECB's pattern leak is gone. With an unpredictable IV, CBC is provably IND-CPA [@bdjr-1997].

The per-message starting value a mode mixes in so that encrypting the same plaintext twice yields different ciphertext. For CBC and CFB the IV must be *unpredictable* -- indistinguishable from random to an attacker -- not merely fresh, because it is the first value fed into the chain [@nist-sp-800-38a]. Part 2 of this series covers how to generate one.

CBC answered the first question correctly and left the second blank, and even its confidentiality carries three sharp contract edges. This one mode seeded most of the Failure Catalog. It is malleable: a controlled flip in ciphertext block $C_i$ deterministically flips the corresponding bits of plaintext block $P_{i+1}$ while randomizing $P_i$ -- the "flip-and-garble" gadget, an attacker editing a later block without the key [@rogaway-modes-2011].

The three contract edges follow. It needs padding, and a receiver that reveals whether decrypted padding is valid turns that check into a plaintext-recovering oracle. Its IV must be unpredictable, or a chosen-plaintext attacker can distinguish messages. And with a 64-bit block, its ciphertext blocks start colliding after about $2^{32}$ blocks, leaking $P_i \oplus P_j$. Rogaway's performance verdict is blunt: CBC encryption is "inherently serial," and he can "identify no important advantages over CTR mode" [@rogaway-modes-2011].Ciphertext stealing (CBC-CS, standardized in an addendum to SP 800-38A) is the no-expansion variant that avoids padding by borrowing bits from the penultimate block. It is a useful trick, not a new security property -- CBC-CS is still malleable and still needs an unpredictable IV.

CFB: a self-synchronizing stream

CFB turns the block cipher into a stream by encrypting the previous ciphertext to produce a keystream, then XORing it with the plaintext: $C_i = P_i \oplus E_k(C_{i-1})$. The cipher never touches the plaintext directly, so there is no padding, the mode can operate on sub-block segments (one byte or even one bit at a time), and it self-synchronizes after lost or inserted segments -- a genuinely useful property for noisy character-oriented links [@rogaway-modes-2011].

The costs are real. Encryption is still serial, and for a segment size $s \lt n$ the mode makes many more block cipher calls per byte -- Rogaway notes $s = 8$ means "16 times the number of blockcipher calls as CBC," and $s = 1$ means 128 times [@rogaway-modes-2011].Folklore (and even the loose version of this article's own scope) sometimes says CFB needs only a unique IV. The primary source is stricter: SP 800-38A Section 5.3 requires the IV for both CBC and CFB to be unpredictable [@nist-sp-800-38a]. Treat CFB's IV exactly like CBC's.

CFB's malleability is the middle case, not a pure bit-flip. Because $P_i = C_i \oplus E_k(C_{i-1})$, flipping a ciphertext bit flips exactly the aligned plaintext bit in the current block -- but that same altered block is the cipher's input for the next one, so the following block decrypts to garbage. Efail (2018) weaponized precisely this: Damian Poddebniak and co-authors built malleability "gadgets" in CFB (OpenPGP's mode), engineered to absorb the garbled block while keeping the surgical edit, that turned an encrypted email into a plaintext-exfiltration channel with no key recovery and no padding oracle [@efail-2018][@efail-site].

OFB: a pre-computable stream

OFB makes the keystream independent of the message by feeding back the cipher's own output instead of the ciphertext: $O_i = E_k(O_{i-1})$, then $C_i = P_i \oplus O_i$. Because the pad depends only on the key and IV, you can compute it before the plaintext arrives, and a single flipped ciphertext bit corrupts only the corresponding plaintext bit, with no error propagation -- attractive for satellite links and digitized voice [@rogaway-modes-2011].

A number used once: a value that must never repeat under a given key. OFB and CTR need their nonce only to be *unique*, not unpredictable, so a simple counter is a perfectly good nonce [@nist-sp-800-38a]. Reusing one under the same key is catastrophic for every keystream mode, because it reproduces the exact same pad. Part 2 covers how to source these values safely.

That last point is OFB's undoing. If a $(\text{key}, \text{IV})$ pair ever repeats, the pad repeats, and $C \oplus C' = P \oplus P'$ leaks the XOR of two plaintexts with no key -- a two-time pad [@rogaway-modes-2011]. OFB is also serial in both directions, so it cannot use hardware parallelism at all, a strictly worse profile than CTR for the same "stream" benefit. And the original FIPS 81 reduced-feedback variants shortened the keystream cycle dangerously, a hazard SP 800-38A removed by defining OFB with full-block feedback only [@fips-81][@nist-sp-800-38a].

CTR: the parallel stream that wins

CTR keeps OFB's "encrypt something to make a pad" idea but replaces the serial feedback chain with an independent per-block counter: $C_i = P_i \oplus E_k(\text{nonce} ,|, i)$. Because each pad block is a standalone function of its counter, the blocks have no data dependency on one another. CTR is fully parallel on both encryption and decryption, random-access (decrypt block $i$ alone), precomputable, inverse-free, and needs no padding. Rogaway estimates it "encrypting at more than 10 times the speed of CBC" in hardware [@rogaway-modes-2011]. Its contract is the simplest of all: the counter must be unique per key, and unpredictability is explicitly not required [@bdjr-1997][@rogaway-modes-2011].

Counter mode is "the best and most modern way to achieve privacy-only encryption" and "an important building block for authenticated-encryption schemes." -- Phillip Rogaway, 2011

And here is the cliff. CTR is the best answer to the first question, which is exactly what makes its failure the point of the whole story. It is still malleable, and more transparently so than any other mode: $P = C \oplus \text{keystream}$, so flipping any ciphertext bit flips exactly the corresponding plaintext bit, with no key. The "transfer $9" to "transfer $9,000,000" edit from the opening is a single XOR, and the receiver decrypts a perfectly well-formed message. CTR removed every other excuse -- it is fast, parallel, and clean -- so the blank where integrity should be is the only thing left to see.

flowchart TD subgraph CBC["CBC: serial chaining"] cIV["IV"] --> cx1["XOR"] cP1["P1"] --> cx1 cx1 --> cE1["E_k"] --> cC1["C1"] cC1 --> cx2["XOR"] cP2["P2"] --> cx2 cx2 --> cE2["E_k"] --> cC2["C2"] end subgraph CTR["CTR: independent counters"] tK1["E_k(nonce, 1)"] --> tx1["XOR"] tP1["P1"] --> tx1 tx1 --> tC1["C1"] tK2["E_k(nonce, 2)"] --> tx2["XOR"] tP2["P2"] --> tx2 tx2 --> tC2["C2"] end

Lined up as a reference grid, the five modes and their exact contracts look like this:

Mode	Relation	IV / nonce contract	Parallelism	Malleability
ECB	`C_i = E_k(P_i)`	none (the flaw)	encrypt and decrypt parallel	block-level: cut, paste, reorder
CBC	`C_i = E_k(P_i XOR C_{i-1})`	unpredictable IV	encrypt serial, decrypt parallel	flip-and-garble (block-coupled)
CFB	`C_i = P_i XOR E_k(C_{i-1})`	unpredictable IV	encrypt serial, decrypt parallel	surgical bit, next block garbled (middle)
OFB	`C_i = P_i XOR E_k(O_{i-1})`	unique nonce	serial both ways	surgical bitwise
CTR	`C_i = P_i XOR E_k(counter_i)`	unique nonce (not unpredictable)	encrypt and decrypt parallel	surgical bitwise

The IV and nonce contracts are SP 800-38A's; the parallelism and malleability columns follow Rogaway's summary tables [@nist-sp-800-38a][@rogaway-modes-2011].

That last column deserves its own magnification, because "malleable" is not one behavior. It runs from surgical (edit one plaintext bit and touch nothing else), through a middle case (edit one bit, but wreck the neighboring block), to block-coupled (your controlled edit lands a block later):

Mode	Malleability class	What one flipped ciphertext bit does
CTR, OFB	surgical	flips exactly the aligned plaintext bit, with zero collateral
CFB	middle case	flips the aligned bit in the current block, and fully garbles the next block
CBC	block-coupled	garbles the current block, and flips the aligned bit in the next block
ECB	block-level	no sub-block control, but whole blocks can be cut, pasted, and reordered

The distinction is operational, not academic: CTR's surgical malleability is what makes the opening bit-flip a one-line edit, while CFB's "flip here, garble there" is the exact structure Efail's exfiltration gadgets were built around [@rogaway-modes-2011][@efail-2018]. Read as an evolution, the same five tell a story of steady improvement on every axis but one:

Mode	Year	Key idea	Limitation that drove the next step
ECB	1980	encrypt each block independently	deterministic; leaks block equality (not IND-CPA)
CBC	1976 / 1980	chain each block with the previous ciphertext	serial; needs padding; unpredictable IV; 64-bit birthday
CFB	1980	encrypt the previous ciphertext into a keystream	serial; sub-block sizes multiply cipher calls
OFB	1980	encrypt the feedback into a message-independent pad	serial both ways; reuse is a two-time pad
CTR	1979 / 2001	encrypt an independent counter	the best confidentiality mode, yet still no integrity

Note: Not one of the four evolutions from ECB added integrity. CBC, CFB, OFB, and CTR each improved chaining, padding, error behavior, or parallelism. Every one of them left the second question -- can the attacker change it? -- completely blank.

One honest caveat: CFB, OFB, and CTR are not a strict quality ladder. They are three parallel answers to CBC's "turn the block cipher into a stream," standardized together, with CTR the clear winner [@rogaway-modes-2011]. The linear arrow is a teaching device.

Line the four up and the pattern is undeniable. The bug was never "which chaining?" It was the blank where the second answer should be. Naming that blank correctly is the pivot the whole field turned on.

5. Malleability Is the Real Bug

Here is the reframe that organizes the entire subject: confidentiality is not security. A mode that perfectly hides your message while letting an attacker predictably rewrite it has not handed you a weaker guarantee. It has handed you a different one, and mistaking the two is the single most repeated error in applied cryptography.

The property that an attacker can transform a ciphertext into a predictable transformation of the underlying plaintext, without knowing the key or the plaintext. A malleable scheme may be perfectly confidential and still let an attacker edit the message. All five SP 800-38A modes are malleable.

Key idea: Every one of the five modes answers only confidentiality. The missing integrity answer is malleability, and malleability is the real bug. The fix is authenticated encryption -- not a faster or cleverer confidentiality mode.

This is a provable statement, not a mood. A confidentiality-only mode is not IND-CCA2 and not non-malleable; IND-CPA says nothing about an active attacker who edits ciphertext in transit [@bdjr-1997].

The mechanism differs per mode, and that difference is your diagnostic. In the pure keystream modes (CTR and OFB) the relation is $P = C \oplus \text{keystream}$, so flipping ciphertext bit $i$ flips plaintext bit $i$ exactly, with no collateral. CFB is the middle case: the flip lands surgically in the current block but garbles the next one, because CFB feeds each ciphertext block back through the cipher. In CBC the coupling runs the other way -- a flip in $C_i$ predictably edits $P_{i+1}$ while randomizing $P_i$. Part 1 develops why this is a failure of the goal, not the construction.

The stronger targets a confidentiality-only mode provably fails. IND-CCA2 (indistinguishability under adaptive chosen-ciphertext attack) hands the adversary a decryption oracle for any ciphertext but the challenge; non-malleability forbids turning one ciphertext into a predictably related one. Because all five SP 800-38A modes are malleable, none is IND-CCA2. Part 1 of this series formalizes both goals -- here they are exactly what a MAC restores.

You can run the attack from the opening. The demo below encrypts a payment instruction with a toy keystream, then, knowing only the message format, rewrites the amount by XORing a delta into the ciphertext. No key is ever touched:

{` // Toy CTR: P = C XOR keystream. Editing C edits P, with no key. NOT real crypto. function xorBytes(a, b) { return a.map(function (x, i) { return x ^ b[i]; }); } function toBytes(s) { return Array.from(s).map(function (c) { return c.charCodeAt(0); }); } function toStr(b) { return b.map(function (x) { return String.fromCharCode(x); }).join(''); }

var plaintext = 'amount:0000009'; // the honest instruction var keystream = toBytes('SECRETPADSECRET').slice(0, plaintext.length);

// Sender encrypts. The attacker sees only C -- never the key, never the keystream. var C = xorBytes(toBytes(plaintext), keystream);

// The attacker knows the fixed message FORMAT and wants this instead: var target = 'amount:9000000'; // same length, this is the "9 -> 9,000,000" edit var delta = xorBytes(toBytes(plaintext), toBytes(target)); // computable from the format alone

// He XORs the delta straight into the ciphertext. var forged = xorBytes(C, delta);

// The receiver decrypts with the real keystream and sees the forgery. console.log('Receiver reads: ' + toStr(xorBytes(forged, keystream))); // amount:9000000 console.log('Keys or keystream used by the attacker: none.'); `}

The same edit, drawn as it happens on the wire:

sequenceDiagram participant S as Sender participant A as Attacker participant R as Receiver S->>A: Ciphertext of a nine-dollar transfer Note over A: Cannot read it, AES is unbroken Note over A: But P is C XOR keystream, so flipping ciphertext bit i flips plaintext bit i A->>A: XOR a chosen delta into the amount bytes A->>R: Modified ciphertext Note over R: Decrypts to a nine-million transfer, perfectly well-formed R->>R: Accepts the forgery as authentic Confidentiality without integrity is not weaker encryption. It is a different, largely illusory guarantee.

Now turn the lens on the historical record. Every famous break of these modes is one of two diagnoses -- a missing integrity answer, or a violated IV/nonce contract:

Break	Year	Mode	Root cause	Lesson
Adobe [@troyhunt-adobe-2013]	2013	ECB	confidentiality answered wrongly (determinism)	never ECB for messages
Padding oracle, Vaudenay [@vaudenay-2002]	2002	CBC	no integrity plus a distinguishable padding check	verify before decrypting
BEAST [@bard-2004][@cve-2011-3389]	2011	CBC	violated IV contract (predictable IV)	IVs must be unpredictable
Lucky Thirteen [@lucky-thirteen-2013]	2013	CBC	wrong composition order plus a timing leak	Encrypt-then-MAC, constant time
POODLE [@poodle-2014][@cve-2014-3566]	2014	CBC (SSL 3.0)	padding oracle after a downgrade	retire the mode and the fallback
Sweet32 [@sweet32-2016][@cve-2016-2183]	2016	CBC (64-bit)	block-size birthday bound	no 64-bit ciphers for bulk
Efail [@efail-2018]	2018	CBC / CFB	missing integrity (malleability gadget)	authenticate the ciphertext
Truncation, Smyth-Pironti [@smyth-pironti-2013]	2013	TLS record (any mode)	missing integrity of length and framing (omission)	authenticate the end, not just the bytes
GCM nonce reuse [@joux-2006][@nonce-disrespecting-2016]	2016	CTR / GCM	violated nonce contract	never repeat a (key, nonce)

Most of these breaks edit or leak bytes, but the subtlest one deletes them. Ben Smyth and Alfredo Pironti showed at WOOT 2013 that silently truncating a TLS stream -- cutting it short at an attacker-chosen point -- changes the meaning a web application infers from a "complete" response, because the record layer authenticated the bytes it carried but never the fact that the message had ended [@smyth-pironti-2013]. That is an integrity failure of omission, and it is why the fix in Section 10 authenticates length and end-of-stream, not just content. Most of the rest are TLS history, which the SChannel post tells from the deployment side.Precision on GCM nonce reuse: one repeated $(\text{key}, \text{nonce})$ immediately leaks $P_1 \oplus P_2$, but uniquely recovering the GHASH subkey $H$ generally needs two or more collisions. Never say "one reuse leaks $H$" [@joux-2006].The routinely mis-cited CVE-2016-0270 actually names IBM Domino, not OpenSSL, and NVD warns it "has been incorrectly used for GCM nonce reuse issues in other products." The deployed GCM-nonce forgery is the Nonce-Disrespecting Adversaries paper, whose byline is exactly five authors: Boeck, Zauner, Devlin, Somorovsky, and Jovanovic [@cve-2016-0270][@nonce-disrespecting-2016].

Note: A bare confidentiality mode lets an attacker edit your plaintext undetected -- bit-for-bit in CTR and OFB, a surgical bit plus a garbled next block in CFB, and block-coupled in CBC. Use an AEAD, or Encrypt-then-MAC and verify the tag before you decrypt a single byte.

The fix is to add the missing answer, and the order in which you add it turns out to matter. Bellare and Namprempre (2000) and Krawczyk (2001) proved that Encrypt-then-MAC -- encrypt, then MAC the ciphertext, and verify the tag before decrypting -- generically yields both IND-CPA and INT-CTXT, a scheme that is confidential and unforgeable, while MAC-then-encrypt and encrypt-and-MAC are fragile [@bellare-namprempre-2000][@krawczyk-2001].

A keyed tag that proves a message was not altered and came from someone holding the key. Anyone with the key can compute the tag over a message; without it, forging a valid tag is infeasible. HMAC, CMAC, and CBC-MAC are common constructions. A MAC supplies the integrity answer a confidentiality mode leaves blank. SSL and early TLS shipped MAC-then-encrypt. The theory said Encrypt-then-MAC was the safe generic choice. That debate was not settled by proof alone -- it was settled by a decade of breaks (BEAST, Lucky Thirteen, POODLE) that all exploited the MAC-then-encrypt-plus-CBC-padding surface, until TLS 1.3 removed CBC outright and mandated authenticated encryption [@krawczyk-2001][@rfc-8446-tls13].

Better still, fuse the two answers into one primitive.

A single primitive that provides confidentiality *and* integrity at once, and can also authenticate unencrypted "associated data" such as headers. It answers both questions in one object, so a modified ciphertext is rejected before any plaintext is released.

The punchline binds this whole article together: the dominant AES AEADs are literally these modes plus a MAC. GCM equals CTR plus GHASH, a polynomial hash over $GF(2^{128})$ [@mcgrew-viega-2004][@nist-sp-800-38d]. CCM equals CTR plus CBC-MAC [@rfc-3610-ccm][@nist-sp-800-38c]. The 1979 counter idea and the 1976 chaining idea, welded into a primitive that finally answers both questions -- the SMB 3.1.1 post shows GCM and CCM running in a real protocol.

flowchart TD P["Plaintext"] --> CTR["CTR encryption"] CTR --> C["Ciphertext"] C --> M["MAC over ciphertext and associated data"] M --> T["Authentication tag"] C --> W["Transmit ciphertext plus tag"] T --> W W --> V{"Tag valid?"} V -->|"no"| X["Reject, decrypt nothing"] V -->|"yes"| D["Decrypt and release plaintext"]

One boundary to keep honest: not every modern AEAD is built from these modes. ChaCha20-Poly1305 (a stream cipher plus Poly1305) and Ascon (a sponge permutation) are first-class AEADs that are deliberately not SP 800-38A constructions [@rfc-8439-chacha20][@nist-sp-800-232]. The lineage claim is bounded to the AES AEADs.

With integrity finally bolted on, every entry in the catalog retroactively dies -- a modified ciphertext fails the tag before a byte is decrypted. So the field declared victory and shipped AEAD everywhere. Then it discovered that AEAD did not repeal the IV/nonce contract. It sharpened it -- which is exactly where the state of the art picks up.

6. The Field Is Retiring Confidentiality-Only Modes

The modern answer to "which block cipher mode should I use?" is no bare confidentiality mode at all. It is a choice of AEAD, and between 2024 and 2026 that answer stopped being folklore and became written policy. The tell is what the standards bodies did not do. Faced with four decades of breaks, nobody proposed a sixth confidentiality mode. Every document below reaches instead for authentication.

Start with the audit. NIST IR 8459, published in September 2024 by Nicky Mouha and Morris Dworkin, is the first formal review of the entire SP 800-38 series, and it reads less like a specification than a post-mortem: it works through the family mode by mode, documenting why each keeps failing, and its recommendations point at authenticated encryption rather than a patched mode -- down to disallowing ECB for the very job it keeps losing at, encrypting secrets [@nist-ir-8459]. An audit whose answer to "which new mode?" is "stop adding modes" is this whole section in miniature.

The policy machinery had already started turning. In April 2023 NIST's Crypto Publication Review Board published its decision to revise SP 800-38A itself, with goals that read like a confession: to "limit the approval of the Electronic Codebook (ECB) mode," to "provide guidance on the importance of incorporating authentication, where feasible," to fold in "three variations of ciphertext stealing for Cipher Block Chaining mode," and -- once a stronger technique exists -- to "consider deprecating the modes in SP 800-38A" [@csrc-sp38a-revision-2023]. The document that defines the five modes is contemplating its own retirement, and names authenticated encryption as the successor it is waiting on.

SP 800-131A Revision 3 supplies the compliance lever. Its initial public draft of October 21, 2024 disallows ECB for encrypting secret data and relegates it to legacy (decrypt-only) use; the draft's own phrase is "the retirement of ECB as a confidentiality mode of operation" [@nist-sp-800-131a-r3]. For a FIPS-bound product that is an effective-on-finalization change, not a suggestion.

Where the field is heading is just as clear from what it standardized. Ascon, finalized as NIST SP 800-232 in August 2025, is the new AEAD for the constrained, low-power class for which earlier standards specified AES-CCM -- and it is a sponge permutation, pointedly not an SP 800-38A block cipher mode [@nist-sp-800-232]. "Migrate to AEAD" does not mean "migrate to a mode." And for the one contract even AEADs still impose, AES-GCM-SIV (RFC 8452, 2019) is the standardized hedge: a nonce-misuse-resistant scheme that degrades gracefully instead of catastrophically when a nonce repeats [@rfc-8452-gcm-siv].

An AEAD that stays secure even when a nonce is accidentally reused, leaking at most whether two identical messages were sent under the same nonce, instead of collapsing into a two-time pad and forgery. AES-GCM-SIV reaches this by deriving its internal counter from a MAC of the whole message, so a repeat is a mild, bounded leak rather than a catastrophe [@rfc-8452-gcm-siv][@gcm-siv-spec-2017]. AES-GCM-SIV is engineered to be "nonce misuse resistant -- that is, [it does] not fail catastrophically if a nonce is repeated." -- RFC 8452

Document	What it does	Status
NIST IR 8459 [@nist-ir-8459]	audits the whole SP 800-38 series; steers ECB and secrets toward AEAD	published, Sept 2024
Decision to revise SP 800-38A [@csrc-sp38a-revision-2023]	limit ECB, add CBC ciphertext stealing, urge authentication, weigh deprecation	published, Apr 2023
SP 800-131A Rev. 3 [@nist-sp-800-131a-r3]	moves ECB to legacy (decrypt-only) use; disallowed for encrypting secrets on publication	draft (Oct 21, 2024 IPD)
Ascon (SP 800-232) [@nist-sp-800-232]	a permutation AEAD for constrained devices, deliberately not a 38A mode	final, Aug 2025
AES-GCM-SIV (RFC 8452) [@rfc-8452-gcm-siv]	a nonce-misuse-resistant AEAD hedge	published, 2019

The migration is credible now, rather than merely aspirational, because the substrate already moved. TLS 1.3 (RFC 8446, 2018) removed every CBC-mode cipher suite and makes AES-GCM its mandatory-to-implement AEAD [@rfc-8446-tls13]; QUIC protects every packet with an AEAD, binding the packet number directly into the AEAD nonce, with no unauthenticated-confidentiality option at all [@rfc-9001-quic-tls].

The performance objection that once favored CBC also evaporated: with AES-NI and the carry-less multiply instruction PCLMULQDQ, AES-GCM fell from roughly 3.7 cycles per byte in optimized software toward about 1, so the fast path and the safe path are now the same path [@krovetz-rogaway-ae-2011][@gcm-siv-spec-2017]. The 2024-2026 standards are simply retiring the confidentiality-only modes to match a deployment reality that migrated years earlier.

Key idea: The modern "which mode?" question is really "which AEAD?" The five SP 800-38A confidentiality-only modes now survive as internals of authenticated encryption and as legacy interoperability options -- not as something you deploy on purpose.

Not every SP 800-38 sibling is a confidentiality mode. SP 800-38G defines FF1 and FF3, *format-preserving* encryption that turns a 16-digit card number into another 16-digit string so it still fits a legacy database column [@nist-sp-800-38g]. Different goal, and it came with its own break: Durak and Vaudenay gave a practical total recovery of FF3 over small domains, a slide attack exploiting the design's "bad domain separation" in roughly $O(N^{11/6})$ chosen plaintexts [@durak-vaudenay-2017]. NIST responded with FF3-1, shrinking the tweak from 64 to 56 bits and raising the minimum domain to one million [@nist-sp-800-38g-r1]. Signposted here, not surveyed -- it is not one of the five.

Note: Reach for a vetted AEAD -- AES-GCM or ChaCha20-Poly1305 -- give it a unique nonce per key, cap your messages under the nonce limit, and drop to a raw confidentiality mode only as an Encrypt-then-MAC building block when an AEAD is genuinely unavailable.

The cross-references write themselves: the CBC-to-GCM migration is the story the SChannel post tells for Windows TLS, and GCM and CCM running in a shipping protocol is what the SMB 3.1.1 post shows. So the strategic direction is settled: move to AEAD. But "AEAD" is not one thing. The moment you have to ship, the question sharpens from "which mode?" to "which AEAD, with which parameters, for which platform?" -- and that has a real, defensible answer.

7. When You Must Pick a Mode, and Which AEAD

Two comparisons matter in practice. The first is the intra-family one folklore gets wrong. The second is the one you actually face when you ship.

CBC versus CTR: a choice that changes nothing that matters

Both are confidentiality-only, both are malleable, and both are still everywhere. On the merits CTR is superior: fully parallel on encryption and decryption, random-access, and governed by the simplest contract (a unique nonce). CBC survives on forty years of deployment inertia, not on technical advantage -- Rogaway, having surveyed all five modes, reports "no important advantages over CTR mode" for CBC [@rogaway-modes-2011].

But here is the point most tuning guides miss: swapping CBC for CTR fixes nothing that matters, because neither answers the second question. You trade a serial mode with padding for a parallel mode without it, and you keep every bit of the malleability. If your reason for the swap is security, you are solving the wrong problem.

Which AEAD

This is the comparison with real stakes, and every option is a defensible answer to a different constraint. AES-GCM is the throughput default on modern CPUs, hardware-accelerated by AES-NI and CLMUL, and brittle exactly where humans err -- a single reused nonce is catastrophic [@nist-sp-800-38d]. ChaCha20-Poly1305 is the software default: constant-time by construction, with no AES hardware and no cache-timing hazard [@rfc-8439-chacha20]. AES-CCM is CTR plus CBC-MAC, two-pass and small-footprint [@rfc-3610-ccm][@nist-sp-800-38c]; those documents define CCM, and its compact profile is why the IEEE wireless standards adopt it -- WPA2 (802.11i) [@krovetz-rogaway-ae-2011] and IEEE 802.15.4 low-power wireless [@rfc-4944][@rfc-9031] both build their link-layer security on it. AES-GCM-SIV is the nonce-misuse-resistant hedge [@rfc-8452-gcm-siv]. Ascon is the lightweight standard for microcontrollers [@nist-sp-800-232].

AEAD	Built from	Passes	Constant-time	Nonce-reuse penalty	Best fit
AES-GCM [@nist-sp-800-38d]	CTR + GHASH	1, online	needs AES-NI, CLMUL	catastrophic (forgery)	server bulk, TLS
ChaCha20-Poly1305 [@rfc-8439-chacha20]	stream + Poly1305	1, online	by construction (software)	catastrophic	mobile, no AES hardware
AES-CCM [@rfc-3610-ccm]	CTR + CBC-MAC	2, not online	needs AES-NI	catastrophic	WPA2, IoT, small code
AES-GCM-SIV [@rfc-8452-gcm-siv]	POLYVAL-SIV + CTR	2, not online	needs AES-NI, CLMUL	graceful (leak equality)	nonce-uncertain systems
Ascon [@nist-sp-800-232]	sponge permutation	1 (duplex)	easy to protect	catastrophic	microcontrollers, IoT

The performance folklore is worth correcting too. The cleanest apples-to-apples software measurement, Krovetz and Rogaway at FSE 2011 on an Intel i5 "Clarkdale," found CCM near 4.2 cycles per byte, GCM near 3.7, OCB near 1.5, and raw CTR near 1.3 [@krovetz-rogaway-ae-2011]. Read that as an ordering under fixed effort, not a modern absolute: with mature AES-NI and CLMUL, AES-GCM reaches roughly 1 cycle per byte on current x86 [@gcm-siv-spec-2017]. The durable lesson is that hardware, not algorithm choice, moved GCM from 3.7 to 1 -- which is the whole reason CTR-based AEADs won.

The two non-38A AEADs from Section 5, ChaCha20-Poly1305 and Ascon, sit within a broader research lineage -- OCB, EAX, SIV/AES-SIV, IACBC/IAPM, McOE -- that is real but out of scope here; OCB is the elegant one-pass design that patents kept out of deployment for years [@rfc-7253-ocb].

Every column wins on some axis and loses on another; none is unconditionally best. And the reasons why no single scheme dominates are not engineering accidents. They are theorems. To use any of these correctly, you have to know the walls they are all pressed against.

8. You Cannot Get Integrity From a Confidentiality Mode

The two-question frame is not merely good advice. It is a theorem, and it draws a hard line no amount of clever engineering crosses.

Start with the central impossibility. IND-CPA does not imply IND-CCA2 or non-malleability; BDJR proved ECB is not even IND-CPA and that CBC and CTR are IND-CPA with proper IVs and nonces, but IND-CPA says nothing about an active attacker editing ciphertext [@bdjr-1997]. Bellare and Namprempre sharpened the target, separating INT-PTXT from INT-CTXT and proving that only Encrypt-then-MAC generically delivers IND-CPA plus INT-CTXT [@bellare-namprempre-2000][@krawczyk-2001].

The consequence is a lower bound, not a tip: you cannot patch integrity into a bare CTR, CBC, CFB, or OFB mode, because malleability is a property of the confidentiality goal, not a bug in any construction. This is the reasoning Part 1 sets up in full.

Key idea: "Confidentiality does not imply integrity" is a theorem, not advice. IND-CPA does not imply IND-CCA2 or non-malleability, so you cannot patch integrity into a bare CTR, CBC, CFB, or OFB mode. It is a property of the goal, not a bug in the construction.

The second wall is the block size.

The threshold at which collisions among random $n$-bit values become likely: around $2^{n/2}$ of them. For a block cipher it means ciphertext blocks start repeating -- and leaking $P_i \oplus P_j$ -- after roughly $2^{n/2}$ blocks, regardless of key length. This is the ceiling behind Sweet32 and the GCM nonce cap.

Ciphertext-collision leakage grows like $q^2 / 2^n$ in the number of blocks $q$, so security degrades at about $q \approx 2^{n/2}$ blocks: roughly $2^{32}$ blocks (about 32 GiB) for a 64-bit cipher, which is the Sweet32 ceiling, and $2^{64}$ blocks for AES [@bdjr-1997][@sweet32-2016]. A provable ceiling, independent of key size -- doubling the key does not move it.

GCM inherits its own two ceilings, and conflating them is a common error. Per SP 800-38D, a single message is capped at $2^{39} - 256$ bits (about 64 GiB), and, under random 96-bit nonces, the number of invocations per key must stay below about $2^{32}$ to keep the nonce-collision probability negligible [@nist-sp-800-38d]. One is a length limit; the other is a count limit. They are different numbers that both bite.

The last wall is the sharpest, because no computational assumption stands behind it. Reusing a $(\text{key}, \text{nonce})$ in any keystream mode leaks $C_1 \oplus C_2 = P_1 \oplus P_2$ -- a two-time pad. You can watch it recover a plaintext with nothing but XOR:

{` // Reusing a (key, nonce) reproduces the SAME keystream. That is a two-time pad. function xorBytes(a, b) { return a.map(function (x, i) { return x ^ b[i]; }); } function toBytes(s) { return Array.from(s).map(function (c) { return c.charCodeAt(0); }); } function toStr(b) { return b.map(function (x) { return String.fromCharCode(x); }).join(''); }

var p1 = 'attack at dawn'; var p2 = 'defend the fort'; var n = Math.min(p1.length, p2.length); var ks = toBytes('REUSEDPADREUSEDPAD').slice(0, n); // the SAME pad used twice -- the bug

var c1 = xorBytes(toBytes(p1).slice(0, n), ks); var c2 = xorBytes(toBytes(p2).slice(0, n), ks);

// The attacker never has the key. He XORs the two ciphertexts; the pad cancels: var leaked = xorBytes(c1, c2); // equals p1 XOR p2

// With a crib -- a good guess at p1 -- he recovers p2 outright: var crib = toBytes('attack at dawn').slice(0, n); console.log('Recovered from a crib: ' + toStr(xorBytes(leaked, crib))); // defend the for `}

Note: Reusing a $(\text{key}, \text{nonce})$ leaks $P_1 \oplus P_2$ with no computational assumption to fall back on -- no key length saves you. In GCM it is worse: repeated nonces also expose the GHASH subkey $H$ -- uniquely, once two or more collisions accumulate -- enabling universal forgery [@joux-2006][@nist-sp-800-38d].

The core science, then, is closed. "Confidentiality does not imply integrity" is settled, reuse is an information-theoretic floor, and the block-size wall is provable. If the theory is finished, what is left to work on? More than you would guess -- and it is where the modes still bite.

9. Where Modes Still Bite

The confidentiality-versus-integrity fight is won. The live frontier is one level up: not "is it confidential?" but "how resilient is the authenticated scheme when humans and hardware misbehave?" Four problems are genuinely open, and one popular worry is not a problem at all.

Make nonce-misuse-resistance the default, not the hedge. AES-GCM fails catastrophically on nonce reuse, yet reuse -- from stateless senders, VM clones, restarted counters -- is among the most common real misuses [@nist-sp-800-38d]. AES-GCM-SIV delivers graceful degradation at roughly 1 cycle per byte and up to $2^{50}$ messages per key, "well suited for real world applications that need a nonce-misuse resistant Authenticated Encryption scheme" [@gcm-siv-spec-2017].

But it is two-pass and offline, and it remains opt-in. The open problem is an AEAD that is online, single-pass, parallel, roughly 1 cycle per byte, and misuse-resistant at once -- and, harder, getting TLS and KMS libraries to make it the default. NIST IR 8459 flags nonce management across the whole SP 800-38 series as a first-order concern [@nist-ir-8459].

The property that binds a ciphertext to the single key and context that produced it, so it cannot be made to decrypt validly under a second key. Standard AEAD security says nothing about it, which is why AES-GCM and ChaCha20-Poly1305 lack it -- and why a ciphertext can be crafted to open to two different valid plaintexts under two different keys.

Key commitment and robustness. AES-GCM and ChaCha20-Poly1305 are not key-committing: a single ciphertext can be built to decrypt to valid plaintexts under two different keys [@key-commitment-2022]. Real systems assume otherwise, so this breaks password-based encryption, message franking, and envelope schemes.

Partitioning-oracle attacks turned that gap into practical password recovery against Shadowsocks proxies; the same study only surveyed protocols such as OPAQUE as potentially vulnerable rather than breaking them [@partitioning-oracles-2021]. The "invisible salamanders" attack built AES-GCM ciphertexts that decrypt to valid files under two keys, defeating message franking [@fast-franking-2018], a technique later generalized across file formats [@key-commitment-2022]. A genuine lower bound -- compactly committing AE is provably impossible at AES-GCM's exact performance profile [@fast-franking-2018] -- meets a cheap upper bound -- committing GCM and GCM-SIV variants at no ciphertext expansion [@committing-ae-2022]. The bounds nearly meet, yet the deployed default still sits on the wrong side.

Constant-time implementation. CBC-decrypt-then-MAC timing gave us Lucky Thirteen, and table-based AES and GHASH leak through cache [@lucky-thirteen-2013]. This is effectively solved on hardware with AES-NI and CLMUL, and ChaCha20-Poly1305 is constant-time by design [@rfc-8439-chacha20]. It stays a live hazard on microcontrollers and throughout the legacy CBC base.

The forty-year migration. A vast deployed base still runs CBC and 64-bit block ciphers, keeping Sweet32 and padding oracles alive. TLS 1.3 removed CBC-mode cipher suites and mandates AEAD [@rfc-8446-tls13], and IR 8459 audits the whole series [@nist-ir-8459], but embedded firmware, file-format crypto, database encryption, and private protocols lag by years. This is an engineering and logistics problem, not a mathematical one -- and it is the one that keeps the Failure Catalog growing.

A widespread belief holds that quantum computers break block cipher modes. To first order they do not: Grover's algorithm gives only a quadratic speedup on key search, so doubling the key (AES-256) restores the margin. The post-quantum churn is in key exchange and signatures, not in symmetric modes or AEADs [@nist-ir-8105].

None of these is a hole in the confidentiality-versus-integrity theory. All are the gap between the ideal AEAD and the one you can install today -- which is exactly the gap a practitioner has to bridge. So here are the rules that bridge it.

10. Use X With These Params In Case Y

Everything so far collapses into one rule and a short decision tree you can apply without re-deriving a theorem. The rule: use a vetted AEAD, not a raw confidentiality mode [@ferguson-schneier-kohno-2010].

The decision guide, in priority order:

Default: AES-GCM with a 96-bit nonce, unique per key -- prefer a deterministic counter -- and a hard cap of fewer than $2^{32}$ messages per key [@nist-sp-800-38d].
Cannot guarantee unique nonces: AES-GCM-SIV [@rfc-8452-gcm-siv], or XChaCha20-Poly1305, which widens the RFC 8439 ChaCha20-Poly1305 construction to a 192-bit random nonce [@rfc-8439-chacha20].The 192-bit-nonce XChaCha20 variant is specified in the IRTF draft draft-irtf-cfrg-xchacha, not in RFC 8439, which standardizes only the 96-bit ChaCha20-Poly1305 [@rfc-8439-chacha20]. The wider nonce is exactly what lets you pick nonces at random without tracking a counter.
No fast AES hardware, or you need constant-time software: ChaCha20-Poly1305 [@rfc-8439-chacha20].
Constrained or IoT, small code budget: Ascon-AEAD128 [@nist-sp-800-232] or AES-CCM [@rfc-3610-ccm].
Need key or context commitment (password-based encryption, franking, envelope, rotation): a committing AEAD [@committing-ae-2022].
Must drop to a raw mode (interoperability or a FIPS boundary): CTR plus Encrypt-then-MAC (CMAC or HMAC) with a unique nonce, or CBC only with a fresh unpredictable IV plus Encrypt-then-MAC plus constant-time padding [@nist-sp-800-38a][@bellare-namprempre-2000].
Streaming or large objects: do not ship one monolithic AEAD blob you cannot buffer. Split the stream into records, give each a unique per-chunk nonce, and authenticate a sequence number plus an explicit end-of-stream marker, so a dropped, reordered, or truncated record is caught rather than silently accepted. This is the record-protocol pattern DTLS 1.3 uses -- rejecting duplicates through "a sliding receive window" -- and that QUIC uses by binding each packet number into its AEAD nonce; together they close truncation and replay, the two integrity gaps a bare mode cannot see [@smyth-pironti-2013][@rfc-9147-dtls13][@rfc-9001-quic-tls].
Never: ECB for messages, a 64-bit block cipher for bulk data, a reused nonce, or "encryption" with no integrity tag.

flowchart TD Start["Need to encrypt a message"] --> Q1{"Is a vetted AEAD available?"} Q1 -->|"no"| Raw["CTR or CBC plus Encrypt-then-MAC, verify tag first"] Q1 -->|"yes"| Q2{"Can you guarantee unique nonces?"} Q2 -->|"no"| NMR["AES-GCM-SIV or XChaCha20-Poly1305 (192-bit nonce)"] Q2 -->|"yes"| Q3{"Fast AES hardware present?"} Q3 -->|"no"| Chacha["ChaCha20-Poly1305"] Q3 -->|"yes"| Q4{"Constrained device?"} Q4 -->|"yes"| Small["Ascon-AEAD128 or AES-CCM"] Q4 -->|"no"| GCM["AES-GCM, 96-bit nonce, fewer than 2^32 messages per key"]

When you do touch a raw mode, the contract is the whole game. Part 2 covers how to generate these values; this table says what each mode requires:

Mode	Requirement	Consequence of violation
ECB	none (and that is the flaw)	determinism leaks block equality
CBC	unpredictable and unique IV	a predictable IV enables BEAST
CFB	unpredictable and unique IV	a predictable IV enables chosen-plaintext distinguishing
OFB	unique nonce	reuse is a two-time pad
CTR	unique nonce (unpredictability not required)	reuse is a two-time pad

Those requirements come straight from SP 800-38A [@nist-sp-800-38a]; the raw bytes that satisfy them come from a CSPRNG, which the Windows CSPRNG post covers, and the real API calls that wire AES-CBC and AES-GCM together live in the CNG post. Finally, every common misuse maps one-to-one to a named break and its fix:

Misuse	Named break	Fix
ECB for structured data	Adobe 2013 [@troyhunt-adobe-2013]	AEAD over AES
static or predictable IV	BEAST [@cve-2011-3389]	fresh unpredictable IV, or an AEAD
reused GCM nonce	Nonce-Disrespecting Adversaries [@nonce-disrespecting-2016]	counter nonces, or GCM-SIV / XChaCha
MAC-then-encrypt or encrypt-and-MAC	Lucky Thirteen [@lucky-thirteen-2013]	Encrypt-then-MAC, verify before decrypt
no integrity at all	Efail [@efail-2018]	an AEAD, or Encrypt-then-MAC
64-bit block cipher for bulk	Sweet32 [@sweet32-2016]	a 128-bit-block AEAD
truncation with no length integrity	Truncation, Smyth-Pironti [@smyth-pironti-2013]	authenticate length and end-of-stream

Run `openssl s_client -connect example.com:443 -tls1_3` and read the `Cipher` line: a modern server reports an AEAD such as `TLS_AES_128_GCM_SHA256` or `TLS_CHACHA20_POLY1305_SHA256`. If you instead see a suite with `CBC` in the name, you are looking at a legacy, malleable-mode configuration that belongs on the migration list.

Note: Read every mode as a building block with an exact IV/nonce contract, and read every break as a missing integrity answer or a violated contract. Default to an AEAD; touch a raw mode only under Encrypt-then-MAC discipline, and only when an AEAD is off the table.

Notice that every rule is the same rule wearing different clothes: pick the primitive that answers both questions, and honor its IV/nonce contract. The folklore that gets this wrong is dense enough to deserve its own section.

11. Misconceptions, Named and Corrected

Seven half-truths cause real incidents. Each dissolves under the same two-question lens.

No. All five SP 800-38A modes are malleable, so an attacker who cannot read your ciphertext can still predictably edit the plaintext -- bit-for-bit in the additive keystream modes CTR and OFB, block-coupled in CBC, and a mix of the two in CFB. Confidentiality and integrity are different guarantees; you need a MAC or an AEAD to get the second one, and encryption alone does not provide it. Only as a building block, never as a message-encryption mode. The raw single-block permutation is legitimate inside key wrap and CMAC or CBC-MAC. But ECB is deterministic, so the moment your data has any structure or repetition it leaks block equality -- which is why NIST is moving ECB to legacy use [@nist-sp-800-131a-r3]. The rule is "never ECB for messages," not "ECB has no use anywhere." No. A random IV fixes ECB's determinism, but it adds no integrity -- the mode is still malleable. And the requirement is not uniform: CBC and CFB need an *unpredictable* IV, while CTR and OFB need only a *unique* nonce [@nist-sp-800-38a]. Getting that distinction wrong is exactly what BEAST exploited. No. Under random 96-bit nonces you must stay below roughly $2^{32}$ invocations per key to keep the nonce-collision probability negligible [@nist-sp-800-38d]. Past that, a repeat becomes likely, and a repeated GCM nonce fails catastrophically. If you cannot count, use AES-GCM-SIV or XChaCha20-Poly1305 instead. That fixes nothing that matters. Both are confidentiality-only and both are malleable; swapping one for the other trades performance characteristics, not security [@rogaway-modes-2011]. The fix is an AEAD, not a different malleable mode. Not under nonce reuse. A single repeated $(\text{key}, \text{nonce})$ leaks $P_1 \oplus P_2$, and with two or more collisions it recovers the GHASH subkey $H$, enabling universal forgery -- Joux's "forbidden attack," which was later found live on real TLS servers [@joux-2006][@nonce-disrespecting-2016]. GCM is only as strong as its nonce discipline. Order matters. MAC-then-encrypt and encrypt-and-MAC are fragile and produced Lucky Thirteen and the padding-oracle family [@lucky-thirteen-2013]. The proven-safe generic composition is Encrypt-then-MAC: authenticate the ciphertext and verify the tag *before* you decrypt [@bellare-namprempre-2000].

Every one dissolves into the same sentence -- which is where this started, and where it ends.

Two Questions, Forty Years

Return to the opening. A ciphertext AES kept perfectly secret, rewritten in transit by an attacker who never read a byte of it, and accepted as authentic -- because the mode answered only the first of two questions. That was not an exotic failure. It was the ordinary shape of every break in this article.

Run the catalog back through the lens and the pattern is total. Adobe [@troyhunt-adobe-2013], Vaudenay's padding oracle [@vaudenay-2002], BEAST [@cve-2011-3389], Lucky Thirteen [@lucky-thirteen-2013], POODLE [@cve-2014-3566], Sweet32 [@cve-2016-2183], Efail [@efail-2018], and GCM nonce reuse [@nonce-disrespecting-2016]: in every case, AES or DES did exactly what it promised, and the variable was always which question the design forgot or which IV/nonce contract it violated. Not one of these was a cipher break.

Read that way, the 2024-2026 state of the art is a single move. The field stopped iterating confidentiality modes and standardized the second answer. Authenticated encryption is the destination -- and its dominant AES instances, GCM and CCM, are literally these very modes plus a MAC, while ChaCha20-Poly1305 and Ascon supply a parallel lineage that is not [@nist-ir-8459][@nist-sp-800-232]. The frontier moved with it: nonce-misuse resistance and key commitment are the properties the deployed defaults still lack.

The payoff of the field guide is the same as its premise. Master the five not as interchangeable dropdown options but as building blocks with exact contracts, and every break -- past or future -- becomes readable on sight. You do not need to memorize the next CVE. You need one test, and you already have it: which question did this mode answer, and was its IV/nonce contract honored?

That lens outlives every mode, every cipher, and every standard revision. Which is why this is Part 5 of a field guide to protocol design, not a chapter on five diagrams.

They Read Your Plaintext Without Breaking Your Cipher: A Field Guide to Padding Oracles

noreply@paragmali.com (Parag Mali) — Wed, 08 Jul 2026 20:09:31 GMT

A padding oracle lets an attacker read your plaintext without ever touching your key -- and it is not a flaw in AES, in CBC, or even in PKCS#7. It is what you get whenever a receiver reveals *whether an attacker-chosen ciphertext decrypted to well-formed plaintext* before it has proven that ciphertext authentic. That one leaked bit ("was the padding valid?"), plus CBC's malleability, recovers plaintext one byte at a time -- about 128 guesses per byte -- as Serge Vaudenay showed in 2002 and Juliano Rizzo and Thai Duong weaponized against ASP.NET in 2010.

This field guide follows the same bug leaking through progressively quieter channels: a loud error (Vaudenay), coarse timing (Canvel), statistical timing under unified errors (Lucky Thirteen), SSL 3.0's unchecked padding (POODLE), and the oracle re-created by Lucky Thirteen's own fix (CVE-2016-2107). Every point fix lost. The single structural cure is to invert the order: authenticate before you decrypt-and-unpad. Encrypt-then-MAC proves it attains IND-CCA plus INT-CTXT; AEAD, mandated by TLS 1.3, ships it with no knob to misset. The article ends with ranked decision rules and a design-review checklist for 2026.

1. The Break That Never Touched the Key

In September 2010, two researchers pointed a few thousand malformed requests at an ordinary ASP.NET application and walked away with its authentication tickets and its web.config -- the site's master secrets -- without ever attacking its AES-256 encryption or going near the key [@rizzo_duong_woot2010]. It had done nothing more than return one error when a decrypted request had bad padding and a different error when the padding was fine but the data was not. That one-bit difference is a decryption machine: the attackers never broke the cipher, they turned the server's error handling into the decryption function.

Sit with the paradox, because the rest of this article lives inside it. AES-256 was, and is, intact. Nobody factored anything, guessed a key, or exploited a weakness in the block cipher's rounds. The plaintext walked out the door one byte at a time purely because the server answered a question it should never have been willing to answer: was this ciphertext, which I did not create, well-formed after I decrypted it?

Juliano Rizzo and Thai Duong automated that question against WebResource.axd and ScriptResource.axd handlers and recovered Forms-authentication tickets and server files. The United States National Vulnerability Database catalogs it as CVE-2010-3332, the "ASP.NET Padding Oracle Vulnerability," and Microsoft shipped an out-of-band patch to close it [@cve_2010_3332]. This was not a lab curiosity. It was, at the time, the largest deployed instance of a bug that had been sitting in plain sight for eight years.

A padding oracle is an attack class, not a cipher weakness. A receiver decrypts an attacker-chosen ciphertext, checks whether the recovered plaintext has valid padding, and reveals the verdict -- through an error message, a timing difference, or any observable behavior. That single accept/reject bit, repeated, becomes a plaintext-recovery oracle that never attacks the underlying cipher or key.

The reframe is worth stating in the sharpest possible terms, because once you hold it you will see this bug everywhere.

The attacker never attacks the cipher. They turn the receiver's error handling into the decryption function -- "decrypt, then validate" becomes "decrypt, then confess."

This is Part 6 of a field guide for protocol designers. It assumes the malleability of CBC mode from Part 5 (the lever the attack pulls) and the chosen-ciphertext adversary from Part 1 (this is that adversary, deployed and winning). By the end you will carry one diagnostic sentence and drop every named break in this article -- Vaudenay, Lucky Thirteen, POODLE, and tomorrow's application-layer oracle -- onto it on sight: when a ciphertext you did not create arrives, what does the receiver reveal about it before it has proven the ciphertext authentic?

If AES was intact and the key was never touched, then the machine that recovered the plaintext was built entirely out of the server's own responses. That idea did not begin with CBC, or even with symmetric cryptography. To see the atom clearly, go back to the first time anyone realized that a receiver's verdict on validity is itself a decryption function.

2. A Validity Check Is a Decryption Oracle

The year is 1998, the place is Bell Labs, and Daniel Bleichenbacher is staring at an SSL server that is far too honest. When the server receives an RSA-encrypted message, it decrypts and checks whether the result has the structure that the PKCS #1 v1.5 standard demands. If the structure is wrong, it says so. Bleichenbacher realized that this single yes/no answer -- does the decrypted message have valid PKCS #1 formatting? -- is enough to recover the plaintext.

With roughly $2^{20}$ adaptively chosen queries, he could extract an RSA-protected session key without factoring the modulus and without ever learning the private key [@bleichenbacher1998]. The server's "is this well-formed?" answer was the attacker's decryption function. This is the seed of everything that follows.

It is also the moment to nail down a boundary that expert readers will check for. Bleichenbacher's attack is an RSA PKCS #1 v1.5 oracle -- a different primitive with different arithmetic. It is the conceptual ancestor of the CBC padding-oracle class "in spirit," but it is never itself a CBC padding oracle [@bleichenbacher1998].Calling Bleichenbacher "the first CBC padding oracle" is a common and consequential error. His target is RSA public-key encryption; the CBC class is symmetric. The shared idea -- a structural validity verdict on attacker-chosen ciphertext leaks the plaintext -- is what makes him the ancestor, not the mechanism. The distinction matters because the family tree has two branches, and confusing them muddles the fix.

In an adaptive chosen-ciphertext attack, the adversary submits ciphertexts of its choosing and learns something from the receiver's reaction to each one. A scheme is IND-CCA2 secure only if those reactions leak nothing that helps distinguish or recover plaintext. A padding oracle is precisely a receiver whose reaction leaks -- so it is a live, deployed IND-CCA2 break, the security notion this series defines in Part 1.

The whole subject lives inside that definition. If a receiver's response to a ciphertext it did not create tells the attacker anything, the game is already lost -- the only question is how expensive the win is.

Bleichenbacher's oracle never died; it changed clothes. **DROWN** (2016) revived it by using a server's SSLv2 support to attack modern TLS [@drown_attack2016]. **ROBOT** (2017 to 2018) found the same PKCS #1 v1.5 oracle live in load balancers and TLS stacks from major vendors, nearly two decades on [@robot_2018]. And the **Marvin Attack** (2023) showed the timing variant still breaks RSA implementations "previously thought immune" [@marvin_attack2023]. All three are RSA-side breaks -- a different primitive from the CBC story told here -- and they appear only as this signpost so nobody mistakes them for CBC oracles. The lesson each one re-teaches is the same: a validity verdict on attacker-chosen input is a decryption oracle, whatever the cipher.

Four years after Bleichenbacher, Serge Vaudenay carried the idea across the aisle from public-key to symmetric cryptography. In "Security Flaws Induced by CBC Padding," presented at EUROCRYPT 2002, he showed that a receiver which decrypts a CBC ciphertext and reveals whether the padding is valid becomes a plaintext-recovery oracle against SSL, IPSEC, and WTLS [@vaudenay2002]. This is the founding result of the class -- the moment "confidentiality without integrity" was shown to be, in the general case, a decryption oracle waiting to be asked.

The object it manipulates had arrived on schedule: PKCS #7 padding, the append-n-bytes-each-equal-to-n scheme, was standardized as RFC 2315 in the same era, so the manipulable surface and the attack template appeared together [@rfc2315]. Vaudenay's procedure is documented in cryptography's standard texts as the canonical illustration of chosen-ciphertext insecurity [@katz_lindell_imc].

timeline title Padding oracles, 1998 to 2022 1998 : Bleichenbacher RSA PKCS number 1 oracle 2000 : Bellare-Namprempre composition theorem 2002 : Vaudenay CBC padding oracle 2003 : Canvel timing oracle vs TLS 2010 : ASP.NET break by Rizzo and Duong 2013 : Lucky Thirteen statistical timing 2014 : POODLE and RFC 7366 Encrypt-then-MAC 2016 : CVE-2016-2107, the fix re-creates the oracle 2018 : TLS 1.3 removes CBC, mandates AEAD 2022 : BCP 195 recommends against CBC

Vaudenay's real contribution was noticing that CBC makes the symmetric version cleaner than Bleichenbacher's RSA original: flip a byte, watch the verdict, recover a byte. To believe that -- and to earn the right to use it on every later break -- you have to see the arithmetic. It is simpler than it sounds, and once you see it you cannot un-see it in any decrypt-then-check system you review.

3. The Atom: Vaudenay's Oracle, Worked Byte by Byte

Everything in this article is one move, performed once here and then reused by every named break with only the channel changed. Derive it in full and the rest of the piece can move fast. There are three steps: understand the padding, understand the lever, then watch the recovery.

Step one: three padding formats, disambiguated once

Block ciphers operate on whole blocks, so a message that does not fill the last block must be padded, and the padding must be self-describing so the receiver can strip it. PKCS #7 is the canonical scheme.

To pad a message to a block boundary, append `n` bytes, each equal to the value `n`. Need three bytes of padding? Append `03 03 03`. Need one? Append `01`. If the message is already block-aligned, append a *full extra block* of padding (for a 16-byte AES block, sixteen bytes of `10`). To unpad, read the final byte `n`, verify that the last `n` bytes all equal `n`, and strip them. Standardized in RFC 2315 [@rfc2315].

Here is the trap that catches expert readers, so disambiguate it now and never again: not every named attack operates on literal PKCS #7 bytes. Three formats matter, and mitigations for one do not automatically cover another.

PKCS #7 (RFC 2315) requires every pad byte to equal the pad length [@rfc2315]. TLS 1.0 through 1.2 use a PKCS #7-like scheme where every pad byte equals length - 1, and -- this detail will return with Lucky Thirteen -- the record is MAC'd, then padded, then encrypted [@rfc5246]. SSL 3.0 is the dangerous outlier: its pad bytes are arbitrary, and only the final length byte is constrained, so there is effectively no padding content to check at all [@rfc6101].

Padding format	Pad-byte rule	What the receiver checks	Break that targets it
PKCS #7 (RFC 2315)	Append `n` bytes each equal to `n`	Length byte and every pad byte	Vaudenay's canonical oracle
TLS 1.0 to 1.2 (RFC 5246)	Every pad byte equals `length - 1`; MAC then pad then encrypt	Length and pad bytes, after decrypt	Lucky Thirteen
SSL 3.0 (RFC 6101)	Pad bytes arbitrary; only the final length byte constrained	Length byte only; pad bytes unchecked	POODLE

The DES-era ancestor is PKCS #5, re-published as RFC 8018, which is the same scheme fixed at an 8-byte block; PKCS #7 generalizes it to any block size up to 255 [@rfc8018]. The two names describe one idea, which is why you see both in old code.

That single table is why "just make the padding check uniform" was never a complete fix -- it says nothing about SSL 3.0, where there is no pad content to make uniform.

Step two: CBC malleability, the lever

In CBC decryption, each plaintext block is $P_i = D_k(C_i) \oplus C_{i-1}$: decrypt the current ciphertext block with the block cipher, then XOR the previous ciphertext block. Because that XOR is the last step, an attacker who flips a bit in $C_{i-1}$ deterministically flips the *same* bit in $P_i$ -- steering the plaintext without any knowledge of the key. Part 5 derives this in full; here it is the lever the oracle pulls. flowchart TD Ci["Target ciphertext block Ct"] --> Dk["Block cipher decryption Dk"] Dk --> Inter["Intermediate block, equals Dk of Ct"] Cprev["Previous ciphertext block, attacker controls it"] --> XORnode(("XOR")) Inter --> XORnode XORnode --> Pt["Recovered plaintext block Pt"] Attacker["Attacker flips byte j of the previous block"] -.-> Cprev Attacker -.-> Result["Byte j of Pt flips by the same amount, no key needed"]

Hold the two pieces together: the receiver will tell you whether a decrypted block has valid padding, and you can steer any byte of that decrypted block by editing the block in front of it. Those two facts are a decryption oracle.

Step three: the recovery, last byte first

Take a target ciphertext block $C_t$ whose plaintext you want. Prepend a block $C'$ that you fully control, and ask the receiver to decrypt the pair. The receiver computes an intermediate block $I = D_k(C_t)$ and returns the plaintext $P = I \oplus C'$, then checks its padding. You do not know $I$, but you can search for it one byte at a time.

Fix your attention on the last byte. Vary $C'$'s last byte over all 256 possible values and watch the verdict. For exactly one value, the decrypted last byte becomes 0x01, which is valid single-byte padding, and the receiver accepts. At that instant you know that $I[\text{last}] \oplus C'[\text{last}] = \texttt{0x01}$, so the intermediate byte is $I[\text{last}] = C'[\text{last}] \oplus \texttt{0x01}$. XOR that against the real previous ciphertext byte and you have recovered a true plaintext byte -- and AES was never touched.

One honest wrinkle hides inside "about 128 guesses." A guess can occasionally produce valid longer padding by luck -- for instance if the plaintext already ended in 0x02, a crafted byte could yield 02 02. So the careful attacker perturbs the second-to-last byte to confirm the intended 01 interpretation. That rare double-check is why the average is ~128 rather than a clean 128, and why worst-case is 256.

To peel the next byte, target two-byte padding: set the known last byte to decrypt to 0x02 (you can, because you now know its intermediate), and brute-force the second-to-last byte until the receiver sees 02 02. March inward -- 03 03 03, then 04 04 04 04 -- and a full block falls. The cost is about 128 guesses per byte on average and 256 in the worst case [@vaudenay2002].

sequenceDiagram participant A as Attacker participant O as Oracle receiver Note over A,O: Goal, learn the last byte of target block Ct A->>O: Send chosen block Cprime, then Ct O->>O: Decrypt, inspect last-byte padding O-->>A: invalid padding Note over A: Increment last byte of Cprime, retry A->>O: The value making the last plaintext byte 0x01 O->>O: Padding parses as one valid byte O-->>A: valid padding Note over A,O: Intermediate byte is that guess XOR 0x01 Note over A: True plaintext byte is intermediate XOR real previous byte

Run the atom yourself. The simulation below models the oracle over a fixed intermediate block -- no real cipher, so you can watch the one-in-256 accept that leaks a byte.

{` // A toy padding oracle over a fixed 16-byte "intermediate" block. // No real crypto: we model I = D_k(C_t) as a known array so you can watch // the 1-in-256 accept that leaks one plaintext byte. const BLOCK = 16;

// Pretend these are the secret intermediate bytes I = D_k(C_t). const intermediate = [0x8a,0x2f,0x11,0x77,0x4c,0x93,0xe0,0x05, 0xbb,0x6d,0x19,0xa4,0x3c,0xf8,0x52,0x7e]; // The real previous-ciphertext block (known to the attacker). const realPrev = [0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xef, 0xfe,0xdc,0xba,0x98,0x76,0x54,0x32,0x10];

// Oracle: is the last decrypted byte valid 0x01 padding? function oracle(cprime) { const lastPlain = intermediate[BLOCK-1] ^ cprime[BLOCK-1]; return lastPlain === 0x01; // the single leaked bit }

// Attack: brute-force the last byte of a controlled block. let guesses = 0; const cprime = new Array(BLOCK).fill(0); for (let g = 0; g < 256; g++) { guesses++; cprime[BLOCK-1] = g; if (oracle(cprime)) { const intByte = g ^ 0x01; // I[last] = guess XOR 0x01 const plainByte = intByte ^ realPrev[BLOCK-1]; console.log("Accepted after " + guesses + " guesses"); console.log("Recovered intermediate byte: 0x" + intByte.toString(16)); console.log("Recovered plaintext byte: 0x" + plainByte.toString(16)); break; } } `}

Key idea: One reliable accept/reject bit on attacker-chosen ciphertext, plus CBC's malleability, is a complete decryption function -- about 128 guesses per byte, and the key is never touched. Every named break in the rest of this article is that same atom, with only the channel that carries the bit changed.

That is Aha number one, and it dismantles the mental model most engineers start with. AES-256's strength was never the variable. The variable was what the receiver was willing to say about a ciphertext it had not authenticated. Before moving on, one point of vocabulary, because it changes how you diagnose the bug.

Note: A padding oracle is an attack class -- a side channel against a construction (CBC-mode encryption composed with a MAC), not a weakness in a primitive. The block cipher (AES) and the MAC (HMAC) are the primitives, and they are doing exactly what they promise. The oracle lives in how they are composed and in what the receiver reveals. Say "attack class" and "construction," never "the padding-oracle primitive."

The atom needs exactly one thing from the receiver: a distinguishable answer to "was the padding valid?" Vaudenay read that answer off a loud error message. The next fifteen years are the story of the field muffling that answer, one channel at a time -- and the same bit escaping through the next-quietest one every single time.

4. One Distinguisher, Four Quieter Channels

The atom never changes. What changes is how the accept/reject bit is observed -- and each time the field silences one channel, the bit re-emerges through a quieter one. Here is the entire failure catalog as one descending staircase, with POODLE branching off to the side.

Channel one -- the loud error message (Vaudenay 2002, ASP.NET 2010). The first receivers simply returned a distinct "padding error," trivially observable. Vaudenay read it straight off the response, and eight years later Rizzo and Duong read it off differing HTTP responses from ASP.NET applications, recovering authentication tickets and web.config at scale [@rizzo_duong_woot2010] [@cve_2010_3332]. The obvious countermeasure: return one indistinguishable error for both padding failures and data failures. That closes the loudest channel and opens the next.

Channel two -- coarse timing (Canvel et al. 2003). Once OpenSSL returned the same bad_record_mac alert for padding and MAC failures, Brice Canvel, Alain Hiltgen, Serge Vaudenay, and Martin Vuagnoux showed the verdict still leaked through when the alert arrived: a receiver that accepted the padding went on to compute the MAC, while one that rejected padding could bail early, and the resulting millisecond gap reconstituted the oracle [@canvel2003]. They intercepted a password over a live OpenSSL TLS channel. This is the first concrete demonstration of the pattern that organizes the whole subject. The standards response, TLS 1.1 (RFC 4346), mandated uniform alert handling and explicit per-record initialization vectors [@rfc4346]. The countermeasure: make the decryption path constant-time -- compute the MAC even on padding failure so both paths take equal time.

Channel three -- statistical timing, Lucky Thirteen (AlFardan and Paterson, 2013). This is the break that proved constant-time is the hard problem, and it is worth binding tightly to the thesis, because it is not merely "a timing attack." TLS uses MAC-then-encrypt with a specific receiver order: decrypt, strip the padding, then run HMAC over what remains. The trouble is that "what remains" has a length that depends on how many bytes the receiver treated as padding -- and HMAC's running time depends on that length, because the hash compression function runs one extra time at certain length thresholds. So the attacker's guess about the padding changes the MAC-computation time by a few tens of CPU cycles [@lucky13_2013].

A comparison (or, more broadly, a code path) is constant-time when its running time does not depend on secret data or on how far into the data a difference occurs. A tag check that returns early on the first mismatched byte leaks *where* the mismatch is; a constant-time check XORs all bytes and inspects the accumulated difference once. Lucky Thirteen forced constant-time unpadding-and-MAC on the whole industry, and CVE-2016-2107 shows how easily a hand-written fast path reintroduces the oracle -- there, through a missing length check that produced a distinguishable alert rather than a timing gap.

Nadhem AlFardan and Kenneth Paterson amplified that sub-microsecond difference statistically across the network, recovering a full plaintext block in about $2^{23}$ TLS sessions, dropping to roughly $2^{13}$ sessions per byte with favorable positioning, across OpenSSL, GnuTLS, PolarSSL, and more (CVE-2013-0169) [@lucky13_2013] [@cve_2013_0169]. Bind it to the ordering: MAC-then-encrypt forces a length-dependent MAC, so the timing leak is a property of the order of operations, not a stray implementation slip.The name "Lucky Thirteen" comes from the 13 bytes TLS feeds into the HMAC before the record body: a 5-byte TLS record header plus an 8-byte sequence number. Their alignment against the 64-byte hash-compression boundary is exactly what opens the timing gap. A number that sounds whimsical is really a byte-counting accident. The next countermeasure was obvious and genuinely hard: make the MAC and the unpadding constant-time.

Channel four -- unchecked structure, POODLE (Moller, Duong, and Kotowicz 2014). Here the staircase forks into a parallel branch. SSL 3.0's pad bytes are arbitrary by specification -- only the final length byte is constrained -- so there is no padding check to harden, no message to unify, no timing to flatten [@rfc6101]. An attacker who maneuvers a target byte into the last position of a block learns it from MAC pass or fail alone, needing neither an error message nor a timing measurement, at an expected cost of 256 SSL 3.0 requests per byte [@poodle_writeup] [@cve_2014_3566]. The name expands to Padding Oracle On Downgraded Legacy Encryption, and this is where a persistent misconception must be corrected.POODLE's downgrade is the enabler, not the bug. The downgrade only forces a modern client back onto vulnerable SSL 3.0; the vulnerability is the unchecked pad. The proof is TLS-POODLE (CVE-2014-8730), which hit TLS stacks that copied SSL 3.0's lax padding check and works with no downgrade at all [@cve_2014_8730]. Frame POODLE as a padding oracle first, a downgrade second. Google's write-up and the accompanying announcement documented the mechanism and effort in full [@poodle_writeup] [@google_poodle_blog]. Because there is no check to make uniform, the only fix is to remove SSL 3.0, and CBC, from the wire entirely.

Channel five -- the oracle the fix re-created (CVE-2016-2107, 2016). This is the single clearest proof of the thesis. OpenSSL's AES-NI assembly fast path, written to make the Lucky Thirteen countermeasure constant-time, mishandled a length check -- and re-opened a padding oracle. It was found with the TLS-Attacker fuzzing methodology [@somorovsky_fuzzing2016], and the National Vulnerability Database records the cause in words worth quoting exactly.

This vulnerability [CVE-2016-2107] exists because of an incorrect fix for CVE-2013-0169.

The constant-time patch for Lucky Thirteen re-created the very oracle it was written to close, and OpenSSL shipped the repair in 1.0.2h and 1.0.1t [@cve_2016_2107] [@openssl_secadv_20160503]. It did not travel alone. Amazon's s2n library added a Lucky Thirteen countermeasure that still leaked, revived as Lucky Microseconds by Martin Albrecht and Kenneth Paterson -- and the randomized delays s2n had added as masking were part of the problem [@lucky_microseconds2016].

Then, in 2019, Craig Young's Zombie POODLE and GOLDENDOODLE and a large Internet scan by Robert Merget and colleagues found CBC padding oracles still live in 1.83% of the Alexa Top Million, distinguishable by the content of server responses with no precise timing required at all [@merget2019] [@qualys_zombie_poodle2019].

Zombie POODLE is an invalid-padding, valid-MAC oracle; GOLDENDOODLE is the mirror image, a valid-padding, invalid-MAC oracle. Different verdicts, same atom.

Incident	Year	Leak channel	Root cause	Primary source
Vaudenay	2002	Distinct padding error	MtE-CBC observable branch	[@vaudenay2002]
Canvel et al.	2003	Coarse timing	MAC computed vs skipped	[@canvel2003]
ASP.NET (Rizzo, Duong)	2010	Distinct HTTP error	Padding vs data error revealed	[@rizzo_duong_woot2010] [@cve_2010_3332]
Lucky Thirteen	2013	Statistical timing	Strip-then-MAC length dependence	[@lucky13_2013] [@cve_2013_0169]
POODLE	2014	MAC pass or fail on shifted byte	SSL 3.0 unchecked padding	[@poodle_writeup] [@cve_2014_3566]
TLS-POODLE	2014	Same, no downgrade	TLS stacks copying the lax check	[@cve_2014_8730]
CVE-2016-2107	2016	Distinguishable alert (bad_record_mac vs record_overflow)	Constant-time fix slipped a length check	[@cve_2016_2107]
Zombie POODLE, GOLDENDOODLE	2019	Content differences in responses	Deployed CBC-HMAC long tail, 1.83%	[@merget2019] [@qualys_zombie_poodle2019]

Note: Never return a distinct "bad padding" error, and never let padding validity change a branch or the timing of the response. Any distinguishable decryption outcome on attacker-chosen ciphertext -- an error string, a millisecond, a TCP reset, a difference in response content -- is a padding oracle. The channel does not matter; the observability does.

One clarification sharpens the definition by contrast. BEAST (2011) is often filed next to these breaks, but it is not a padding oracle: it is a predictable-initialization-vector, chosen-plaintext attack on CBC [@beast_2011], and it belongs to the IV story of Part 2 and Part 5, not here.The tell is the direction of information flow. A padding oracle recovers unknown plaintext from the receiver's verdict on the attacker's ciphertext. BEAST confirms guessed plaintext by exploiting a predictable IV. Different precondition, different fix -- naming it here only sharpens what a padding oracle is.

Five generations, five channels, one bit. Every fix silenced the loudest remaining leak, and every fix was beaten by the next-quietest -- including a fix that became its own oracle. Whack-a-mole is not a strategy; it is a symptom. And the symptom points at a diagnosis the field had actually proved correct two years before Vaudenay's attack, and simply had not deployed.

5. The Bug Is the Order, Not the Padding

Stop looking at the padding. A padding oracle is not a padding bug; it is the consequence of checking padding on data you have not authenticated. Change what you check first, and the oracle has nothing to answer. To see why, you need the piece the attack has been quietly relying on: the MAC, and the three ways to combine it with encryption.

A MAC is a keyed tag that proves a message is authentic and unmodified: only a holder of the secret key can produce a tag that verifies. HMAC is the deployed instance. A valid MAC on a ciphertext means the ciphertext is genuine -- it came from someone with the key, and nothing tampered with it. Part 3 covers HMAC's structure; here the point is simply *when* you check it.

In 2000, Mihir Bellare and Chanathip Namprempre formalized the three "generic composition" ways to bolt a MAC onto an encryption scheme and proved exactly what each one buys [@bellare_namprempre2000]. Each maps cleanly onto a real protocol.

Compute the MAC over the *plaintext*, then encrypt the plaintext, MAC, and padding together. On receipt the order is forced: decrypt, strip padding, *then* verify the MAC. Because the receiver must decrypt and unpad before it can check authenticity, the padding verdict is observable by construction. This is SSL and TLS's original choice -- and the reason SSL/TLS, and only SSL/TLS, became a fifteen-year catalog of padding oracles. Encrypt the plaintext, then compute the MAC over the *ciphertext* (and the IV), and transmit ciphertext plus tag. On receipt, verify the tag *first*; decrypt only if it passes. A ciphertext the attacker altered fails the MAC and is discarded before any padding logic runs -- so there is no padding verdict to leak, through any channel. This is IPsec ESP's design and the shape RFC 7366 retrofits onto TLS.

The third sibling, encrypt-and-MAC, tags the plaintext and sends the tag alongside the ciphertext; SSH chose it. It still forces decryption before verification, and because the tag is over the plaintext it can leak plaintext equality, so it is no cure [@bellare_kohno_namprempre_ssh2002].

flowchart TD subgraph MtE["MAC-then-encrypt (SSL and TLS)"] M1["Decrypt"] --> M2["Strip padding"] --> M3["Verify MAC"] end subgraph EnM["Encrypt-and-MAC (SSH)"] E1["Decrypt"] --> E2["Verify MAC over plaintext"] end subgraph EtM["Encrypt-then-MAC (IPsec ESP)"] T1["Verify MAC over IV and ciphertext"] --> T2["Decrypt"] --> T3["Strip padding"] end

Look at where the MAC check sits. In the first two, unauthenticated ciphertext reaches the decrypt-and-parse machinery before anyone has proven it genuine. In the third, a forged ciphertext dies at the door.

Composition	MAC covers	Receiver order	IND-CCA (generic)	INT-CTXT (generic)	Protocol
MAC-then-encrypt	Plaintext	Decrypt, unpad, verify	Not guaranteed	No	SSL and TLS
Encrypt-and-MAC	Plaintext	Decrypt, verify	No	No	SSH
Encrypt-then-MAC	Ciphertext and IV	Verify, decrypt, unpad	Yes	Yes	IPsec ESP

Now the theorem, stated precisely. Encrypt-then-MAC, composed from an IND-CPA encryption scheme and a strongly unforgeable MAC (SUF-CMA), generically attains both IND-CCA and integrity of ciphertexts -- the strongest guarantees of the three -- while MAC-then-encrypt and encrypt-and-MAC do not generically reach integrity of ciphertexts [@bellare_namprempre2000]. Strong unforgeability is the load-bearing word: with only ordinary unforgeability, a second valid tag on the same ciphertext is a fresh accepted ciphertext, and the guarantee weakens to integrity of plaintexts. In practice the qualifier is free, because HMAC is strongly unforgeable, so the deployed guarantee is exactly as stated. That is the whole game: a construction with integrity of ciphertexts rejects any forged ciphertext before decryption, so a padding oracle cannot form.

One honest caveat, because the sloppy version of this claim is wrong. Hugo Krawczyk proved in 2001 that MAC-then-encrypt is secure when the encryption is CBC or counter mode, under stated conditions [@krawczyk2001]. So MtE is not "always broken."Krawczyk's result is conditional: MtE with CBC or CTR is provably secure in the model, which means Canvel, Lucky Thirteen, and POODLE are implementation, side-channel, and underspecified-padding failures -- not refutations of a theorem. The precise statement guards against the overreach "MtE is broken." What is true is subtler and more useful: MtE is conditionally provable and practically fragile, because it leaves unauthenticated ciphertext reaching the parser, and holding the model's assumptions in compiled code is the hard part [@krawczyk2001]. The practitioner's takeaway is not "the theorem was wrong" but "the theorem's assumptions are unreasonably hard to preserve in real code -- so change the order and stop needing them." The practitioner literature has said as much for years [@ferguson_schneier_kohno_ce].

Watch the difference on a single tampered ciphertext. The MtE receiver leaks a distinguishable outcome; the EtM receiver returns one indistinguishable failure before it parses anything.

{` // Two toy receivers over the SAME tampered ciphertext. // No real crypto: "decrypt" and "macOk" are stand-ins so you can see // what each receiver reveals. function decrypt(ct) { return { paddingValid: false }; } // tampering broke the pad function macOk(ct) { return ct.tag === "authentic"; } // forged tag fails

const tampered = { tag: "forged" };

// MAC-then-encrypt: decrypt and check padding BEFORE the MAC. function mteReceive(ct) { const p = decrypt(ct); if (!p.paddingValid) return "PADDING_ERROR"; // leaks the padding verdict if (!macOk(ct)) return "MAC_ERROR"; return "OK"; }

// Encrypt-then-MAC: verify the MAC FIRST; never touch padding on forgeries. function etmReceive(ct) { if (!macOk(ct)) return "FAIL"; // one indistinguishable outcome const p = decrypt(ct); if (!p.paddingValid) return "FAIL"; return "OK"; }

console.log("MtE says:", mteReceive(tampered)); // PADDING_ERROR (distinguishable) console.log("EtM says:", etmReceive(tampered)); // FAIL (nothing to learn) `}

Key idea: The bug is the order, not the padding. Silencing channels is whack-a-mole; checking authenticity first -- Encrypt-then-MAC, and its successor AEAD -- removes the precondition that unauthenticated ciphertext ever reaches a padding check, so the oracle has nothing left to answer.

That is Aha number two, and it reorganizes the entire catalog. Every generation before Encrypt-then-MAC silenced a channel while leaving the precondition intact; the last two remove the precondition itself.

flowchart TD G1["Gen 1, distinct padding error"] --> G2["Gen 2, unified alert"] G2 --> G3["Gen 3, constant-time MtE"] G3 --> G4["Gen 4, Encrypt-then-MAC"] G4 --> G5["Gen 5, AEAD"] G1 -.-> S["Silenced a channel, precondition intact"] G2 -.-> S G3 -.-> S G4 -.-> R["Removed the precondition, authenticity first"] G5 -.-> R The three compositions were not tried in sequence; they were chosen in *parallel* by different protocols and coexisted for years. MAC-then-encrypt went into SSL and TLS, encrypt-and-MAC into SSH, Encrypt-then-MAC into IPsec ESP [@bellare_namprempre2000]. Only the MtE branch became the fifteen-year catalog. IPsec's Encrypt-then-MAC branch was structurally immune from the start, which is the quiet punchline of the whole story: the fix TLS reached for in 2014 was, in effect, "become IPsec" -- the negotiated `encrypt_then_mac` extension of RFC 7366 [@rfc7366].

AEAD (RFC 5116) is Encrypt-then-MAC's standardized successor: one primitive, authenticity intrinsic, no composition knob to misset [@rfc5116]. The theorem was published in 2000. Vaudenay's attack landed in 2002. And the fix did not reach the deployed TLS base until 2014 to 2018. The rest of this article is what "check authenticity first" looks like when it finally shipped at Internet scale -- and why, even now, the class is not entirely dead.

6. The State of the Art: Closed by Construction

The modern answer is boring, and that is exactly the point. Use a primitive where a padding oracle cannot exist, because authenticity is checked first and there is no block padding at all.

An AEAD primitive takes a key, a nonce, a plaintext, and optional associated data, and produces a ciphertext with an integral authentication tag. Decryption verifies the tag as part of the operation and returns *nothing* -- a single indistinguishable failure -- if it does not match. There is no separate MAC to order, and for the stream-based AEADs in wide use there is no block padding to be oracular. Standardized as an interface in RFC 5116 [@rfc5116].

Two AEADs carry nearly all modern traffic. AES-GCM is the default where AES hardware exists: it is AES in counter mode for encryption, plus a GHASH tag over the ciphertext and associated data, verified before any plaintext is released. ChaCha20-Poly1305 is the default where AES hardware does not exist -- Google deployed it in Chrome on Android because it runs about three times faster than AES-GCM on devices without AES acceleration, and it is constant-time in portable software by design [@rfc8439] [@google_chacha_blog2014]. Both are counter-mode stream constructions, and that structural fact, not the label "AEAD," is why they are immune.A stream construction has no block padding at all -- the keystream is simply truncated to the plaintext length. So the object Vaudenay's atom acts on, a padded final block whose validity the receiver checks, does not exist. There is no surface. This is why "GCM has a tag, could it have a padding oracle?" answers itself: there is nothing to pad.

Then the standards removed the choice. TLS 1.3 (RFC 8446, 2018) removes CBC cipher suites entirely and mandates AEAD, and QUIC inherits that record layer, so a conformant modern stack cannot express the padding-oracle precondition [@rfc8446].

For the deployed base that could not jump straight to 1.3, RFC 7366 (2014) retrofits Encrypt-then-MAC onto TLS 1.0 through 1.2 as a negotiated extension -- extension type 22 -- citing Bellare-Namprempre and Krawczyk by name as the reason MtE "is no longer regarded as secure" [@rfc7366]. And BCP 195 (RFC 9325, 2022) codifies the operational rule: prefer TLS 1.3, prefer AEAD suites on 1.2, and recommend against CBC [@rfc9325].

Method	How it works	What it buys	Status 2024 to 2026
AES-GCM	AES-CTR plus GHASH tag, verified first	No padding surface, fastest with AES hardware	Default (TLS 1.3, QUIC)
ChaCha20-Poly1305	ChaCha20 plus Poly1305, verified first	Constant-time in software, ~3x without AES-NI	Co-default, WireGuard, OpenSSH
Encrypt-then-MAC (RFC 7366)	MAC over IV and ciphertext, verified first	Structural fix for legacy CBC	Compose-by-hand rule
Constant-time CBC-HMAC	Harden the MtE order in place	Nothing new; fragile	Deprecated (BCP 195)
Misuse-resistant, committing AEAD	AES-GCM-SIV, committing wrappers	Nonce-repeat safety, key commitment	Ascending, niche
Padding-oracle detection	TLS-Attacker, padcheck scanners	Measures residual exposure	Active tooling

The honest status has two levels. At the primitive level the class is closed: TLS 1.3 has no CBC-HMAC record layer, so it has no padding oracle. But CBC-HMAC survives in the long tail -- legacy TLS, VPN appliances, load balancers, IoT stacks, and home-grown application crypto -- which is why padding oracles are still discovered, in 1.83% of the top million as recently as the 2019 scan, exploitable without precise timing [@merget2019].

Note: Treat any distinguishable decryption error on a CBC-HMAC endpoint as a reportable finding, not a performance bug to smooth over. The lesson of five generations is that the construction, not any single leak, is the problem: CBC-HMAC is the thing to retire. Every hour spent hardening its constant-time behavior is an hour not spent migrating to AEAD, which needs no such hardening.

"Use AEAD" is the entire answer for greenfield code. But engineers inherit constraints -- a mode they cannot change, a library without AEAD, a protocol mid-migration -- so the real question is not "what is best" but "what are my options, ranked, and exactly when does each apply?"

7. How to Not Have a Padding Oracle, Ranked

There are three ways to keep a padding oracle out of your system, in strict order of durability -- and the ranking is a theorem, not a taste. The yardstick is one question: is authenticity checked before anything parses the plaintext?

First choice: AEAD. Authenticity is intrinsic, there is no padding, and there are zero composition knobs for an implementer to misset. This is the default, full stop. Its own frontier is a genuinely different problem, not a padding successor: nonce reuse under AES-GCM is catastrophic -- the "forbidden attack," demonstrated against real TLS and IPMI stacks by Böck et al. (WOOT '16) [@bock_nonce_woot2016] -- and standard AEAD is not key-committing, so one ciphertext can be made to open to different valid plaintexts under different keys [@albertini_committing2022]. Those are addressed by AES-GCM-SIV for nonce-misuse resistance and by committing AEAD constructions, which the CFRG's property vocabulary now names formally [@rfc8452] [@rfc9771]. Treat that as a one-line signpost, not a reason to hesitate on AEAD.

Second choice: Encrypt-then-MAC by hand. Correct, but only if you get three things right -- an independent MAC key (never the encryption key), coverage of both the IV and the ciphertext, and a constant-time tag comparison performed before any decrypt or unpad. That is the RFC 7366 shape [@rfc7366]. Three knobs an implementer can misset is precisely the argument for reaching for AEAD's zero knobs whenever you can.

Third choice, and only if forced: constant-time MtE / CBC-HMAC. This is the "make the existing order safe in place" path, and it is the cautionary option to retire, not to choose. Lucky Thirteen, Lucky Microseconds, and CVE-2016-2107 are the evidence that it fights the construction: MtE keeps unauthenticated ciphertext reaching the parser, so the distinguisher re-emerges through whatever the CPU or the compiler leaves open [@lucky13_2013] [@cve_2016_2107].

Property	AES-GCM	ChaCha20-Poly1305	Encrypt-then-MAC (CBC-HMAC)	Constant-time MtE (CBC-HMAC)	AES-GCM-SIV
Authenticity checked first?	Yes (intrinsic)	Yes (intrinsic)	Yes (verify tag first)	No (decrypt and unpad first)	Yes (intrinsic)
Padding-oracle surface	None (stream)	None (stream)	None (rejected pre-unpad)	Full (precondition survives)	None (stream)
Composition knobs to misset	0	0	3	Many	0
Nonce or IV reuse behavior	Catastrophic	Catastrophic	IV must be unpredictable	IV must be unpredictable	Graceful (equality leak only)
Status 2024 to 2026	Active default	Active co-default	Compose-by-hand rule	Deprecated (BCP 195)	Ascending, niche

Only the first two options remove the precondition; the third merely silences the loudest channel. That is the whole ranking, and it maps onto the parallel history from the last section: AEAD and Encrypt-then-MAC are what IPsec effectively had from the start, while constant-time MtE is the fifteen-year attempt to make SSL/TLS's original order safe without changing it.

So the durable options all share one property: they refuse to let unauthenticated ciphertext reach a parser. That raises a deeper question a careful reader should now be asking. Why is one accept/reject bit enough to be fatal in the first place -- and is Encrypt-then-MAC provably enough to stop it, or just empirically better so far?

8. Why a Bit Is Enough, and Why the Fix Is a Theorem

Two boundaries frame the whole subject: how little leakage the attacker needs, which is frighteningly little, and how hard the defender's guarantee actually is, which is a proof rather than a hope.

The lower bound: one reliable bit suffices. A single accept/reject bit per query, combined with CBC's malleability, recovers plaintext at about 128 guesses per byte, and the cipher is never attacked [@vaudenay2002]. The consequence is a hard limit on defense that every engineer should internalize: there is no "leak too small to matter," only "too noisy to measure cheaply." The bit is information-theoretically sufficient; the only variable is how many queries it takes to read it reliably.

Note: Lucky Thirteen turned a difference of a few tens of CPU cycles -- invisible to a human, buried in network jitter -- into full plaintext recovery by amplifying it statistically over many sessions [@lucky13_2013]. If a one-bit distinguisher exists at all, "make it quieter" only raises the query count; it never reaches zero. The only defense that reduces the leak to nothing is removing the precondition, so no bit is ever produced.

The impossibility in the middle. An unauthenticated, malleable mode is provably not IND-CCA2. CBC without integrity is a decryption oracle by construction, so no amount of error-message hygiene or timing equalization can rescue MAC-then-encrypt CBC against a determined side-channel adversary. The impossibility lives in the precondition itself -- in letting a malleable ciphertext be decrypted before it is authenticated -- which is why the deployed padding oracle is exactly the IND-CCA2 break this series defines in Part 1.

The upper bound: the fix is a hard theorem. The best achievable defense is a proved one.

A scheme has integrity of ciphertexts when an adversary, even after seeing many valid ciphertexts, cannot produce *any* new ciphertext the receiver accepts as valid. This is the property that closes the oracle: if every forged ciphertext is rejected before decryption, the receiver never reveals a padding verdict on attacker-chosen input. Encrypt-then-MAC and AEAD provide it; MAC-then-encrypt does not, generically.

Encrypt-then-MAC with an IND-CPA cipher and a strongly unforgeable MAC (SUF-CMA) generically attains IND-CCA plus integrity of ciphertexts, so a forged ciphertext is rejected with overwhelming probability before decryption -- the oracle is closed by theorem, not by patch [@bellare_namprempre2000]. Krawczyk marks the honest boundary of the alternative: MAC-then-encrypt is conditionally provable for CBC and counter mode, so the real-world MtE breaks are implementation and side-channel failures, not refutations of a theorem -- but Encrypt-then-MAC needs no such conditions [@krawczyk2001].

Key idea: At the level of construction design there is no gap. The lower bound -- any observable padding verdict yields byte-at-a-time decryption -- is met by removing the precondition, and the upper bound -- reject forgeries before decryption, IND-CCA plus INT-CTXT -- is achieved by Encrypt-then-MAC and AEAD. Best-possible and best-achieved coincide. Every remaining gap is implementation and deployment, not mathematics.

That is Aha number three, and it is a humbler note than it first sounds. If the design problem is provably solved, why do scanners still find these oracles in production, and why did a correct construction get re-broken by its own patch? Because "solved on paper" and "solved in a compiled binary on a specific CPU, deployed to a billion devices" are different sentences -- and the space between them is where the class still lives.

9. Where Padding Oracles Still Live

The construction-level problem is closed; the class is not. Here are four places the 2002 bug remains exploitable, and one frontier that would end the whack-a-mole.

Constant-time is a moving target. Even with the correct construction, a specific compiled binary on a specific CPU can reintroduce a secret-dependent timing difference through branch prediction, cache behavior, or an assembly fast path -- and the countermeasure can also slip in a plainer way. CVE-2016-2107 is the canonical evidence: OpenSSL's AES-NI fast path, written to make the fix constant-time, dropped a length check and re-created the oracle -- leaking not through timing but through a distinguishable alert (bad_record_mac versus record_overflow), which is why TLS-Attacker found it by clustering responses rather than measuring cycles [@cve_2016_2107]. The strongest partial answer is formally verified, secret-independent cryptographic code -- HACL* and EverCrypt prove memory safety, functional correctness, and secret independence, and ship in Firefox and NSS [@hacl_star]. But that covers primitives, not yet whole record layers end to end, so the verification frontier is real.

The deployed CBC-HMAC long tail. Legacy TLS, VPN appliances, load balancers, and IoT stacks that cannot move to TLS 1.3 keep MAC-then-encrypt CBC alive. The 2019 scan put the exposure at 1.83% of the top million, exploitable without precise timing, and the population shrinks year over year rather than vanishing -- a trend the SSL Pulse dashboard tracks [@merget2019] [@ssl_pulse].

Application-layer oracles. This is the part TLS 1.3 does not reach, and it deserves its own aside because it is where the next decade of these bugs will be found.

Tibor Jager and Juraj Somorovsky broke the W3C XML Encryption standard with the same oracle, decrypting XML in SOAP and web-services stacks by watching how an endpoint reacted to manipulated ciphertext -- proof that the mechanism operates far outside TLS [@jager_somorovsky_xmlenc2011]. The application layer is full of the same shape: JWE and JOSE `A128CBC-HS256` tokens, encrypted cookies, and ViewState-style tokens reproduce the 2002 bug, often with no MAC at all, above TLS where network scanners cannot see them. A separate but adjacent hazard, Efail, exploited a CBC *malleability gadget* in S/MIME and a CFB gadget in OpenPGP to exfiltrate plaintext directly -- not a padding-verdict oracle, but the same "unauthenticated malleable ciphertext" precondition wearing different clothes [@efail2018].

Format and parse oracles beyond padding. Generalize once more: any observable post-decryption structural verdict -- a JSON parse success, a protobuf validity check, a decompression outcome -- is a padding oracle by another name whenever it acts on unauthenticated ciphertext. The padding was only ever the first structure anyone checked. Jager and Somorovsky already proved the mechanism outside padding entirely [@jager_somorovsky_xmlenc2011], and systematic detection of "decrypt-then-parse" leaks is not yet automated the way TLS padding-oracle scanning now is.

AEAD's own frontier. The successor primitive has two sharp edges of its own -- catastrophic nonce reuse in AES-GCM [@bock_nonce_woot2016] and the lack of key commitment [@albertini_committing2022] -- which matter most in exactly the places large systems trip: nonce management across many distributed senders, and multi-key or multi-recipient contexts like JWT and envelope encryption. Both are addressed separately today, by AES-GCM-SIV for misuse resistance and by committing constructions that RFC 9771's vocabulary now specifies, but no single ubiquitous primitive yet delivers misuse-resistant and committing and fast and online at once [@rfc8452] [@rfc9771]. That convergence is the open engineering target, and it is a different problem from the padding oracle, not a continuation of it.

Every one of these is the same sentence wearing new clothes: unauthenticated, attacker-chosen input reaching a check whose verdict is observable. Which means the practical guide almost writes itself -- it is the thesis made operational.

10. Decision Rules: Use X With These Params in Case Y

Everything above collapses into a short decision procedure and a shorter list of nevers.

flowchart TD Start["Need authenticated encryption"] --> Q1{"Greenfield design?"} Q1 -->|"Yes"| Q2{"AES hardware present?"} Q2 -->|"Yes"| GCM["AES-GCM, unique 96-bit nonce"] Q2 -->|"No"| ChaCha["ChaCha20-Poly1305"] Q1 -->|"No, stuck with CBC"| Q3{"Can you retire CBC?"} Q3 -->|"Yes"| GCM Q3 -->|"No"| EtM["Encrypt-then-MAC, RFC 7366, verify first"] GCM --> Q4{"Nonce uniqueness hard?"} Q4 -->|"Yes"| SIV["AES-GCM-SIV"] Q4 -->|"No"| Done["Ship it"]

The rules, in order:

Default to a vetted AEAD, from a library you cannot misuse. Use AES-GCM with a unique 96-bit nonce and fewer than $2^{32}$ messages per key where the CPU has AES-NI; use ChaCha20-Poly1305 where there is no AES hardware, or when you want constant-time behavior from portable software [@rfc8439]. In application code, reach for libsodium's secretbox or Google Tink rather than raw primitives, and prefer any API where you cannot express "decrypt, then check" -- the safest libraries never hand you plaintext before verification.
If nonce uniqueness is hard to guarantee across many independent senders or under snapshot and rollback risk, use AES-GCM-SIV, so a nonce repeat degrades gracefully instead of catastrophically [@rfc8452].
If a ciphertext may be opened under more than one key -- JWT and JOSE, envelope encryption, abuse reporting -- use a committing AEAD [@albertini_committing2022] [@rfc9771].
If you must compose by hand, use Encrypt-then-MAC: encrypt, then compute the MAC over the IV and ciphertext with an independent MAC key, and verify the tag in constant time before you decrypt or unpad [@rfc7366].
On a legacy TLS 1.2 CBC deployment you cannot yet retire, negotiate RFC 7366 Encrypt-then-MAC, prefer AEAD suites, and follow BCP 195 [@rfc9325].
Never return a distinct "bad padding" error; never branch or vary timing on padding validity; never decrypt before verifying; never reuse the encryption key as the MAC key; never leave the IV out of the MAC; and never ship SSL 3.0 or non-RFC-7366 CBC.

If you are stuck at the fourth rule, the shape below is the reference. It is dependency-free and non-cryptographic on purpose: copy the order of operations, not the stand-in primitives.

{` // Reference SHAPE for a correct Encrypt-then-MAC open(). // constantTimeEqual, hmac, cbcDecrypt, removePkcs7 are stand-ins, NOT real crypto. function constantTimeEqual(a, b) { if (a.length !== b.length) return false; let diff = 0; for (let i = 0; i < a.length; i++) diff |= a[i] ^ b[i]; return diff === 0; // no early exit: time is independent of where they differ }

function open(kEnc, kMac, iv, ciphertext, tag) { // 1. Authenticate FIRST, over IV concat ciphertext, in constant time. const expected = hmac(kMac, iv.concat(ciphertext)); if (!constantTimeEqual(tag, expected)) return "FAIL"; // one outcome, always

// 2. Only authentic ciphertext ever reaches decryption and unpadding. const padded = cbcDecrypt(kEnc, iv, ciphertext); const plain = removePkcs7(padded); return plain === null ? "FAIL" : plain; // same FAIL either way }

// Stand-ins so the snippet runs (NOT secure): function hmac(k, data) { return data.map((b) => (b ^ k) & 0xff); } function cbcDecrypt(k, iv, c) { return c; } function removePkcs7(p) { return p; }

console.log(open(1, 2, [9, 9], [4, 5, 6], [7, 7, 7])); // FAIL: forged tag rejected first `}

Every misuse in real code maps one-to-one onto a named break in the catalog. That mapping is the practical guide as a grid.

Misuse seen in code	The named break it reproduces	The fix
Distinct "bad padding" error	Vaudenay, ASP.NET	Verify authenticity first
Non-constant-time unpad and MAC	Lucky Thirteen	AEAD, or constant-time EtM
Unchecked pad bytes	POODLE	Retire SSL 3.0 and CBC
AES-NI fast-path length slip	CVE-2016-2107	Verified constant-time, or AEAD
Verifying the MAC after decrypting	The whole class	Encrypt-then-MAC ordering
Nonce reuse under AES-GCM	The forbidden attack	Unique nonces, or AES-GCM-SIV
App-layer encrypt with no MAC	JWE and cookie oracles	A committing AEAD

Note: Use a vetted AEAD: AES-GCM with unique 96-bit nonces and the under-$2^{32}$-messages-per-key cap where AES hardware exists, or ChaCha20-Poly1305 where it does not. If you must keep CBC, negotiate RFC 7366 Encrypt-then-MAC with an independent MAC key and a constant-time verify performed first. Never ship SSL 3.0 or non-RFC-7366 CBC. That is the entire checklist, because the lesson is a single sentence.

Detection is cheap enough to wire into a pipeline, and you should, because content-difference oracles need no timing rig to find [@merget2019].

Point an open-source padding-oracle scanner at your own hosts. Craig Young's `padcheck` and the TLS-Attacker project's `TLS-Padding-Oracles` both probe for the invalid-padding-versus-invalid-MAC content differences that Zombie POODLE and GOLDENDOODLE exploit, and they run without a precise timing setup [@padcheck] [@tls_padding_oracles]. A clean result on a CBC endpoint is reassuring; any distinguishable response is a reportable finding, not a tuning opportunity.

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

11. Misconceptions, Named and Corrected

The padding oracle survives mostly because a handful of confident, wrong sentences keep getting said in design meetings. Here they are, corrected.

The strength of AES is irrelevant to this attack, because the key is never attacked. A padding oracle recovers plaintext from the receiver's error handling -- a distinguishable answer to "was the padding valid?" -- combined with CBC's malleability [@vaudenay2002]. The ASP.NET break recovered authentication tickets and `web.config` with AES-256 fully intact [@rizzo_duong_woot2010]. "The cipher is strong" and "the system is secure" are different claims. No. The same accept/reject bit re-emerges through the next-quietest channel. Once the error message was unified, it leaked through coarse timing (Canvel et al., 2003) and then through statistical timing under unified errors (Lucky Thirteen, 2013), and through unchecked structure entirely (POODLE, 2014) [@canvel2003] [@lucky13_2013] [@poodle_writeup]. Silencing one channel just moves the leak; only removing the precondition closes it. No -- and the overstatement matters. Krawczyk proved MAC-then-encrypt conditionally secure for CBC and counter mode, so the real-world breaks are implementation, side-channel, and underspecified-padding failures, not refutations of a theorem [@krawczyk2001]. What is true is that MtE is *fragile in practice*: it leaves unauthenticated ciphertext reaching the parser, so constant-time MtE is a fight against the construction. The fix is to change the order, not to declare a theorem false. It is a padding oracle; the downgrade is only the enabler that forces a client onto vulnerable SSL 3.0, whose pad bytes are unchecked by specification [@poodle_writeup] [@rfc6101]. The proof is TLS-POODLE (CVE-2014-8730), the same oracle against TLS stacks that copied the lax check, with no downgrade at all [@cve_2014_8730]. Frame POODLE as a padding oracle first, a downgrade second. No. Bleichenbacher (1998) is an RSA PKCS #1 v1.5 oracle -- a different primitive with different arithmetic [@bleichenbacher1998]. Vaudenay (2002) is the first *CBC* instance [@vaudenay2002]. Bleichenbacher is the ancestor "in spirit," because he first showed that a structural validity verdict is a decryption oracle, but calling his attack a CBC padding oracle confuses two branches of the family tree. No. AES-GCM and ChaCha20-Poly1305 are counter-mode stream constructions with no block padding, and they verify the authentication tag before releasing any plaintext, so the Vaudenay atom has no surface to act on [@rfc8439]. GCM's own hazard is nonce reuse, which is a different problem -- the "forbidden attack" -- not a padding oracle [@bock_nonce_woot2016]. Only if authenticity is checked *first* and the unpadding is *also* constant-time. A constant-time compare on a MAC you verify *after* decrypting still leaves the padding check reachable, which is the whole class -- and a hand-written fast path can reintroduce the oracle anyway, as CVE-2016-2107 did, through a missing length check observable as a distinguishable alert rather than a timing leak [@cve_2016_2107]. The safe pattern is verify-then-decrypt, or an AEAD that gives you no other option.

Every correction points at the same root: the padding was never the bug. Time to say the sentence the whole article was built to earn.

Decrypt, Then Confess

Return to that ASP.NET server in September 2010. AES-256 intact. The key never touched, never even approached. And the plaintext -- authentication tickets, web.config, the site's master secrets -- gone, one byte at a time, because the server answered a question it should never have been asked before it authenticated the ciphertext [@rizzo_duong_woot2010].

Line up the catalog and the shape is unmistakable. Bleichenbacher, Vaudenay, Canvel, ASP.NET, Lucky Thirteen, POODLE, CVE-2016-2107, Zombie POODLE: in every case the cipher did exactly what it promised, and the variable was always the order of operations, leaking through a quieter channel each time it was silenced. A loud error became coarse timing became statistical timing became unchecked structure became a fix that re-created its own oracle. Five generations chased the bit; the bit kept escaping, because the precondition -- unauthenticated, malleable ciphertext reaching a padding check -- was never removed.

The resolution the field finally deployed is a single move: verify authenticity first. Encrypt-then-MAC proves it -- IND-CCA plus integrity of ciphertexts, the strongest of the three generic compositions, published two years before Vaudenay's attack [@bellare_namprempre2000]. AEAD ships it as one primitive with no knob to misset, and TLS 1.3 makes it the only option a conformant stack can express [@rfc8446].

This mirrors the running lesson of the series: Part 1's IND-CCA2 adversary is not a chalkboard abstraction but the exact adversary that walked out of that ASP.NET server, and Part 5's warning that confidentiality is not integrity is precisely the gap a padding oracle drives through.

When a ciphertext you did not create arrives, what does your receiver reveal about it before it has proven the ciphertext authentic? Encrypt-then-MAC and AEAD are the discipline of making the answer nothing.

Carry that one question into every protocol you design or review. Drop Lucky Thirteen onto it, drop POODLE onto it, drop the next application-layer JWE oracle onto it: each is a non-empty answer, and the fix is always the same shape. The cipher was never the weak link, and no future cipher will be. That is why this is Part 6 of a field guide to protocol design, not a chapter on block ciphers.

Secure Against Whom? The Security Definitions Every Protocol Designer Needs

noreply@paragmali.com (Parag Mali) — Sat, 04 Jul 2026 15:17:50 GMT

A security definition is a contract with two clauses: a **goal** (what the adversary must fail to do) bound to an **adversary model** (what the adversary is allowed to do). Nothing is ever "secure" in the abstract, only secure *relative to that contract*. Most real-world breaks are not weak math. They are a construction that met a *weaker* target than its deployment's adversary demanded: Bleichenbacher and POODLE handed attackers a decryption oracle, AES-GCM nonce reuse handed them a repeated nonce, invisible salamanders handed them a second key. This guide builds the vocabulary generation by generation, from IND-CPA and IND-CCA2 through EUF-CMA, SUF-CMA, AEAD, and committing encryption, plus the two proof settings (random oracle versus standard model) and the reduction that ties goals to hard problems. The operational lesson is one habit: **state your deployment's adversary model first, pick the matching target second, and choose the primitive last.**

1. The Primitive Was Fine

In 1998, Daniel Bleichenbacher did not break RSA. Factoring stayed hard, the keys stayed secret, and the math was exactly as sound the day after his attack as the day before. Yet with about a million carefully malformed messages, he could recover the secrets of an SSL session, because the server, trying to be helpful, answered one question every time it rejected a ciphertext: was the padding valid? [@bleichenbacher1998]

That single leaked bit is a decryption oracle. RSA as used in SSL wrapped the session key in PKCS#1 v1.5 padding, and a server that reports "bad padding" differently from "bad key" tells the attacker, ciphertext by ciphertext, whether a chosen value decrypts into the padded structure. Bleichenbacher showed that roughly $2^{20}$ adaptive queries turn that trickle into the full plaintext [@bleichenbacher1998].

The tempting reading is "an RSA bug." It is not. Nineteen years later, in 2017, researchers pointed the identical attack at modern TLS stacks and load balancers, and it still worked against products from several major vendors [@robot_2018] [@robot_site]. They called it ROBOT, the Return Of Bleichenbacher's Oracle Threat. The industry had spent two decades patching individual symptoms, tightening one timing difference here, one error message there, without ever changing what was actually wrong.

Note: ROBOT is the clearest evidence in this article that the failure is structural, not incidental. Every point fix removed one instance of the oracle. None of them changed the fact that PKCS#1 v1.5 encryption was deployed where an attacker can observe decryption behavior, and it was never built to survive that. You cannot patch your way out of the wrong security target. You have to change the target [@robot_2018].

So what, exactly, does "secure" mean, and secure against whom? That question is not rhetorical. It is the entire discipline. A construction is secure only against a specified adversary trying to achieve a specified goal, and the moment the deployment hands that adversary a capability the specification never modeled, the guarantee evaporates no matter how sound the underlying math.

Key idea: A security definition is a contract with two clauses: a goal (what the adversary must fail to achieve) bound to an adversary model (what the adversary is allowed to do). "Secure" without a named adversary model is not a weak claim. It is not a claim at all.

This guide makes you fluent in that contract. We build the vocabulary the way the field built it, one generation at a time, and prove the thesis with evidence: a catalog of named, dated breaks in which a provably fine primitive sank a real protocol because the environment granted an adversary the proof never covered. Bleichenbacher and ROBOT are the first entry.

By the end you will read any construction as goal plus adversary model plus proof setting, and see why that one habit would have prevented the entire catalog. For the deployment story of how Windows TLS stacks rotated ciphers over twenty years, see SChannel and the twenty-year algorithm.

A construction is never secure in the abstract. It is secure only relative to a named adversary model.

To see why a correct primitive was not enough, we have to go back to a time when "secure" had no definition at all.

2. Before "Secure" Meant Anything

For most of history, a cipher was "secure" because nobody important had broken it yet. That is survivorship bias wearing the costume of a guarantee. It tells you nothing about the attacks nobody has tried, and it cannot distinguish a strong design from one that simply has not attracted a competent adversary. Every classical cipher, from simple substitution to Vigenère to Enigma, was "secure" by this standard right up until the morning it was not.

The one durable gain from that era is Kerckhoffs's principle: assume the adversary knows every detail of your algorithm, and put all the secrecy in the key.Auguste Kerckhoffs stated this in 1883 [@kerckhoffs1883]. It is why "security through obscurity" is a slur, and why modern designs publish their algorithms and keep only keys secret. But note what it still does not supply: a definition of what the attacker must fail to do. It is a rule about where to hide the secret, not a definition of success. It leaves "secure" undefined.

That gap survived the single most important idea in the field's modern history. In 1976, Whitfield Diffie and Martin Hellman opened public-key cryptography, showing that two strangers could agree on a secret over a channel an eavesdropper fully controls, and sketching digital signatures along the way [@dh1976]. It was a genuine discontinuity. But it delivered mechanisms, not a definition of what an attacker must fail to achieve. "Secure" still meant "we tried and could not break it."

You cannot prove a scheme meets a goal you never wrote down. So the founding question of modern cryptography is not "how do we encrypt?" It is "what must the attacker fail at, and what is the attacker allowed to do while failing?" Shafi Goldwasser and Silvio Micali answered it in 1982 and 1984 with semantic security: a ciphertext must leak nothing computationally useful about its plaintext, not even a single predicate, to any efficient adversary who already knows partial information [@gm1984] [@gm1982stoc].

They also gave an equivalent, more usable form, indistinguishability, which we meet as IND-CPA in the next section. The award committee agreed the shift mattered: Goldwasser and Micali received the 2012 Turing Award for it [@turing2012].

Two words in that definition carry enormous weight. "Efficient" means the adversary runs in probabilistic polynomial time; we do not defend against an attacker with unbounded computation, because for public-key cryptography that is hopeless. "Negligible" means the adversary's edge over guessing shrinks faster than any inverse polynomial in the security parameter.Probabilistic polynomial time (PPT) and negligible functions are the two dials of computational security. A function is negligible if it eventually falls below $1/n^c$ for every constant $c$. Together they let us say "no realistic adversary wins by more than a vanishing margin" instead of the impossible "no adversary ever wins." Security stops being a binary property of an algorithm and becomes a statement about a game between a challenger and a bounded adversary.

This article numbers the generations of definitions by *idea*, not by calendar. Confidentiality against a passive attacker comes first, then against an active one, then integrity, then their union, then commitment. The field did not invent them in that order: unforgeability for signatures (1988) was defined *before* adaptive chosen-ciphertext security (1991). Where the dates cross, we flag it. The dependency that matters here is conceptual, not temporal.

Before we build the first game, there is one loose end. An airtight, provably unbreakable definition of secrecy was already on the books, and it predated all of this by decades. Why did the field not simply use Shannon's?

3. The Perfect Cipher We Cannot Afford

Claude Shannon gave cryptography a mathematically perfect definition of secrecy in 1949, and the one-time pad achieves it, unconditionally, forever [@shannon1949]. Not "we think it is hard to break." Provably impossible to break, even against an adversary with infinite computing power.

An encryption scheme has perfect secrecy if the ciphertext is statistically independent of the plaintext: observing the ciphertext leaves the adversary's probability distribution over possible messages exactly where it started. Formally, $\Pr[M = m \mid C = c] = \Pr[M = m]$ for every message and ciphertext. No amount of computation helps, because the information is simply not present in the ciphertext.

The one-time pad reaches this bar with almost embarrassing simplicity. Take a key $k$ that is uniformly random and as long as the message $m$, and send $c = m \oplus k$. Because each key bit is a fresh coin flip, every plaintext of that length is an equally plausible explanation of the ciphertext, so the ciphertext reveals nothing. Decryption is the same XOR again.

So why is the internet not built on one-time pads? Shannon proved the catch in the same paper: any perfectly secret cipher needs at least as much key entropy as message entropy, $H(K) \ge H(M)$ [@shannon1949]. The key must be as long as everything you will ever send, and it does nothing to solve the problem of getting that key to the other party in the first place. Two strangers who have never met cannot pre-share gigabytes of secret pad, which is exactly the situation every TLS handshake faces.

There are two more ceilings, and they matter for the rest of this guide. The first is that the perfection is contingent on the pad being used once. Reuse a pad across two messages and $c_1 \oplus c_2 = m_1 \oplus m_2$, which leaks the XOR of the plaintexts and, with a little language structure, both messages.This is not hypothetical. The VENONA project decrypted Soviet cables for years precisely because the Soviets reused one-time-pad key material under wartime production pressure [@venona]. "Never reuse the key" is a lesson written in decades of intercepted traffic, and it returns almost verbatim in the AES-GCM nonce story later.

The second ceiling is quieter and more important for our thesis. The one-time pad offers zero integrity. It is maximally malleable: flip any bit of the ciphertext and you flip exactly the corresponding bit of the plaintext, and the receiver has no way to notice. Perfect secrecy says nothing whatsoever about whether a message arrived unmodified.

Note: This is one of the most expensive misconceptions in applied cryptography, so meet it early. Confidentiality (nobody can read it) and integrity (nobody can change it undetected) are different goals. A scheme can have perfect confidentiality and no integrity at all, as the one-time pad demonstrates. Assuming encryption implies integrity is the root cause of an entire class of breaks we catalog in Generation 4.

The way out of the key-length ceiling is to relax the adversary. Shannon's model grants the attacker unlimited computation. If we instead demand only that a computationally bounded adversary fail, we can hope for short keys, public keys, and eventually integrity, provided we state precisely what "fail" means. That relaxation is the whole computational project the previous section set up.

The relaxation bites immediately, and its first bite is instructive. Consider deterministic "textbook" RSA, where a message always encrypts to the same ciphertext under a given public key. An adversary who suspects the plaintext is one of two values does not need to break RSA at all. The public key lets anyone encrypt, so the attacker encrypts both candidates and compares them to the challenge ciphertext. Whichever matches is the answer.

Goldwasser and Micali turned this into a theorem: no deterministic public-key scheme can be semantically secure [@gm1984]. Randomization is not good hygiene; it is mandatory, a consequence of the definition itself. That randomness has to come from somewhere trustworthy, its own deep subject that a later part of this series takes up.

With the passive adversary finally pinned down as a game, we can write the first modern definition precisely, and then watch an attacker walk straight through its one blind spot.

4. Five Generations, One Recurring Story

The next four decades of cryptography follow one pattern so regularly that you can predict the next entry. A definition fixes a goal and an adversary model. A deployment then hands the attacker a capability the model never granted, whether a decryption oracle, a repeated nonce, or a second valid key. A named, dated break follows. And the field responds by writing a stronger definition that pulls the new capability inside the game. Watch for that shape. By Generation 3 you will feel it coming.

timeline title From perfect secrecy to committing encryption 1949 : Shannon perfect secrecy, unbounded adversary 1976 : Diffie-Hellman public-key crypto, no definition of success 1984 : Goldwasser-Micali semantic security and IND-CPA 1988 : Goldwasser-Micali-Rivest unforgeability, EUF-CMA 1990 to 1991 : Naor-Yung CCA1, Rackoff-Simon CCA2, Dolev-Dwork-Naor non-malleability 1993 : Bellare-Rogaway random oracle model 1998 : Bleichenbacher break, relations map, Cramer-Shoup, ROM uninstantiability 2000 to 2006 : Bellare-Namprempre AE, Rogaway AEAD, SIV nonce-misuse resistance 2018 to 2021 : Invisible salamanders and partitioning oracles, committing AE 2024 : ML-KEM in FIPS 203, NIST Accordion effort

Generation 1: confidentiality against a passive adversary (IND-CPA, 1984)

Goldwasser and Micali's indistinguishability game is the founding contract of modern cryptography, and it is worth stating exactly.

A scheme is IND-CPA secure if no efficient adversary can tell which of two self-chosen, equal-length messages was encrypted, even while free to encrypt anything else it likes. The adversary submits $m_0$ and $m_1$; the challenger flips a secret bit $b$ and returns the challenge $\mathrm{Enc}(m_b)$; the adversary outputs a guess $b'$. Its advantage is $\lvert \Pr[b' = b] - \tfrac{1}{2} \rvert$, and security means that advantage stays negligible. This is the indistinguishability form of semantic security.

In the public-key setting the adversary already holds the public key, so its chosen-plaintext power is free: it can encrypt anything it wants. That is exactly what dooms determinism. If encryption is a plain function, the adversary encrypts $m_0$ itself and checks whether the result equals the challenge.

{` // A toy "deterministic" encryption: the same message always maps to the same ciphertext. function encryptDeterministic(pk, m) { // stand-in for textbook RSA: a fixed, public, invertible transform return "CT[" + pk + ":" + m + "]"; }

// The IND-CPA adversary, given only the public key and the challenge ciphertext. function adversary(pk, challenge) { const m0 = "attack at dawn"; const m1 = "retreat at dusk"; // The public key lets the adversary encrypt candidates itself. const guessForM0 = encryptDeterministic(pk, m0); // Re-encrypt m0 and compare. No key recovery, no math broken. return (challenge === guessForM0) ? "m0" : "m1"; }

const pk = "PUBLIC-KEY"; const challengerSecretlyChose = "attack at dawn"; // this is m0 const challenge = encryptDeterministic(pk, challengerSecretlyChose); console.log("Adversary guesses:", adversary(pk, challenge)); console.log("Advantage over guessing: 1/2, the maximum. Deterministic PKE cannot be IND-CPA."); `}

The adversary wins every time, with the maximal advantage of one half. The fix, forced by the definition rather than by taste, is randomization: a good scheme encrypts the same message to freshly random-looking ciphertexts, so re-encrypting a guess tells the attacker nothing.

IND-CPA is the right target for exactly one adversary: a passive one, who watches ciphertexts go by but never learns how the receiver reacts to them. That is its blind spot. Real servers decrypt attacker-supplied ciphertexts and do something observable: return an error, take a branch, spend measurable time. Each reaction is a decryption oracle the IND-CPA game never handed out.

Bleichenbacher's 1998 attack, from the opening of this article, is precisely this failure: an IND-CPA-grade target deployed where the adversary can watch decryption behavior [@bleichenbacher1998]. To survive that attacker, the definition itself must give the adversary a decryption oracle.

Generation 2: confidentiality against an active adversary (IND-CCA1, IND-CCA2, non-malleability, 1990 to 1998)

The strengthening arrived in two steps. Naor and Yung (1990) gave the adversary a decryption oracle it may query only before seeing the challenge, the "lunchtime attack" or CCA1, and built the first provably chosen-ciphertext-secure scheme using double encryption plus a zero-knowledge proof that both ciphertexts hold the same plaintext [@ny1990]. A year later Rackoff and Simon (1991) removed the timing restriction: the oracle is available before and after the challenge, forbidding only a query on the challenge ciphertext itself. That is IND-CCA2, still the gold-standard confidentiality target today [@rs1991].

IND-CCA2 is the IND-CPA game plus a decryption oracle the adversary may call adaptively both before and after receiving the challenge $c^{*}$, with the single restriction that it may not ask for the decryption of $c^{*}$ itself. A scheme that meets it withstands exactly the padding-oracle and reaction-attack environments that sink IND-CPA-only deployments. sequenceDiagram participant A as Adversary participant C as Challenger A->>C: Two equal-length messages m0 and m1 C->>C: Flip secret bit b, encrypt the chosen message C->>A: Challenge ciphertext c-star A-->>C: IND-CCA2 only, decrypt any ciphertext except c-star C-->>A: The corresponding plaintext A->>C: Final guess b-prime Note over A,C: Advantage measures how far a correct guess beats one half

Dolev, Dwork, and Naor (1991) added an orthogonal axis that turns out to matter just as much.

A scheme is non-malleable if, given a ciphertext of some message $m$, no efficient adversary can produce a ciphertext of a *meaningfully related* message such as $m+1$ or $2m$. Indistinguishability says the adversary learns nothing from a ciphertext; non-malleability says the adversary cannot *transform* it into a ciphertext of a related plaintext, which is a distinct, active threat such as raising a sealed bid by one dollar [@ddn1991].

By 1998 the notions had multiplied into a zoo, and Bellare, Desai, Pointcheval, and Rogaway mapped it. They proved every implication and separation among the goals of indistinguishability and non-malleability crossed with the attacks CPA, CCA1, and CCA2, and the headline result is that IND-CCA2 and non-malleability under CCA2 are the same property [@bdpr1998]. That equivalence is the reward of definition-first thinking: hit the single target IND-CCA2 and you get non-malleability with no separate proof.

Notice the chronology. Rackoff and Simon defined the adaptive oracle in 1991, seven years before Bleichenbacher showed a real SSL server being that oracle. The definition did not chase the break; it predicted the entire class of break. What was missing in 1998 was not the theory but the discipline of choosing the target the deployment demanded. And yet IND-CCA2, for all its strength, guarantees only confidentiality. It promises nothing about whether a message you can read arrived unmodified, or whether an attacker who cannot read it can still inject one the receiver will accept.

Generation 3: integrity as a first-class goal (EUF-CMA and SUF-CMA, 1988 onward)

Here the calendar folds back. Goldwasser, Micali, and Rivest defined unforgeability in 1988, three years before adaptive chosen-ciphertext security, by carrying the game-based, reduction-oriented definition style from secrecy to authenticity: the same challenger, oracle access, and negligible success bound, now applied to a forgery game rather than to indistinguishability [@gmr1988].

Give the adversary the verification key and a signing oracle it may query on any messages it chooses. The adversary wins if it outputs a valid signature on a message it never asked the oracle to sign. A signature or MAC scheme is EUF-CMA secure if every efficient adversary wins with only negligible probability. This is the target behind HMAC, RSA-PSS, ECDSA, and Ed25519.

There is a strictly stronger sibling that the deployment reality of the decade made important.

SUF-CMA changes only the winning condition: the adversary wins if it produces any valid message-signature *pair* the oracle never produced, including a brand-new signature on a message that was already signed. SUF-CMA therefore forbids the signature malleability that EUF-CMA tolerates. Every SUF-CMA scheme is EUF-CMA, but not the reverse [@katzlindell].

Why does the gap between them matter? Because EUF-CMA lets a third party take a valid signature and maul it into a different valid signature on the same message. Wherever a protocol treats a signature or ciphertext as a unique identifier, that malleability bites. Early Bitcoin is the textbook case: an attacker could re-encode an ECDSA signature, changing a transaction's identifier without invalidating it, which disrupted systems that assumed the identifier was fixed. MtGox famously halted withdrawals citing malleability, though the same analysis found it did not actually account for the exchange's lost funds [@decker2014]. That is exactly the attack SUF-CMA forbids and EUF-CMA permits.

A subtler cousin is verifying a signature without binding its context (which key, which algorithm, which audience), which invites cross-protocol confusion. For a real incident where a stolen signing key met permissive validation, see how Storm-0558 turned one signing key into forged tokens.

A MAC or signature protects a token. It is not, by itself, a secure channel. For that we need confidentiality and integrity together, composed in a way we can prove correct.

Generation 4: authenticated encryption (AE and AEAD, 2000 to 2006)

Practitioners had been bolting encryption and MACs together by instinct, and instinct chose badly. Bellare and Namprempre (2000) settled the matter with definitions and proofs [@bn2000].

INT-PTXT (plaintext integrity) means the adversary cannot force decryption to accept a plaintext that was never legitimately encrypted. INT-CTXT (ciphertext integrity), strictly stronger, means the adversary cannot produce *any* valid ciphertext the encryptor never output. INT-CTXT is what real channels want, because it rejects forged ciphertexts before they are ever decrypted.

Their verdict on the three ways to glue encryption to a MAC is one of the most consequential engineering results in the field: Encrypt-then-MAC (encrypt, then authenticate the ciphertext) generically delivers IND-CCA together with INT-CTXT, while MAC-then-Encrypt and Encrypt-and-MAC do not [@bn2000]. Order is not a detail. It is the difference between a secure channel and a broken one.

AEAD is a single combined target: confidentiality (IND-CPA) plus ciphertext integrity (INT-CTXT) over a nonce-based interface that takes a key, a nonce, associated data, and a message, and returns a ciphertext and a tag. The associated data (packet headers, sequence numbers, routing context) is authenticated but not encrypted. Rogaway named and formalized it in 2002, and RFC 5116 turned it into the deployable interface every modern channel uses.

Rogaway (2002) added the associated-data interface [@rogaway2002], McGrew's RFC 5116 (2008) standardized it as the API protocol designers actually call [@rfc5116], and Rogaway and Shrimpton (2006) defined the fallback for when nonces cannot be trusted [@rs2006siv].

A nonce-misuse-resistant scheme degrades gracefully when a nonce repeats: instead of collapsing, it leaks only whether two (nonce, associated data, message) triples were identical. The SIV construction achieves this by deriving the tag from the plaintext first, then using that tag as the encryption nonce. This is the guarantee behind AES-GCM-SIV.

Now the breaks, and they line up with the theory exactly. TLS chose MAC-then-Encrypt with CBC, the very order Bellare and Namprempre flagged, and decrypted before verifying. That handed attackers a padding-and-timing decryption oracle twice: Lucky Thirteen (2013) recovered plaintext from tiny timing differences in MAC and padding checks [@lucky13_2013] [@lucky13_site], and POODLE (2014) forced a downgrade to SSL 3.0, whose CBC padding is not checkably authenticated, then peeled secrets off byte by byte [@poodle_cve]. Both are wrong-composition-order failures wearing different clothes.

The second Gen-4 landmine is the nonce contract, and it is the most destructive single mistake in applied cryptography.

Note: Reuse one (key, nonce) pair in AES-GCM and you do not lose a little security, you lose all of it. GHASH evaluates a polynomial whose coefficients are the ciphertext blocks at the secret authentication key $H$, so two messages under one nonce cancel the block-cipher mask and leave a polynomial equation in $H$. The attacker factors that polynomial to recover $H$ and can then forge a valid tag on any message. This is Joux's "forbidden attack," a universal forgery rather than a slow leak [@joux_gcm]. VM clones, snapshot rollbacks, and stateless senders are the usual culprits.

Even without reuse, GCM has a hard ceiling.AES-GCM's standard nonce is 96 bits. With random nonces, birthday collisions on that nonce cap a single key at about $2^{32}$ messages, the bound NIST SP 800-38D fixes in section 8.3 to keep the collision probability negligible. A separate limit, the 32-bit block counter that the 96-bit nonce leaves inside the 128-bit block, caps any one message at about $2^{32}$ blocks (roughly 64 GiB). NIST warns that exceeding either cap can compromise both confidentiality and integrity [@sp800_38d]. The proof was always conditioned on unique nonces and a bounded message count; the environment routinely violates both.

Which surfaces the deepest omission of all. AE and AEAD guarantee that a ciphertext is unforgeable and hides its plaintext. They never required it to commit to the key that produced it.

Generation 5: committing encryption, binding a ciphertext to its key (2018 to 2021, still open)

An AEAD scheme is key-committing if a single ciphertext cannot be made to decrypt validly under two different keys. Stronger notions bind more of the input: context commitment binds the key, nonce, and associated data, while the strongest level also binds the message. Bellare and Hoang grade these from CMT-1 (key only) up to CMT-4, which commits to the entire input tuple of key, nonce, associated data, and message. It is a binding property, not a privacy property, and standard AEAD never required it.

The break that named the goal is vivid. For AES-GCM you can craft one ciphertext that decrypts to two different, meaningful plaintexts under two chosen keys, because its GHASH tag can be made to collide across keys.Dodis, Grubbs, Ristenpart, and Woodage called the hidden second message an "invisible salamander," after a test image they smuggled past Facebook's abuse-reporting checks. The playful name marks a serious result: a reported ciphertext could be made to "say" different things to sender, receiver, and moderator. That broke Facebook's encrypted-message franking, the mechanism that lets a recipient report abuse in a way a moderator can verify [@salamanders2018].

Three years later the same missing property was weaponized for a different goal. Len, Grubbs, and Ristenpart showed that a single ciphertext valid under many keys turns password guessing into a binary search: each query rules out half the candidate key space at once. These partitioning oracles sped online attacks against Shadowsocks proxies and reached into key-management and end-to-end-encrypted settings [@partitioning2021]. Bellare and Hoang formalized the graded commitment hierarchy and proved that committing to the key alone (CMT-1) does not imply committing to the full context (CMT-4), so partial fixes leave a real gap [@bh2022]; Menda and colleagues then demonstrated concrete context-discovery and commitment attacks that exploit that gap in real settings [@menda2023].

Generation 5 is not superseded. It is the live frontier, being written into standards right now, and we return to it in the state of the art.

That is five turns of one wheel. It is worth seeing the wheel itself.

flowchart TD A["A definition fixes a goal and an adversary model"] --> B["A deployment hands the attacker a capability outside that model"] B --> C{"Does the attack win inside the old game?"} C -->|"No, the game never granted that capability"| D["A named, dated break follows in the wild"] D --> E["The field writes a stronger definition that grants the capability"] E --> A

Key idea: Every arrow in that chain has the same shape. A definition names a goal and an adversary model; a deployment grants the attacker a capability outside that model; a dated break follows; a stronger definition absorbs the capability. Learning the definitions is learning to spot the next missing capability before an attacker does.

Two tables make the pattern concrete. The first is the failure catalog, where each row is a construction that met a weaker target than its environment demanded.

Break	Year	Construction	Capability the model ignored	Missing target	Lesson
Bleichenbacher, then ROBOT	1998, 2017	RSA PKCS#1 v1.5 encryption	Decryption and padding oracle	IND-CCA2	You cannot patch out a missing target
Lucky Thirteen	2013	TLS CBC, MAC-then-Encrypt	Timing decryption oracle	AEAD (Encrypt-then-MAC)	Composition order is provable, not a matter of taste
POODLE	2014	SSL 3.0 CBC, MAC-then-Encrypt	Padding oracle via forced downgrade	AEAD / IND-CCA2	The adversary model must include downgrade
AES-GCM nonce reuse	ongoing	AES-GCM AEAD	Repeated (key, nonce) pair	Nonce-misuse resistance	Unique nonces are a load-bearing assumption
Invisible salamanders	2018	AES-GCM message franking	A second valid key	Key commitment (CMT)	AEAD never promised one key per ciphertext
Partitioning oracles	2021	Non-committing AEAD	One ciphertext valid under many keys	Key commitment (CMT)	Missing commitment enables key and password search

The second table lays out the targets themselves, in order of increasing strength, so you can name any construction as a goal bound to an adversary model.

Target	Goal	Adversary model	Strength relation	Deployed instance
IND-CPA	Confidentiality	Passive, chosen-plaintext	Weakest confidentiality	Building block only
IND-CCA2	Confidentiality	Active, adaptive decryption oracle	Implies IND-CPA, equals NM-CCA2	ML-KEM, RSA-OAEP, Cramer-Shoup (standard-model reference)
EUF-CMA	Authenticity	Adaptive chosen-message	Base authenticity	HMAC, ECDSA, Ed25519
SUF-CMA	Authenticity	Adaptive chosen-message	Strictly stronger than EUF-CMA	Ed25519, HMAC
AEAD	Confidentiality and integrity	Active, nonce-respecting	Combines IND-CPA and INT-CTXT	AES-GCM, ChaCha20-Poly1305
Committing AE	Binds ciphertext to key and context	Active, multi-key	Strictly stronger than AEAD	AWS Encryption SDK, Accordion (pending)

Five times we have said a scheme "meets" a target. It is time to say what meets actually means, and why you should believe it.

5. What "Provably Secure" Actually Proves

We have been defining games. A game tells you what it means to win. It does not tell you that nobody can. So how do you prove a negative, that no efficient adversary wins, without enumerating every possible attack? The answer is the single idea that unifies everything in this guide: a proof by reduction.

To prove a scheme meets a target, assume some problem is hard (integer factoring, the decisional Diffie-Hellman problem, Module-LWE) or that a lower-level primitive is secure. Then exhibit an efficient algorithm, the reduction, that turns *any* adversary who wins the security game into a solver for that hard problem. If the problem really is hard, no such solver exists, so no such adversary exists either. Security becomes a conditional theorem: break the scheme and you have broken the assumption.

Read that structure carefully, because it is doing something subtle. It never claims the scheme is unbreakable. It claims something you can actually establish: that breaking the scheme is at least as hard as a problem the world's cryptanalysts have failed to crack for decades. The proof relocates all the risk onto one clearly labeled assumption, where everyone can study it. The hard problems themselves (factoring, discrete logarithms, lattice problems) are the subject of later parts of this series; here they are simply the anchors a reduction reaches for.

flowchart LR A["Efficient adversary A wins the security game"] --> R["Reduction R runs A as a black box"] R --> S["R becomes an algorithm that solves the hard problem"] S --> X["But the problem is assumed hard, so no such solver exists"] X --> Z["Therefore no efficient adversary A can exist"]

This is the only known way to make "secure" falsifiable, and it composes, which is what makes it practical. Bellare and Namprempre's result that IND-CPA plus INT-CTXT implies IND-CCA is itself a reduction you can bolt onto others: prove your encryption IND-CPA and your MAC strongly unforgeable, glue them Encrypt-then-MAC, and the channel's IND-CCA security follows with no fresh from-scratch proof [@bn2000] [@bonehshoup]. Large guarantees get assembled from small proven parts.

A security proof does not promise that nobody can break the scheme. It promises that breaking it is as hard as a problem we have collectively failed to solve for decades.

But a proof is only as good as two things: the assumption it rests on, and how tightly it reduces.

A reduction is tight if the solver it builds is almost as effective as the adversary it consumes, running in similar time with similar success probability. It is loose if it loses a factor, for instance a multiple of the number of queries or users. A reduction that loses a factor $L$ means a scheme advertised at $k$-bit security actually delivers only about $k - \log_2 L$ bits at the chosen parameters. Looseness is not academic; you pay it back in larger keys and slower handshakes.

Neal Koblitz and Alfred Menezes pressed exactly this point in their "Another Look" critique: many published reductions are loose, or rest on bespoke, barely-studied assumptions, and calling a scheme "provably secure" invites readers to hear "unbreakable" when the honest claim is much narrower [@km2007]. We take up their argument in full when we reach the limits. For now it is enough to know that the tightness of a proof is an operational number, not a footnote.

Key idea: "Provably secure" means conditionally secure: secure relative to a named hardness assumption and a named adversary model, and only as tightly as the reduction allows. It converts a vague hope into a precise, falsifiable claim whose single point of failure is written on the label. That is far more than folklore offers, and far less than "unbreakable."

This method is not a museum piece. It is the machine still producing the definitions that shipped last year. Here is what it built between 2024 and 2026.

6. The Definitions That Shipped: 2024 to 2026

A quantum-resistant standard published in 2024 is built directly on the 1984, 1991, and 1999 sequence: an IND-CPA scheme, upgraded to IND-CCA2, by a transform invented to plumb exactly that gap.

On August 13, 2024, NIST published FIPS 203, standardizing ML-KEM, a key-encapsulation mechanism whose security rests on the hardness of Module-LWE and which is, in the standard's own words, believed to be secure even against adversaries who possess a quantum computer [@fips203].

A KEM is the modern shape of public-key confidentiality. Rather than encrypting a chosen message, encapsulation generates a fresh random shared secret together with a ciphertext that carries it; decapsulation recovers the secret from the ciphertext using the private key. The shared secret then keys a symmetric AEAD channel. The target you want from a KEM is IND-CCA2, because an active network attacker can submit chosen ciphertexts to decapsulation.

ML-KEM reaches IND-CCA2 the way Fujisaki-Okamoto transforms do: start from an IND-CPA lattice scheme, then make decapsulation recompute and compare. It derives the encryption randomness deterministically from the message, re-encrypts on the way in, and on any ciphertext that does not re-encrypt exactly returns a pseudorandom key instead of the real one (implicit rejection), so a decapsulation failure is invisible to the caller [@fips203] [@fo1999]. That single move strips out the malleability an adaptive attacker would exploit, turning a passive-secure scheme into an active-secure one.

The transform's soundness in both the random-oracle and quantum-random-oracle settings is the subject of a careful modular analysis by Hofheinz, Hövelmanns, and Kiltz, which also shows the quantum bound is not tight [@hhk2017].The Quantum Random Oracle Model (QROM) lets the adversary query the idealized hash in superposition, which is what a real quantum attacker holding the hash's public code could do. Proving the FO transform secure in the QROM is harder than in the classical setting and currently costs a looser bound. The full story belongs to a later post-quantum installment of this series.

The price of the strong target is not CPU, it is bandwidth. Google reports that an ML-KEM key exchange transmits about 1 KB per peer against 32 bytes for X25519, an over-thirty-fold increase that splits the TLS ClientHello across packets and adds roughly 4 percent to median desktop handshake latency [@chrome2024].

That cost is being paid at scale regardless. Cloudflare reported that nearly 2 percent of all TLS 1.3 connections already used post-quantum key exchange in early 2024 [@cloudflare2024], Signal's PQXDH was the first large-scale deployment of post-quantum key establishment in messaging [@signal_pqxdh], and Apple's iMessage PQ3 layers ongoing ML-KEM rekeying on top for what it calls Level 3 security [@apple_pq3].

ML-KEM ships in *hybrid* mode, combining a classical key exchange such as X25519 with the post-quantum one so a break of either component alone is survivable. The driver is "harvest now, decrypt later": an adversary recording encrypted traffic today could decrypt it once a quantum computer arrives, so confidentiality that must outlive the next decade needs the post-quantum target now. The Windows-side rollout is covered in [the thirty-year migration that ships in a pip install](/blog/the-thirty-year-migration-ships-in-a-pip-install-how-post-qu) and [post-quantum cryptography on Windows](/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati).

The same AEAD target ships in three deployed instances that differ not in what they guarantee but in the deployment reality they suit. All three hit AEAD; the discriminating axis is how they behave when a nonce repeats [@rfc8439] [@rfc8452] [@sp800_38d].

Property	AES-GCM	ChaCha20-Poly1305	AES-GCM-SIV
Target met	AEAD (IND-CPA + INT-CTXT)	AEAD	AEAD plus nonce-misuse resistance
Structure	Counter mode plus GHASH	ChaCha20 stream plus Poly1305	Tag derived from plaintext, then counter mode, via POLYVAL
Passes	One pass, online, parallelizable	One pass, online	Two passes, not online
Best hardware	AES-NI and carryless multiply	none needed, fast in software	AES-NI and carryless multiply
Nonce reuse	Catastrophic (Joux forgery)	Catastrophic (keystream reuse)	Graceful, leaks only equality of inputs
Per-key limit	about $2^{32}$ invocations at a 96-bit nonce	same nonce-uniqueness requirement	far higher tolerance
Key-committing	No	No	No
Best suited for	TLS and QUIC with AES hardware	mobile and embedded, no AES hardware	stateless senders, key wrap, uncertain nonces
Spec	NIST SP 800-38D	RFC 8439	RFC 8452

Note: Pick AES-256-GCM when you have AES hardware and can guarantee unique nonces. Pick ChaCha20-Poly1305 when you cannot count on AES hardware, as on many mobile and embedded targets [@rfc8439]. Pick AES-GCM-SIV when nonce uniqueness is at risk, for example stateless senders, key wrapping, or anything that can be cloned or rolled back [@rfc8452]. None of the three commits to its key, so add that property separately if you need it.

The newest target on this list, key commitment from Generation 5, is being written into standards as you read this. In May 2025 the IRTF's Crypto Forum Research Group published RFC 9771, which gives consensus, game-based names for Key Commitment and Full Commitment alongside related properties such as nonce hiding, multi-user security, and quantum security. A spec can finally name the property it needs instead of gesturing at it [@rfc9771].

NIST is scoping an actual mode. Its Accordion effort targets a tweakable, variable-input-length strong pseudorandom permutation with a reduction proof and key commitment as a stated requirement, laid out across NIST IR 8537 in 2024 [@ir8537], the requirements report NIST IR 8552 in April 2025 [@ir8552], and a pre-draft call for comments on SP 800-197A that proposes three modes (Acc128, Acc256, and a beyond-birthday variant) built from the HCTR2 technique [@sp800197a] [@hctr2] [@nist_news_accordion].

You do not have to wait for it: the AWS Encryption SDK already enforces key commitment through a commitment policy, a production deployment that predates any standard [@aws_esdk].

Why does commitment need a whole new mode rather than a bigger tag? Partly because a binding guarantee inherits the birthday bound: $n$-bit commitment security needs roughly a $2n$-bit commitment, about 256 bits for 128-bit security, so a standard 128-bit tag is undersized for the job [@bh2022]. And breaking commitment is a binding problem, which the sketch below shows is a weapon rather than a curiosity.

{` // Intuition only, not a real attack. A non-committing "AEAD" whose verifier // happens to accept a crafted ciphertext under MANY candidate keys. function accepts(candidateKey, craftedCiphertext) { // In a committing scheme this would be true for at most one key. // Here the attacker built a ciphertext valid for a whole set of keys. return craftedCiphertext.validKeys.includes(candidateKey); }

// The attacker packs "half the remaining candidates" into one ciphertext. function craftFor(keySubset) { return { validKeys: keySubset }; }

let candidates = []; for (let i = 0; i < 1024; i++) candidates.push("key#" + i);

let queries = 0; while (candidates.length > 1) { const half = candidates.slice(0, Math.floor(candidates.length / 2)); const ct = craftFor(half); queries++; // One online guess rules out half the space, committing or not. candidates = accepts(candidates[0], ct) ? half : candidates.slice(half.length); } console.log("Recovered key:", candidates[0], "in", queries, "online queries over 1024 candidates."); `}

Ten queries to search a thousand keys, because each ciphertext answers "is your key in this set?" A committing scheme makes that impossible: one ciphertext accepts under at most one key, so each guess can only ever eliminate a single candidate.

All of this, classical and post-quantum, symmetric and public-key, is proven in one of two settings, under one of two styles of definition. Which one you trust changes what the proof is worth.

7. Two Styles of Definition, Two Places to Prove Them

Two long-running tensions run underneath every definition so far, and neither is resolved. The first is how you state a goal. The second is where you prove it.

Everything up to this point has used indistinguishability games: define two worlds and demand that no efficient adversary can tell them apart. That style fits standalone primitives beautifully. But there is a second style, simulation-based (or real-versus-ideal) security, which asks a different question: is there a simulator that, with no access to the secrets, can produce a transcript indistinguishable from a real interaction? If so, the real protocol leaks nothing the ideal one would not, because anything the adversary learns it could have generated itself.

Simulation is the natural language for zero-knowledge proofs, secure multiparty computation, and composable settings, where the strongest framework is Universal Composability.Universal Composability, due to Ran Canetti [@canetti2001uc], proves a protocol secure even when arbitrarily many copies of it and other protocols run concurrently, by comparing the real execution to an ideal functionality. It is the strongest simulation-based framework, and the price of that strength is that UC-secure protocols are harder to build. We only point at it here. Simulation generally implies the matching indistinguishability notion but not the reverse, so the two are complementary lenses rather than rivals [@bonehshoup]. For these simulation-based definitions in deployed systems, see the age gate that does not know your age and direct anonymous attestation.

The second tension is the setting in which a proof lives, and it is the one most often misunderstood.

The random oracle model proves a scheme secure while treating a hash function as if it were a truly random function that everyone can query but nobody can predict. It is a *proof setting*, a modeling assumption you adopt in order to prove a goal such as IND-CCA2, and it sits beside the standard model, which assumes only that standard problems are hard. The random oracle model is emphatically **not** a security definition. It never occupies the same slot as IND-CPA or EUF-CMA; it is where you prove those goals, not what you prove.

Bellare and Rogaway introduced it in 1993 precisely because it buys efficient, strong proofs for practical schemes: OAEP, PSS, and the FO transform behind ML-KEM all live here [@br1993]. The standard model asks for less faith and is therefore more trustworthy when you can afford it.

Cramer and Shoup proved in 1998 that IND-CCA2 is achievable in the standard model, under the decisional Diffie-Hellman assumption, with no random oracle at all, settling that the strongest confidentiality target is not hostage to the heuristic [@cramershoup1998]. The two settings coexist as a trade of assurance against efficiency, and the post-quantum era stacks the quantum random oracle model on top.Beyond the deployed targets in this guide, the literature refines these notions further along both axes. RCCA (Canetti-Krawczyk-Nielsen) [@ckn2003rcca] and the related gCCA and mCCA variants relax IND-CCA2 for settings such as re-randomizable encryption. On the hash-function side, UCE is a standard-model assumption for discharging hash-based proofs without a random oracle, while indifferentiability is an ideal-model framework showing that a concrete construction built from an ideal primitive behaves like a random oracle, the tool that justifies random-oracle-style design rather than replacing it. These academic refinements are surveyed in later parts of this series; here they are pointers only.

Here is the whole thing in one picture: two proof settings, the random oracle model and the standard model, with the major schemes sorted by where each one is proven.

flowchart TD subgraph ROM["Random oracle model"] O["RSA-OAEP (IND-CCA2) and RSA-PSS (EUF-CMA), strong game-based goals proven in the ROM"] K["ML-KEM, IND-CCA2 KEM via the FO transform in the quantum ROM"] end subgraph STD["Standard model"] CS["Cramer-Shoup, IND-CCA2 under decisional Diffie-Hellman"] UC["Universal-composability zero knowledge, simulation based"] end The random oracle model and the standard model are not rival definitions of secure. They are two settings in which you prove the same goal.

Which raises the uncomfortable question the next section confronts. If the random oracle model is only a heuristic, exactly how much is a random-oracle proof worth?

8. What a Proof Cannot Promise

Now the uncomfortable part. A scheme can be provably secure in the random oracle model and broken under every real hash function you could ever plug in.

That is not a worry, it is a theorem. Canetti, Goldreich, and Halevi constructed signature and encryption schemes that carry airtight proofs in the random oracle model yet become insecure the moment the oracle is replaced by any concrete, efficiently computable hash [@cgh2004]. Their construction is deliberately contrived, engineered to detect when its oracle has a short description and to misbehave when it does. But contrived is enough: it proves that a random-oracle proof cannot, in general, guarantee security once instantiated. The proof is real; the security does not always survive contact with a real hash.

Note: Treat a random-oracle proof as strong evidence, not as a certificate. It says a scheme has no structural weakness of the kind the proof rules out, which is reassuring for OAEP, PSS, and ML-KEM. It does not say that every hash instantiation is safe, because we know constructions where none is [@cgh2004]. Calibrate your trust to the setting the proof actually used.

The honest reading is not to discard random-oracle proofs. Almost everything efficient we deploy has one, and the counterexamples above are artificial rather than schemes anyone would design. The honest reading is to calibrate. That is also the spirit of Koblitz and Menezes's "Another Look" critique, which is often misread as an attack on provable security and is better understood as a discipline for reading proofs [@km2007].

Before you trust a "provably secure" label, ask four questions. What exactly are the goal and adversary model, stated in full? What assumption does the reduction rest on, and how well studied is it? How tight is the reduction, and what security does it actually deliver at the deployed parameters? And in which setting does the proof live, random oracle or standard model? None of these questions refutes a proof. Each tells you what the proof is worth [@km2007].

Even celebrated proofs need repair. The original OAEP argument had a gap in its chosen-ciphertext proof that went unnoticed for years before it was found and fixed for the RSA case.Victor Shoup showed in 2001 that the original OAEP proof did not establish IND-CCA2 in the generality claimed. The result was recovered for RSA specifically, but only after the community re-examined a proof everyone had trusted [@shoup2001]. A proof is an artifact, and artifacts can contain bugs. If the proofs themselves can carry errors, "it has a proof" is the beginning of due diligence, not the end.

Underneath all of it sits the deepest limit of the field. Essentially every computational definition in this guide rests on an unproven assumption: that factoring is hard, that discrete logarithms are hard, that Module-LWE is hard. A genuine, unconditional proof that any of them is hard would resolve questions on the order of P versus NP, which nobody can do [@bonehshoup].

So "provably secure" always means conditionally secure. There is no unconditional computational security above the Shannon bound we started with. The one-time pad remains the only thing proven secure against an unbounded adversary, and it is the one thing we cannot afford to use.

None of this refutes the method. It maps the edge of what is settled. And the edge is exactly where today's research is moving.

9. Where the Definitions Are Still Moving

The chain is not closed. Each open problem below is a place where the adversary model is still being enlarged, which is another way of saying the thesis is a roadmap rather than a finished map.

Standardizing committing AEAD. The deployed triad commits to nothing, yet message franking, multi-recipient encryption, key rotation, key-management services, and password-based encryption all need it. The Accordion effort is scoping the mode now, but whether the default becomes key commitment (CMT-1) or full context commitment (CMT-4) is still open, and the two differ in both cost and in what they defend [@ir8537] [@sp800197a].
Tight, deployment-honest reductions. Loose reductions force larger keys than the assumption alone requires, and the gap is worst in the multi-user setting, where one attacker faces millions of sessions at once. The Section 5 rule makes the cost concrete: if a reduction loses a factor equal to a billion ($2^{30}$) sessions, a headline 128-bit guarantee shrinks to about 98 bits at the deployed parameters.RFC 9771 names multi-user security as a distinct property precisely because a bound that is comfortable for one user can dissolve across a billion of them. Tight multi-user proofs are an active target, not a solved problem [@rfc9771]. How much the community should discount a loose proof remains contested rather than settled [@km2007].
Post-quantum definitions in the quantum random oracle model. What "IND-CCA2 against a quantum adversary" actually costs is still being pinned down. ML-KEM ships with a proof whose bound is not tight, and the right model for a superposition decryption oracle is unsettled [@hhk2017] [@rfc9771].
The random-oracle-versus-standard-model question. Canetti, Goldreich, and Halevi proved the random oracle model is in principle uninstantiable, yet the efficient schemes running the internet are proved there, and Cramer and Shoup showed the standard model can reach the same target at higher cost [@cgh2004] [@cramershoup1998]. There is no consensus on how much to trust the heuristic; the honest position is calibrated trust, not resolution.

Note: Every entry on this list is a place where a future deployment could hand an attacker a capability no current definition names, exactly as message franking did in 2018. That is why the discipline is not "memorize the acronyms." It is a habit you apply before you choose a primitive.

Which is exactly why mastery here is not the acronyms. It is a workflow, and it fits on one screen.

10. The Field Guide: Choose the Target Before the Primitive

Everything in this guide collapses into one workflow you can run in a design review this afternoon: name what the adversary is allowed to do, pick the target that survives that adversary, and only then choose a concrete mode and its parameters. The tree below is the whole method.

flowchart TD Q1{"Can the adversary observe decryption or accept/reject?"} Q1 -->|"Yes"| CCA["Require IND-CCA2, never IND-CPA-only"] Q1 -->|"No, just encrypting a channel"| AEAD["Use AEAD by default"] AEAD --> Q2{"Can you guarantee unique nonces?"} Q2 -->|"Yes, with AES hardware"| GCM["AES-256-GCM, 96-bit random nonce, cap under 2 to the 32 per key"] Q2 -->|"No"| SIV["AES-GCM-SIV, nonce-misuse resistant"] CCA --> Q3{"Must one ciphertext bind to one key?"} Q3 -->|"Yes"| CMT["Require committing AE, CMT-4 or a vetted transform"]

The decision rules, stated the way you would apply them:

If any adversary can observe decryption or accept/reject behavior, require IND-CCA2, never IND-CPA-only. That is the Bleichenbacher and ROBOT lesson: a reacting server is a decryption oracle [@bleichenbacher1998].
If you are encrypting a channel, use AEAD by default. AES-256-GCM with 96-bit random nonces and a hard message cap well under $2^{32}$ per key [@sp800_38d]; ChaCha20-Poly1305 where there is no AES hardware [@rfc8439]; AES-GCM-SIV when nonce uniqueness cannot be guaranteed [@rfc8452].
If you must use RSA encryption at all, use RSA-OAEP, never PKCS#1 v1.5, or drop RSA key transport entirely as TLS 1.3 did [@br1994oaep] [@bleichenbacher1998].
If you need authenticity only, use HMAC or Ed25519 for EUF-CMA, and require SUF-CMA wherever a signature or token must be unique [@bonehshoup] [@decker2014]. Ed25519 delivers SUF-CMA only when verification enforces the RFC 8032 canonical-S range check, rejecting any scalar $S$ outside $[0, L)$; libraries that skip it stay malleable [@rfc8032].
If a ciphertext must bind to exactly one key or context, require a committing AE: a CMT-4 construction or a vetted committing transform, never the raw triad. This is the multi-recipient, key-rotation, franking, password-based, and key-management case [@rfc9771] [@aws_esdk] [@bh2022].
If you need post-quantum key establishment, use ML-KEM (FIPS 203) in hybrid mode with a classical KEM during the transition [@fips203].

Deployment condition	Required target	Concrete choice and parameters	Anti-pattern it prevents
Adversary sees decryption or accept/reject	IND-CCA2	ML-KEM, RSA-OAEP, or an AEAD channel	Bleichenbacher, ROBOT, POODLE
Channel, unique nonces, AES hardware	AEAD	AES-256-GCM, 96-bit random nonce, cap under $2^{32}$ per key	Unauthenticated or malleable ciphertext
Channel, no AES hardware	AEAD	ChaCha20-Poly1305	Slow or side-channel-prone software AES
Nonce uniqueness not guaranteed	AEAD plus misuse resistance	AES-GCM-SIV	Joux forbidden-attack forgery
Legacy RSA encryption required	IND-CCA2	RSA-OAEP, never PKCS#1 v1.5	Padding-oracle decryption
Signature or token must be unique	SUF-CMA	Ed25519	Signature-malleability confusion
One ciphertext must bind to one key	Committing AE (CMT)	Committing transform or Accordion mode	Invisible salamanders, partitioning oracles
Confidentiality must outlive a quantum computer	IND-CCA2, post-quantum	Hybrid X25519 plus ML-KEM	Harvest-now-decrypt-later

Every rule above has a mirror image, a mistake that turns up in code review after code review. Here is the misuse catalog, each entry the negation of a rule you just read.

Nonce reuse under AES-GCM or ChaCha20-Poly1305, the single most destructive AEAD error, because it is a universal forgery via the Joux attack rather than a slow degradation [@joux_gcm]. Clones, snapshots, and stateless senders are the usual sources; reach for AES-GCM-SIV or a strictly managed random nonce with a per-key cap.
The wrong composition order, MAC-then-Encrypt or Encrypt-and-MAC; only Encrypt-then-MAC or a dedicated AEAD is generically safe, and history already paid for this with POODLE and Lucky Thirteen [@bn2000].
Treating AES-GCM as key-committing. It commits to nothing; assuming otherwise is the salamander and partitioning-oracle bug [@salamanders2018] [@partitioning2021].
Unbounded messages per key, silently walking past the birthday ceiling that GCM's 96-bit nonce imposes [@sp800_38d].
Verifying a signature without binding its context, which EUF-CMA never promised to cover and which invites cross-protocol confusion.
Trusting a random-oracle proof as a standard-model guarantee, when it is a heuristic to be calibrated rather than a certificate [@cgh2004].

For where these targets are actually invoked as concrete API calls on Windows, from BCrypt to key storage providers, see the CNG architecture behind BCrypt, NCrypt, and KSPs.

Note: State your deployment's adversary model first, choose the matching target second, and pick the concrete primitive and its parameters last. Every rule and every anti-pattern above is a corollary of that one habit.

Bleichenbacher and ROBOT: require IND-CCA2 and drop PKCS#1 v1.5. Lucky Thirteen and POODLE: use an AEAD with Encrypt-then-MAC, not MAC-then-Encrypt CBC. AES-GCM nonce reuse: cap messages per key and use AES-GCM-SIV where uniqueness is uncertain. Invisible salamanders and partitioning oracles: require a committing (CMT) mode. Every break in the catalog was preventable by choosing the target the environment demanded before choosing the primitive.

One habit generated every rule and every warning on this page: name the adversary first.

11. Misconceptions, Named and Corrected

The fastest way to internalize the thesis is to correct the folklore it contradicts.

Only against a *passive* adversary who never sees how the receiver reacts to a ciphertext. The moment a server decrypts attacker-supplied input and behaves observably differently on success and failure, you need IND-CCA2. That gap is exactly what Bleichenbacher's attack exploited [@bleichenbacher1998]. Only under a strict nonce-uniqueness contract and a per-key message cap. Reusing a (key, nonce) pair is a universal forgery, not a minor leak [@joux_gcm]; NIST caps GCM at about $2^{32}$ invocations per key at a 96-bit nonce [@sp800_38d]; and GCM commits to no key, so it is unsafe wherever commitment is assumed [@salamanders2018]. It is strong evidence, not a guarantee. Canetti, Goldreich, and Halevi built schemes provably secure in the random oracle model that are insecure under every real hash [@cgh2004]. Trust a random-oracle proof, but calibrate that trust to the setting it used. No. Confidentiality and integrity are different goals; a one-time pad has perfect confidentiality and zero integrity, since flipping a ciphertext bit flips the plaintext bit undetected. Use an AEAD, and compose Encrypt-then-MAC if you must build it yourself [@bn2000]. No. SUF-CMA also forbids producing a *new* valid signature on an already-signed message, which EUF-CMA permits. The gap bites whenever a signature or ciphertext is treated as a unique token, as Bitcoin transaction malleability showed [@decker2014] [@bonehshoup]. No. It means *conditionally* secure, relative to a named hardness assumption and adversary model, and only as tightly as the reduction allows. A loose reduction delivers fewer bits of security than the headline number suggests [@km2007]. No. It is a proof setting, a heuristic that idealizes a hash as a random function, and it sits beside the standard model, not beside goals like IND-CPA or EUF-CMA. Cramer and Shoup showed the strongest confidentiality target is reachable without it [@br1993] [@cramershoup1998].

The Contract Behind the Cipher

We began with a puzzle: Daniel Bleichenbacher decrypted SSL sessions without ever breaking RSA. The answer runs through every section since. "Secure" is not a property an algorithm has. It is a contract, a goal bound to an adversary model, and a construction honors that contract only against the adversary the contract names.

Bleichenbacher, POODLE, Lucky Thirteen, AES-GCM nonce reuse, invisible salamanders, partitioning oracles: not one of them was weak math. Each was a construction meeting a weaker target than its deployment's adversary demanded, after the environment handed the attacker an oracle, a repeated nonce, or a second key the proof never granted.

That is why the vocabulary matters. IND-CPA and IND-CCA2 name what confidentiality means against a passive versus an active adversary. EUF-CMA and SUF-CMA name authenticity with and without malleability. AEAD names their union; committing AE names what AEAD forgot. The random oracle model and the standard model name where a proof lives, and a reduction names the single assumption on which the whole guarantee rests. Learn to read a construction as goal plus adversary model plus proof setting, and the failure catalog stops being a list of surprises and becomes a list of predictions.

This is Part 1 of a field guide, and it deliberately taught no primitive in depth. That was the point. The remaining parts of this series will build RSA, Diffie-Hellman, elliptic curves, lattices, and hash functions, and every one of them will be measured against exactly the targets defined here. The math will change from part to part. The contract will not.

The RSA math was always fine. What the field lacked in 1998 was the habit of naming the adversary before trusting the primitive. Now you have it.

State the adversary model first, choose the matching target second, and pick the primitive last. That one habit would have prevented every break in this article.