Parag Mali - tag: cbc

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.