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

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 ^[1]. 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 ^[2]. 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.

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 ^[3]. 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 ^[3]. 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.

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.

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 ^[7]. 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 ^[8]. Vaudenay's procedure is documented in cryptography's standard texts as the canonical illustration of chosen-ciphertext insecurity ^[9].

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.

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 ^[8]. 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 ^[10]. 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 ^[11].

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#

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.

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 ^[7].

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;
}
}

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.

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.

flowchart TD
A["Loud padding-error message (Vaudenay, ASP.NET)"] -->|"Unify the alert"| B["Coarse timing gap (Canvel)"]
B -->|"Compute the MAC anyway"| C["Statistical timing (Lucky Thirteen)"]
C -->|"Constant-time AES-NI fast path"| D["Fix re-creates the oracle (CVE-2016-2107)"]
D -->|"Verify authenticity first"| F["Encrypt-then-MAC and AEAD, no verdict to leak"]
P["Unchecked padding by spec (POODLE, SSL 3.0)"] -->|"Retire SSL 3.0 and CBC"| F

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 ^{[1] [2]}. 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 ^[13]. 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 ^[14]. 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 ^[15].

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) ^{[15] [16]}. 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 ^[11]. 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 ^{[17] [18]}. 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 ^[19]. 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 ^{[17] [20]}. 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 ^[21], 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 ^{[22] [23]}. 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 ^[24].

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 ^{[25] [26]}.

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 ^[27], 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.

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 ^[28]. Each maps cleanly onto a real protocol.

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 ^[29].

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.

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 ^[28]. 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 ^[30]. 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 ^[30]. 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 ^[31].

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)

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

AEAD (RFC 5116) is Encrypt-then-MAC's standardized successor: one primitive, authenticity intrinsic, no composition knob to misset ^[33]. 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.

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 ^{[34] [35]}. 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 ^[36].

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" ^[32]. And BCP 195 (RFC 9325, 2022) codifies the operational rule: prefer TLS 1.3, prefer AEAD suites on 1.2, and recommend against CBC ^[37].

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 ^[25].

"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) ^[38] -- and standard AEAD is not key-committing, so one ciphertext can be made to open to different valid plaintexts under different keys ^[39]. 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 ^{[40] [41]}. 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 ^[32]. 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 ^{[15] [22]}.

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 ^[7]. 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.

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.

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 ^[28]. 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 ^[30].

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 ^[22]. 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 ^[42]. 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 ^{[25] [43]}.

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.

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 ^[44], 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 ^[38] and the lack of key commitment ^[39] -- 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 ^{[40] [41]}. 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 ^[34]. 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 ^[40].
• If a ciphertext may be opened under more than one key -- JWT and JOSE, envelope encryption, abuse reporting -- use a committing AEAD ^{[39] [41]}.
• 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 ^[32].
• 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 ^[37].
• 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.

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

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.

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 ^[1].

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 ^[28]. 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 ^[36].

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.