Parag Mali - tag: padding-oracle

How RSA Breaks in Real Life: ROCA, Bleichenbacher's Ghosts, FREAK, and the Keys That Shared a Prime

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

**No one has ever factored a strong, correctly generated RSA key in the wild.** The public ceiling is RSA-250, an 829-bit *challenge* number that took about 2,700 core-years in 2020 [@rsa250-2020]. And yet real RSA keys, sessions, and signatures fell anyway, at three layers the RSA math depends on but does not control. **Key generation:** the 2008 Debian OpenSSL bug collapsed the keyspace to roughly 32,767 seeds [@cve-2008-0166]; low-entropy devices *shared primes* recoverable with a single `gcd` in 2012 [@factorable-2012]; Infineon's ROCA library built *structured* primes a Coppersmith lattice factors, forging Estonian eID cards and YubiKey 4 in 2017 [@roca-crocs]. **Padding:** Bleichenbacher's 1998 oracle decrypts a session from about a million padding-validity answers, recovering no key and factoring nothing [@bleichenbacher-1998], revived by DROWN across roughly a third of HTTPS via SSLv2 in 2016 [@drown-2016] and by ROBOT on Facebook and PayPal in 2017 [@robotattack]. **Negotiation:** FREAK forced a 512-bit export key and factored it for about \$100 in 2015 [@freakattack]. Seven deployed breaks, one pattern. Where three of them ended in a factorization, it was only because the deployment had already produced a *weak* modulus -- the math merely finished the job. Every fix changed how RSA is generated, used, or negotiated -- validated entropy, OAEP and PSS, TLS 1.3 dropping RSA key transport [@rfc8446] -- never RSA itself.

1. No One Has Ever Factored a Strong RSA Key. Your RSA Keys Broke Anyway.

The largest RSA key ever factored in public is a 250-digit, 829-bit challenge number, and cracking it in 2020 took the world's best number theorists about 2,700 core-years [@rsa250-2020]. No strong, correctly generated RSA key protecting real traffic has ever been factored at all. Hold that fact still for a moment, because the next one refuses to sit beside it.

In the same era, Estonian national ID cards were forgeable [@roca-crocs], roughly a third of all HTTPS was decryptable [@drown-2016], hundreds of thousands of embedded private keys were recoverable [@factorable-2012], and export-grade sessions were silently man-in-the-middled [@freakattack]. Every one of those was an RSA break. Not one of them was a factored strong modulus. So how does a factoring problem nobody can beat on a strong key keep producing forged signatures, decrypted sessions, and stolen private keys?

The resolution is the whole argument of this article, and it belongs before the evidence: none of these broke strong RSA. RSA is a trapdoor permutation, and its single security promise is narrow -- that factoring a strong $n = p \cdot q$ is hard [@rsa-1978]. That promise silently depends on three things the mathematics does not control: where the primes came from, how the decrypting party validates padding, and which key strength a protocol will accept. It was those three deployment-owned layers, never the factoring problem, that gave way.

So carry one diagnostic question through everything that follows. When an RSA key, session, or signature falls, do not ask "did someone factor the modulus?" Ask instead: which layer the math depends on but does not control gave way -- the primes, the padding, or the negotiation? Every break in this article is a non-empty answer to that question, and you will learn to drop ROCA, DROWN, FREAK, and tomorrow's incident into it on sight.

To break RSA in the field, you never factor a strong modulus. You take the weak one the deployment already handed you, or the oracle it left open -- and the factoring problem on a strong key stands untouched.

The paradox even has a face. The researcher Nadia Heninger appears at both poles of this story: she recovered weak keys in the field, and she co-holds the public record for factoring a strong one [@factorable-2012, @rsa250-2020]. One person, both ends of the argument -- the weak keys that fall in an afternoon and the strong one that costs millennia of compute.

This is Part 3 of How It Breaks in Real Life, a series with one recurring thesis: the primitive's mathematics almost never caused the break; the deployment did. RSA is one of its cleanest cases. It has a companion piece, How RSA Would Break: Why Factoring Is the Slow Path and Coppersmith Is the Fast One, which handles the would-break-in-theory math: the Number Field Sieve, Coppersmith's lattices, and Shor's algorithm. This article is the did-break-in-the-field frame.

If no strong modulus was ever factored and the factoring problem never moved, then everything that broke was built around it. To see how "unfactored modulus" and "recovered key" can both be true at once, we have to go back to what RSA actually promises -- and, more importantly, what it silently assumes.

2. What RSA Actually Assumes

In 1977, Ron Rivest, Adi Shamir, and Leonard Adleman handed the world its first practical public-key cryptosystem: a public modulus $n = p \cdot q$, a public exponent $e$, a private exponent $d$, and a security argument resting on the hardness of factoring $n$ [@rsa-1978]. That assumption is exactly why the core problem has held for five decades. It is also exactly why, when RSA breaks in the field, the fault lies somewhere else. Being a trapdoor permutation made RSA a primitive. It did not make it a safe deployment.

Start with the single most important distinction in this article. RSA-the-primitive is a keyed permutation over the integers modulo $n$, and its security promise is narrow and conditional. Here is the precise version, because the imprecise version is the source of half the confusion in the subject.

RSA fixes a modulus $n = p \cdot q$, a public exponent $e$, and a private exponent $d$; encryption is $c = m^e \bmod n$ and decryption is $m = c^d \bmod n$. Its security rests on the assumption that inverting the permutation without $d$ is hard. Factoring $n$ is *sufficient* to invert it -- recover $\phi(n)$, then $d$ -- and remains the best known attack, so breaking RSA is *at most* as hard as factoring. Whether it is *as hard as* factoring, the RSA-problem-versus-factoring equivalence, is an open question [@boneh-1999, @rsa-1978]. The math controls only that hardness, never where $p$ and $q$ come from.

Read that twice, because the direction matters. Factoring is sufficient to break RSA: if you can factor $n$, you win. But nobody has proved the reverse, that breaking RSA requires factoring. The RSA problem might, in principle, be easier than factoring; we do not know. What we do know is that the best attack anyone has found on the primitive is still factoring, and factoring a strong modulus is where the wall stands.

Notice the quiet consequence: the field never even needed that unproven shortcut. Every deployed break in this article bypassed both directions entirely. No one factored a strong key, and no one found a clever inversion either. They walked around the math.

Because the guarantee is only about the difficulty of factoring, it says nothing about three other things:

Where $p$ and $q$ come from. They must be large, independent, and drawn from real entropy.
How the raw permutation is wrapped. Textbook RSA is deterministic and malleable, so it must be padded before it is used.
Which key strength a protocol will accept. A 512-bit option nobody wants is still a 512-bit option somebody can force.

Unpadded RSA is deterministic: equal plaintexts always produce equal ciphertexts, so an eavesdropper can recognize repeats and test guesses. It is also *malleable*, because $(m_1^e)(m_2^e) \equiv (m_1 m_2)^e \pmod{n}$: an attacker who multiplies a ciphertext by $s^e$ turns it into an encryption of $m \cdot s$ without knowing $m$. Both properties make raw RSA unusable on its own; it must be wrapped in a padding scheme. That same malleability is the lever every padding-oracle attack pulls.

Those three silences are the structure of the whole article. Picture them as a map: the factoring-hardness assumption sits at the center, and three deployment-owned dependencies surround it. Each is an independent surface an attacker can reach without ever touching the factoring problem.

flowchart TD A["The one RSA guarantee: factoring a strong modulus is hard"] A --> B["Layer 1: Key generation, where the primes come from"] A --> C["Layer 2: Padding validation, how decryption is checked"] A --> D["Layer 3: Negotiation, which key strength is accepted"] B --> E["Each layer is an independent failure surface reached without factoring"] C --> E D --> E

Before we watch each dependency fail, three guardrails, because the argument is easy to overstate in exactly three ways.

Note: The whole argument turns on one distinction. Three incidents ahead -- FREAK, ROCA, and shared primes -- do end in a factorization. That is not a counterexample to the thesis; it is the thesis. In each case the deployment first produced a weak modulus (a downgrade forced 512 bits, a library constrained the primes, bad entropy made two keys collide), and the math only finished a job the deployment had already set up. The precise, load-bearing claim, kept word-for-word throughout: no strong, correctly generated, deployed modulus has ever been factored in the field. The public ceiling is RSA-250, an 829-bit challenge number [@rsa250-2020].

The series this article belongs to lists a familiar set of culprits: the RNG, the nonce, the padding, the downgrade. RSA answers to most of them, but not the nonce.RSA signing has no secret per-signature nonce whose reuse leaks the key. The nonce-reuse break -- the reused $k$ behind the 2010 PlayStation 3 and 2013 Android SecureRandom key recoveries [@ps3-epic-fail-2010, @android-securerandom-2013, @bitcoin-android-alert-2013] -- is an (EC)DSA phenomenon, a different primitive. There is no "RSA nonce-reuse break"; when you see one described, it is really an ECDSA story, and it is told in its own article. Two of the three real culprits are RSA's, and both are downstream of the map above.

The series says the primitive's math *almost* never causes the break, and that hedge is load-bearing. Factoring is genuinely real, just slow. It fell RSA-155 (512-bit) in 1999, RSA-768 in 2009, and RSA-250 in 2020 [@rsa155-2000, @rsa768-epfl, @rsa250-2020], every one a public *challenge* number, never a deployed key. And Shor's algorithm will fall RSA outright on a large quantum computer. None of that is a deployed strong key, and all of it belongs to the companion article, *How RSA Would Break*. State the hedge, and never inflate it into a claim that the mathematics is somehow unbreakable.

One narrow assumption, three silent dependencies, none of them the factoring problem. Before we watch each dependency break in the field, we need to see the contracts up close: what real entropy actually buys, why a padding check is a loaded gun, and why a 512-bit option nobody uses is still a live weapon.

3. Three Contracts the Math Cannot Enforce

Every field break in this article is the violation of one specific promise -- a promise the RSA math assumes but has no way to enforce. There are exactly three, one per layer of the map, and once you can see the contract, the break becomes obvious. Here they are, side by side.

Layer	The contract it imposes	Cost of violating it	Who owns it
Key generation	Primes are unpredictable and never shared	Keys become enumerable, colliding, or structurally factorable	The RNG, the key-generation library, the boot-time entropy source
Padding validation	Never reveal whether a decryption was well-padded	The server becomes a decryption or signing oracle	The TLS and PKCS#1 implementation
Negotiation	Never accept a crippled key or a dead protocol	A strong peer is forced down to a breakable one	The protocol state machine and its configuration

The key-generation contract: the primes must be unpredictable and never shared. Two "random" primes are only as unpredictable as the generator that produced them. Starve that generator of entropy, cripple it with a bug, or bias its structure, and the primes come out predictable, colliding, or specially formed -- while every later step still looks textbook-correct.

A cryptographically secure pseudorandom number generator (CSPRNG) stretches a small secret seed into an unbounded stream of unpredictable bits, and its output is only as unpredictable as that seed. If the seed is starved of real entropy at boot, crippled by a bug that removes entropy, or drawn from a generator that constrains its outputs, the primes it produces become predictable, colliding, or specially formed, even though the arithmetic around them is flawless. If two moduli $n_1$ and $n_2$ accidentally share one prime, then $\gcd(n_1, n_2) = p$ recovers that prime with a single Euclidean gcd, and one division gives the other factor of each. A batch-GCD computes every pairwise gcd across millions of keys at once with a product-and-remainder tree, in quasi-linear time. It is simultaneously an attack (recover private keys at Internet scale) and a defense (scan your own fleet for collisions).

The hidden assumption behind this contract is quiet but total: enough real entropy reached key generation, and no two keys ever drew the same prime.

The padding contract: never reveal whether padding was valid. Textbook RSA is deterministic and malleable, so a real system must wrap the message before exponentiating. For twenty-five years the near-universal wrapper has been PKCS#1 v1.5.

Before exponentiation the message is wrapped as `00 02 [at least 8 random non-zero bytes] 00 [message]` [@rfc2313]. The leading `00 02` marks an encryption block, the random bytes make equal plaintexts encrypt differently, and the `00` separator marks where the message begins. The attack in this article is on this v1.5 *encryption* format, whose validity check becomes the oracle. PKCS#1 v1.5 *signatures* are a separate construction and are not what these attacks break.

Here is the conceptual pivot the whole subject turns on. In 1998, Daniel Bleichenbacher noticed that the padding check itself is a leak [@bleichenbacher-1998]. A server that decrypts a ciphertext and then reveals -- by error, timeout, or timing -- whether the result began with the required 00 02 bytes has answered a yes/no question about the plaintext. One bit does not sound like much. But raw RSA is malleable, so the attacker can ask the question about a plaintext of their choosing.

A decrypting party that reveals -- by error message, connection reset, timeout, or response timing -- whether a submitted ciphertext decrypted to validly padded plaintext leaks one bit per query. Feed it enough adaptively chosen ciphertexts and those one-bit answers pin the plaintext down, without ever recovering the private key. This is the single most load-bearing idea in the article.

Key idea: Because raw RSA is malleable, an attacker can multiply a ciphertext $c$ by $s^e$ to form $c' = c \cdot s^e \bmod n$, which decrypts to $m \cdot s \bmod n$. A server that reveals whether each such $c'$ was validly padded answers one yes/no question per query about where $m$ lies. About $10^6$ adaptive queries narrow $m$ to a single value: a session decrypted, with no private key recovered and nothing factored. This one mechanic drives Bleichenbacher, DROWN, and ROBOT.

You can feel the mechanic in miniature. The toy below uses an idealized one-bit oracle -- it reports only whether the decryption falls in the bottom half of the range -- and binary-searches the plaintext out of the server without ever touching the key.The oracle recovers no private key and factors nothing; it turns the server into a one-session decryption (or one-message signing) oracle, and the modulus is untouched afterward. Keep two things distinct: the attack is on PKCS#1 v1.5 encryption, and v1.5 signatures are a separate scheme it does not break.

{` function modpow(b, e, n){ b %= n; let r = 1n; while (e > 0n){ if (e & 1n) r = (rb)%n; b = (bb)%n; e >>= 1n; } return r; } const p = 61n, q = 53n, n = p*q; // toy modulus n = 3233 const e = 17n, d = 2753n; // public e, private d const m = 65n; // the secret plaintext const c = modpow(m, e, n); // the ciphertext the attacker holds

// The ONLY leak: does the decryption land in the bottom half of [0, n)? // An idealized magnitude / MSB oracle -- one bit per query. const oracle = (ct) => modpow(ct, d, n) < n / 2n;

const enc2 = modpow(2n, e, n); // multiplier that doubles the plaintext (malleability) const K = 14n, SCALE = 1n << K; let loS = 0n, hiS = n * SCALE, ct = c; for (let i = 0n; i < K; i++){ const mid = (loS + hiS) / 2n; if (oracle(ct)) hiS = mid; else loS = mid; // read one bit, halve the interval ct = (ct * enc2) % n; // next query sees 2m, 4m, ... mod n } console.log('recovered plaintext ->', (hiS / SCALE).toString()); // -> 65

// The real PKCS#1 v1.5 oracle asks a different one-bit question: do the top bytes // equal 00 02? That narrows m onto a union of intervals 2B <= m < 3B rather than a // < n/2 half -- same principle, different bit. This < n/2 magnitude test is the same // family of magnitude / most-significant-byte leak Manger's 2001 attack exploits // against OAEP -- but his oracle tests x < B = 2^(8(k-1)) (whether the leading octet // is zero), not x < n/2. `}

The negotiation contract: never accept a deliberately crippled key or a dead protocol. The math cannot see which key strength a handshake settled on, nor whether the protocol carrying it was retired a decade ago.

1990s US export regulations capped exportable cryptography at deliberately weak strengths, including 512-bit `RSA_EXPORT` key exchange, and SSLv2 was the era's now-obsolete protocol [@freakattack, @freak-sp2015]. Both were retired in principle long ago, yet both survived in shipping code and server configurations long enough to become live attack surfaces.

The assumption here is that only a party that wants export-grade crypto, or wants SSLv2, will ever get it.

Three contracts, each reasonable, each unenforced by the math. The factoring problem cannot tell whether you fed it a shared prime, a leaky padding check, or a forced 512-bit key. Which raises the only question that matters: on real smartcards and real servers, do these contracts actually hold? They do not. Here is where, when, and how each one broke.

4. Three Deployment Failures, Three Layers, One Pattern

The comfortable belief is "we use RSA-2048, so our keys, sessions, and signatures are safe." What follows are seven independent refutations of that inference: seven deployed field breaks, grouped into three pillars, one per layer the math depends on but does not control. Each pillar runs in chronological order, but read it as a failure catalog, not a lineage of improving designs. They are three simultaneous layers every real deployment must secure at once, and the chronology is simply the attacker's frontier moving from one unmet obligation to the next as each was patched.

Incident	Year	Pillar	Mechanism	Modulus	Recovers key?	Factors it?	The fix (changed the deployment)
Debian OpenSSL RNG	2008	Key generation	Seed collapsed to the process ID; keys enumerable	Weak	Yes	No	Real entropy; regenerate every key
Mining Your Ps and Qs	2012	Key generation	Shared prime; one gcd factors both	Weak	Yes	Yes (weak)	Entropy at boot; batch-GCD scanning
ROCA	2017	Key generation	Structured primes; Coppersmith lattice	Weak	Yes	Yes (weak)	Fix the library; ROCA detector; regenerate
Bleichenbacher	1998	Padding	v1.5 padding-validity oracle	Strong	No	No	Uniform errors; OAEP; drop RSA transport
DROWN	2016	Padding	Same oracle via a shared-key SSLv2 endpoint	Strong	No	No	Disable SSLv2; stop cross-protocol key reuse
ROBOT	2017	Padding	The 1998 oracle still answering across nine vendors	Strong	No	No	Constant-time uniform errors; retire RSA encryption
FREAK	2015	Negotiation	Downgrade to 512-bit `RSA_EXPORT`, then factor	Weak	Yes	Yes (weak)	Remove export ciphers; downgrade protection; TLS 1.3
RSA-250 (ceiling)	2020	Challenge	GNFS on an 829-bit challenge number	Strong	n/a	Yes (challenge)	Not a field break; the public ceiling, never deployed

Read the two rightmost data columns as the argument in a grid: every row that ends in a factored modulus is a weak modulus, and every row with a strong modulus recovers no key and factors nothing. The one strong modulus ever factored, RSA-250, is a challenge number that never protected anything.

flowchart LR Y1998["1998 Bleichenbacher, padding"] --> Y2008["2008 Debian RNG, key generation"] Y2008 --> Y2012["2012 shared primes, key generation"] Y2012 --> Y2015["2015 FREAK, negotiation"] Y2015 --> Y2016["2016 DROWN via SSLv2, padding"] Y2016 --> Y2017["2017 ROCA structure, and ROBOT padding"] Y2017 --> Y2020["2020 RSA-250 ceiling, a challenge number"]

Pillar 1: The primes were weak before the math began

All three key-generation breaks share one shape: generation produced a weak modulus, and then -- only then -- arithmetic finished it off. A strong modulus is on none of these paths.

flowchart TD R["Crippled RNG, Debian 2008"] --> W["Weak modulus"] B["Starved boot entropy"] --> SP["Two keys share a prime, 2012"] SP --> G["One gcd recovers the shared prime"] G --> W ST["Structured primes, Infineon RSALib, 2017"] --> CO["Coppersmith lattice factors the key"] CO --> W W --> F["The math finishes the job, and a strong modulus is on no path here"]

Debian OpenSSL, defect 2006, disclosed 2008. A well-meaning Debian patch, written to silence a Valgrind warning about uninitialized memory, removed most of the entropy feeding OpenSSL's PRNG. The change shipped in openssl 0.9.8c-1, and for nearly two years the effective seed collapsed to essentially the process ID, about 32,767 possibilities [@cve-2008-0166, @debian-dsa1571]. Keys stopped being unpredictable and became enumerable: an attacker could precompute the whole set. No factoring, no oracle, just a keyspace small enough to list.The defect was uploaded as openssl 0.9.8c-1 on 17 September 2006 and disclosed on 13 May 2008 by Luciano Bello [@debian-dsa1571-full]. Field measurement came from Yilek and colleagues at IMC 2009, who watched the fix propagate: 751 vulnerable certificates observed, and a meaningful fraction still vulnerable roughly six months later [@yilek-imc2009].

Mining Your Ps and Qs, 2012. Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman scanned the entire IPv4 Internet's TLS and SSH hosts and found something worse than predictability. They found collision. Headless and embedded devices, generating keys at first boot with almost no entropy, sometimes produced moduli that shared a single prime with an unrelated device. A shared prime is fatal, because $\gcd(n_1, n_2) = p$ factors both moduli in the time of one gcd.

They measured that 5.57% of TLS hosts shared keys, and they remotely recovered the RSA private keys of 0.50% of all TLS hosts through common factors, notifying 54 manufacturers [@factorable-2012]. An independent study the same year, titled "Ron was wrong, Whit is right," found the same collisions in a different dataset and ruled out a single-vendor fluke [@ron-wrong-2012].

You can watch both keys fall from one gcd:

{const gcd = (a, b) => { while (b) { [a, b] = [b, a % b]; } return a; }; // Two RSA moduli from two different devices. Neither looks weak on its own. // (Shrunk stand-ins; real moduli are hundreds of digits and the gcd costs the same.) const n1 = 63900000000000000000000000000000000000000000002625100000000000000000000000000000000000000000026931n; const n2 = 74700000000000000000000000000000000000000000003196300000000000000000000000000000000000000000034189n; const p = gcd(n1, n2); // one Euclidean gcd -- the entire attack const q1 = n1 / p, q2 = n2 / p; console.log('shared prime p =', p.toString()); console.log('device 1 recovered:', p * q1 === n1); console.log('device 2 recovered:', p * q2 === n2); console.log('Both private keys recovered from one gcd. Key size was irrelevant.');}

ROCA, 2017. The first two breaks needed bad randomness. ROCA needed none. Matus Nemec, Marek Sys, Petr Svenda, Dusan Klinec, and Vashek Matyas showed that Infineon's RSALib built its primes in a speed-optimizing but constrained form, $p = k \cdot M + (65537^a \bmod M)$, detectable from the public key alone and factorable by a Coppersmith-style lattice far faster than general factoring [@roca-ccs2017, @roca-crocs, @cve-2017-15361]. The randomness was fine; the structure was the flaw, so every key the chip ever generated was affected.The first author is Matus Nemec (not "Miroslav"), and the fifth is Vashek, or Vaclav, Matyas (not "Vladimir"). The affected products were the YubiKey 4 (not the YubiKey 5), Estonian national eID cards, and Infineon-based TPMs. Because the attack keys off structure rather than entropy, it is RNG-independent [@roca-crocs].

For a monic polynomial of degree $d$ modulo $N$, Coppersmith's method finds every integer root $x_0$ with $\lvert x_0 \rvert \le N^{1/d}$ in polynomial time, using lattice reduction [@coppersmith-1997]. When a prime is built with a special constrained structure, part of it becomes such a small root, and the method factors $n$ far faster than general-purpose factoring. It is the dormant 1997 engine ROCA revived; the lattice details belong to the companion *How RSA Would Break*.

The cost, from the authors themselves: a 1024-bit key fell in under three CPU-months, about $76 on AWS; a 2048-bit key in under 100 CPU-years, about $40,000; and roughly 760,000 confirmed-vulnerable keys were in the field [@roca-crocs]. Notice what "2048-bit" bought here: nothing. The number that mattered was not the key size but the structure of the primes.

Note: ROCA factors nominally 2048-bit keys, and a shared prime falls to one gcd, yet both only work because generation produced a weak key. The factoring problem on a strong modulus never bent; the RNG or the library did. This is the thesis's sharpest edge, and it is why the weak-versus-strong distinction has to stay explicit: a factored key here is evidence for the thesis, not against it.

Infineon's ROCA-vulnerable chips were FIPS 140-2 and Common Criteria EAL5+ certified, and they passed for years. Certification tested the on-chip RNG, not the *structure* of the public keys it produced, so a biased-but-well-randomized generator sailed straight through. This is exactly why the Pillar 1 fix adds post-generation structure and shared-factor tests, not just entropy checks [@roca-crocs].

Pillar 2: The padding check was an oracle

Now the padding pivot from Section 3, shown surviving twenty-five years of patches. Three incidents, one bug, reappearing at a new layer each time an inner defense hardened.

sequenceDiagram participant A as Attacker participant S as Server Note over S: Holds the private key, reveals only whether padding was valid A->>S: Submit c times s^e mod n S->>A: One bit, padding valid or invalid Note over A,S: Each bit narrows the interval that must contain m A->>S: Submit the next adaptively chosen ciphertext S->>A: One more bit Note over A,S: After about a million queries m is pinned, key never touched

Bleichenbacher, 1998. The origin. A PKCS#1 v1.5 encryption endpoint that reveals whether a decryption was well-padded becomes an adaptive chosen-ciphertext decryption oracle, and about $10^6$ queries decrypt a captured session. The private key is never recovered and nothing is factored; the attacker simply borrows the server's decryption ability for one message [@bleichenbacher-1998].

DROWN, 2016. Nimrod Aviram and fourteen coauthors, Heninger and Halderman among them, showed the 1998 oracle had a door nobody had closed: a forgotten SSLv2 endpoint. If a modern TLS server shared its RSA key with an old SSLv2 server -- common, because operators reused certificates -- an attacker could run a cross-protocol Bleichenbacher attack through the SSLv2 side, whose export ciphers and an OpenSSL bug made a "special" variant cheap.

At disclosure in March 2016, 33% of all HTTPS servers, 25% of the top million, and 22% of browser-trusted sites were vulnerable; it fell to about 1.2% by 2019 [@drown-2016].DROWN is not ROBOT. DROWN (2016) reached modern TLS cross-protocol, through a shared-key SSLv2 endpoint. ROBOT (disclosed December 2017, published at USENIX Security 2018) found the same oracle still answering directly on modern TLS stacks. Different years, different vector, the same 1998 bug [@drown-2016, @robotattack].

Note: Nadia Heninger co-authored Mining Your Ps and Qs (2012, weak keys recovered by gcd) and DROWN (2016, the oracle re-armed via SSLv2), and she co-holds the RSA-250 factoring record (2020, the slow way a strong key falls) [@factorable-2012, @drown-2016, @rsa250-2020]. One researcher stands at both poles of the argument. She is not alone: Juraj Somorovsky bridges DROWN and ROBOT, and J. Alex Halderman bridges Mining Your Ps and Qs and DROWN. This is one research community with a shared toolkit of Internet-wide measurement, not rival schools [@robotattack].

ROBOT, 2017. Hanno Bock, Juraj Somorovsky, and Craig Young gave the bug its name, Return Of Bleichenbacher's Oracle Threat, and showed the nineteen-year-old oracle still live across nine vendors, including F5, Citrix, Radware, Palo Alto Networks, IBM, and Cisco, with vulnerable subdomains on 27 of the top 100 domains, Facebook and PayPal among them [@robot-usenix2018, @robot-eprint, @robotattack]. To prove the point without crossing a line, the team used the oracle to sign a message with Facebook's private key, and still never recovered that key.

ROBOT "allows performing RSA decryption and signing operations with the private key of a TLS server" -- and yet recovers no private key at all. Its own recommendation is the entire fix thesis in one line: disable RSA encryption cipher suites entirely.

Note: Not by error text, not by an alert code, not by a TCP reset, not by a timeout, not by response timing. You cannot make an observable-validity scheme uniformly safe by patching. You replace it (OAEP) or remove it (no RSA key transport).

All three padding incidents carry the sharpest version of the thesis: the attacker uses the private key without ever holding it, and the modulus is untouched at the end. The remedy was never a bigger key. It was uniform, constant-time error handling and, ultimately, retiring RSA encryption in favor of OAEP or forward-secret key exchange, exactly as ROBOT advised.

Pillar 3: The negotiation forced a crippled key

FREAK, 2015. Benjamin Beurdouche and seven coauthors found a TLS state-machine flaw with a nasty consequence. A man-in-the-middle could force a handshake down to 512-bit RSA_EXPORT even when neither the client nor the server wanted export-grade crypto. And 512-bit RSA has been factorable since RSA-155 fell in 1999, so the attacker factors the downgraded modulus in hours for about $100 on cloud compute, then impersonates or decrypts the session. At disclosure, 36.7% of browser-trusted HTTPS servers still accepted export RSA [@freak-sp2015, @freak-pdf, @freakattack, @cve-2015-0204, @rsa155-2000].

sequenceDiagram participant C as Client participant M as MITM participant S as Server C->>M: ClientHello, wants strong RSA M->>S: Forward it but ask for RSA_EXPORT S->>M: ServerKeyExchange with a 512-bit export key M->>C: Inject the 512-bit key as if it were normal Note over M: Factor the 512-bit modulus in hours for about 100 dollars M->>C: Impersonate or decrypt the session

The factoring step is feasible here only because a downgrade plus 1990s export policy forced a deliberately weak key. The math finished a job the deployment set up, and it could not have touched a 2048-bit key the same way.The academic paper, "A Messy State of the Union," has eight authors; never attribute FREAK to a single name [@freak-sp2015]. The freakattack.com credit to Karthikeyan Bhargavan and the miTLS team, with tracking by the University of Michigan, is a separate and separately-true fact [@freakattack]. The fix was, again, a deployment change, not a cryptographic one: remove export ciphers, disable SSLv2, add downgrade protection, and ultimately TLS 1.3 dropping RSA key exchange entirely.

Three layers, seven field breaks, one shape. Every time, a contract the RSA math depends on but does not control was violated, real keys or sessions or signatures fell, and the factoring problem on a strong modulus did not move. Seen one at a time, each looks like a smartcard bug, a TLS bug, a legacy-protocol bug. Seen together, they are a single pattern, and the pattern is the whole point.

5. Every Fix Changed How RSA Is Generated, Used, or Negotiated -- Never RSA

Stop treating the seven incidents as separate. Line them up and one realization collapses the subject: every field break attacked a layer the math depends on but does not control -- entropy, then the padding check, then negotiated strength -- and every fix changed how RSA is generated, used, or negotiated, never the factoring problem.

The breakthrough here is not a eureka discovery. It is an engineering discipline, visible only because the same shape repeats across a twenty-year drumbeat from 1998 to 2020. Map each fix to its layer and watch none of them touch the primitive:

Key generation was answered with validated high-entropy generation plus post-hoc structure and shared-factor testing: FIPS 186-5, batch-GCD scanners, and the ROCA detector [@fips186-5, @factorable-2012, @roca-crocs].
Padding was answered with OAEP, uniform constant-time error handling, and, most durably, structurally retiring RSA encryption [@rfc8017, @robotattack].
Negotiation was answered by removing export and SSLv2, adding downgrade protection, and TLS 1.3 deleting static RSA key exchange outright [@rfc8446].

It is worth dwelling on the padding fix that failed, because its failure is the most instructive event in the whole story. The canonical countermeasure was not hand-waving. TLS 1.2 specified it precisely: on any decryption or padding failure, the server does not signal an error at all. It substitutes a randomly generated premaster secret and proceeds as if nothing were wrong, so the handshake fails uniformly and only later, at the Finished-message MAC, with no observable difference between valid and invalid padding [@rfc5246]. The RFC even cites Bleichenbacher and the Klima-Pokorny-Rosa version oracle by name.

It removed exactly one channel, the explicit error message. And the same one bit resurfaced through three more: a forgotten SSLv2 sibling (DROWN), implementation quirks like TCP resets and alert timing (ROBOT), and decryption timing (Marvin) [@drown-2016, @robotattack, @marvin-paper].

That is the deep lesson. A scheme whose validity is observable cannot be patched uniformly safe; it can only be structurally replaced. The field kept relearning Bleichenbacher's single lesson at a new layer each time an inner defense hardened.

Key idea: Every field break attacked a layer the math depends on but does not control, and every remedy -- validated entropy and structure tests, OAEP and PSS with uniform errors, dead export and SSLv2, TLS 1.3 -- hardened a deployment obligation. The factoring problem is the fixed point around which everything else evolved. Soundness requires the weakest of three deployment layers to hold, and hardening any one of them is an exercise in usage, not cryptanalysis.

This is exactly the border with the two companion pieces. The would-break-in-theory math -- the Number Field Sieve, Coppersmith's lattices, Shor's algorithm -- belongs to *How RSA Would Break*. The constructive depth of OAEP and PSS, including how to implement the constant-time error path correctly, belongs to [*RSA Done Right*](/blog/rsa-is-a-trapdoor-not-a-cryptosystem-oaep-pss-and-the-25-yea/). This article links out to both rather than re-teaching them, because its job is the pattern across the field, not the internals of any one fix.

If every fix is "generate, use, or negotiate RSA correctly," then the state of the art is simply the catalog of what "correctly" means at each layer in 2026 -- and where, even now, correct-by-the-book still is not enough.

6. What Correct RSA Deployment Looks Like in 2026

The modern answer is unglamorous, and that is the point: be sound at all three layers at once, because validated key generation does nothing for a leaky padding check, and a perfect padding scheme does nothing for a forced 512-bit downgrade.

Key generation. Use validated, high-entropy, structure-checked generation per FIPS 186-5, published February 2023 [@fips186-5]. Guarantee real entropy before the first key is generated, use 2048-bit or larger moduli, and run continuous fleet hygiene: batch-GCD across your own keys and the ROCA detector against certified black boxes [@factorable-2012, @roca-crocs]. Generation and measurement are complementary -- measurement catches what generation missed.

Padding and encryption. Use RSA-OAEP for encryption and RSA-PSS for signatures, both from RFC 8017, with constant-time, uniform-error decryption; better still, avoid RSA key transport altogether [@rfc8017].

OAEP (Optimal Asymmetric Encryption Padding) is a plaintext-aware encryption padding, and PSS is the analogous randomized signature scheme; both are specified in RFC 8017 [@rfc8017]. OAEP removes the Bleichenbacher oracle *as a class*, but only when decryption returns one constant-time, generic error for every failure. OAEP decoding has two internally distinct failure cases -- an integer-out-of-range or wrong leading octet, versus an octet-format or integrity failure -- and if an implementation lets them be distinguishable by code, alert, or timing, OAEP itself becomes a padding oracle: Manger's 2001 attack then recovers the plaintext in about $\log_2 n$ queries, far fewer than Bleichenbacher's $10^6$, because the leaked bit is cleaner [@manger-2001]. PSS is not what the padding oracles break; construction depth belongs to *RSA Done Right*.

The one-line takeaway is worth memorizing: OAEP done wrong is Bleichenbacher wearing different padding. Even the fix is a deployment obligation.Marvin (2023, Hubert Kario at Red Hat) is a modern timing revival of the v1.5 oracle across many libraries. Its existence and authorship are verified, but keep it at mention weight pending venue and peer-review confirmation, rather than leaning on it as a load-bearing result [@marvin-paper, @marvin-iacr-news].

Negotiation. Use TLS 1.3, which removes static RSA key exchange entirely: all key exchange is forward-secret (EC)DHE, and RSA survives only as a signature algorithm, with the rationale spelled out in the RFC's Appendix E.8, "Attacks on Static RSA" [@rfc8446]. SSLv2, export ciphers, and RSA_EXPORT are dead. Forward secrecy is the structural win here: with no RSA key transport on the wire, there is no v1.5 decryption for an oracle to be about. The deployed stacks already reflect this -- mainstream TLS libraries now default to TLS 1.3, and some, like rustls, never implemented the TLS_RSA_* transport suites at all [@rustls-manual].

Note: SSLv2, RSA_EXPORT, and PKCS#1 v1.5 all stayed live in production for a decade or more after retirement, and every one was weaponized as a live attack surface: DROWN, FREAK, ROBOT. "Harmless legacy" is a contradiction. Retiring RSA key transport is a migration, not a switch: v1.5 is still specified and ubiquitous in S/MIME, JWT and JOSE, hardware security modules, and legacy TLS, and the timing tail persists wherever v1.5 decryption survives [@marvin-paper].

"Validate generation, use OAEP and PSS, drop RSA key transport" is the whole answer for greenfield code. But engineers inherit constraints -- a device that must self-generate keys, a peer that only speaks v1.5, a fleet already in the field -- so the real question is not "what is best" but "what are my options at each layer, ranked, and exactly when does each apply?"

7. Competing Approaches: How the Field Closes Each Gap

For each of the three loci, the honest picture is competing options with real trade-offs, not a single winner.

Pillar	Option A	Option B	Option C	Main trade-off
Key generation	Hardware RNG plus entropy at boot	Derandomized key generation from a strong seed	Post-hoc structure and shared-factor testing	Prevention versus detection; they coexist
Padding	OAEP (safe only with one constant-time generic error)	Hardened uniform-error v1.5 (`RFC 5246` random premaster)	Abandon RSA encryption for (EC)DHE	Compatibility versus a clean break
Downgrade	TLS 1.3 downgrade protection and protocol retirement	Config hardening (`TLS_FALLBACK_SCSV`, disable export and SSLv2)	--	A new protocol versus patching the old one

Key generation. Three approaches coexist. A hardware RNG with guaranteed entropy at boot prevents the Debian and shared-prime failures at the source. Derandomized key generation -- deriving the primes from a single strong seed -- removes the runtime-entropy dependency entirely, at the cost of trusting that seed. And post-hoc structure and shared-factor testing (batch-GCD scanners, the ROCA detector) catches what generation missed [@factorable-2012, @roca-crocs, @fips186-5]. Measurement is the backstop for generation: ROCA and Mining Your Ps and Qs were both discovered by scanning the field, not by auditing source.

Padding. Three options, chosen by how much legacy you must carry. Fix the scheme with OAEP -- but recall Manger, that it is only misuse-safe with one constant-time generic error [@manger-2001]. Or keep v1.5 for compatibility and harden the implementation toward a uniform error, the RFC 5246 random-premaster substitution -- a twenty-five-year losing battle across error text, protocol siblings, implementation quirks, and timing [@rfc5246]. Or abandon RSA encryption for forward-secret (EC)DHE. Different deployments sit under different compatibility constraints, so all three survive in the field [@rfc8017, @robotattack].

Downgrade. Two options. TLS 1.3, with built-in downgrade protection and outright protocol and algorithm retirement, is the durable answer. For stacks that cannot move yet, configuration hardening -- TLS_FALLBACK_SCSV, disabling export ciphers and SSLv2 -- is the interim one [@rfc8446, @drown-2016].

Notice the convergence. The durable answer to both Pillar 2 and Pillar 3 is the same move: do not do RSA key transport. The clean surviving split is that RSA-for-signatures (PSS) stays first-class while RSA-for-encryption is retired.

Every one of these options changes how RSA is generated, used, or negotiated, or drops RSA key transport entirely, and each buys its safety with a specific cost -- a scan, a migration, a compatibility break, a forward-secret handshake. Which means the honest way to close the technical arc is to ask what is provably true on both sides: how little the attacker needs, and how much the defender can actually guarantee.

8. What Is Provably True on Both Sides

The thesis has two sides, and each has its own frontier. The surprise is the asymmetry: the math side is a slow, honest, well-mapped concession, and all the operationally relevant limits live in the deployment.

The math side, the honest concession. Factoring is real but slow. The Number Field Sieve runs in heuristic sub-exponential time $L_N[1/3, (64/9)^{1/3}]$, with $(64/9)^{1/3} \approx 1.923$ [@rsa240-2019], and the public record has crept forward for two decades.

Challenge	Bits	Year	Effort	Method	Deployed strong key factored?
RSA-155	512	1999	feasible in hours today	NFS	Never
RSA-768	768	2009	~1500 core-years sieving	NFS	Never
RSA-240	795	2019	~900 core-years	NFS	Never
RSA-250	829	2020	~2700 core-years	GNFS (CADO-NFS)	Never
RSA-2048	2048	--	astronomically out of reach classically	--	Never

Every row is a challenge number from the old RSA Factoring Challenge, a public target list RSA Laboratories once published [@wiki-rsa-challenge], and none was ever a deployed key [@rsa155-2000, @rsa768-epfl, @rsa768-eprint, @rsa240-2019, @rsa250-2020]. 512-bit is hours, which is exactly why FREAK works; 2048-bit is out of classical reach; and Shor's algorithm collapses all of it on a quantum computer -- a story the companion How RSA Would Break owns. Read the rightmost column top to bottom: it says Never at every row, because no strong, correctly generated, deployed modulus has ever been factored in the field.RSA-250's roughly 2700 core-years split into about 2450 for sieving and 250 for the matrix step, run on Intel Xeon Gold 6130 cores with CADO-NFS. It is a 250-digit, 829-bit challenge number, and it never protected a deployed system [@rsa250-2020].

The Heninger through-line closes here. The researcher who recovered weak keys by the thousand in Pillar 1 co-holds this record -- the slow, honest way a strong key falls [@rsa250-2020]. That is the entire weak-versus-strong distinction compressed into one career. And note the theory is not even settled in the defender's favor: there is no proof that factoring requires super-polynomial time, and the RSA-problem-versus-factoring equivalence is itself open [@boneh-1999]. Two-plus decades of open cryptanalysis is an empirical floor, not a theorem -- and it never once mattered in the field.

The deployment side, where the real limits live. Here the limits are provable-in-practice, and none is about a strong modulus's strength.

Attack	Attacked layer	Worst-case work	Needs a weak modulus?	Recovers the private key?
Padding oracle (Bleichenbacher family)	Padding	About $10^6$ queries, polynomial	No	No
Batch-GCD shared primes	Key generation	One gcd, quasi-linear over the fleet	Yes	Yes
ROCA and Coppersmith	Key generation	Lattice reduction, polynomial	Yes	Yes
FREAK downgrade then factor	Negotiation	Hours to factor 512-bit	Yes (forced)	Yes
GNFS on a strong modulus	The math itself	Sub-exponential, ~2700 core-years at 829-bit	--	Only the challenge key

Three boundaries, stated outright. First, a padding oracle needs no factoring: its query count is bounded below only by the roughly one-bit-per-conforming-reply information rate, so decryption is many queries but always polynomial, and you cannot make an observable-validity scheme require exponentially many queries [@bleichenbacher-1998, @manger-2001]. Second, a shared prime is a single gcd away and a structured prime a Coppersmith lattice away -- quasi-linear or polynomial, regardless of key size [@factorable-2012, @roca-crocs]. Third, certification is not structural testing -- the ROCA lesson from Pillar 1, where FIPS 140-2 and CC EAL5+ chips shipped structurally factorable keys for years [@roca-crocs].

Key idea: The math side is a slow, mapped concession -- an 829-bit public ceiling, and no strong deployed key ever factored. The deployment side holds the real limits: a padding oracle needs no factoring, a shared prime is one gcd, a structured prime one lattice, a downgrade one forced 512-bit key -- all independent of key size. "Strong-modulus-secure" and "system-secure" are different claims, and the gap between them is inherent, not accidental.

If the math side is a slow, mapped concession and the deployment side has hard, polynomial-cost limits, the practical frontier is obvious: it is wherever those deployment limits are still being hit in the wild. That is not a solved problem. It is an active one.

9. Where RSA Still Breaks in the Field

The math side is a slow, honest concession. The deployment side is not closed. Here are the places the same three-pillar pattern is still live, each an operational frontier, each consistent with the thesis that the weak link is a layer the math depends on, never the factoring problem.

Entropy on embedded, first-boot, and cloned systems (Pillar 1). The exact Debian and shared-prime gap, revived by cloud VM cloning and container images that reproduce identical state at key-generation time [@ristenpart-yilek-2010]. The best partial answer is FIPS 186-5 generation plus fleet batch-GCD, but coverage of cloned and containerized keys is incomplete [@factorable-2012, @fips186-5].

The PKCS#1 v1.5 long tail and timing oracles (Pillar 2). v1.5 is still specified and everywhere. Marvin (2023) showed the timing axis is still open across many libraries, tied to the working impossibility result that an observable-validity scheme cannot be patched uniformly safe, only structurally replaced [@marvin-paper, @marvin-iacr-news, @robotattack].

Protocol and algorithm-retirement lag (Pillar 3). How does a dead algorithm -- SSLv2, export RSA, v1.5 -- stay live for a decade or more? DROWN fell from 33% in 2016 to about 1.2% by 2019, and FREAK from 36.7% toward the low single digits: large but incomplete progress [@drown-2016, @freakattack]. This is a socio-technical problem, not a cryptanalytic one.

The next ROCA-class library (Pillar 1). Detecting a structurally biased generator inside certified closed hardware, before it ships millions of keys. The ROCA detector is signature-based, so a genuinely new structure would evade it [@roca-crocs].

Post-quantum signature migration ahead of Shor. This is the one future break that is the math. Key exchange is already forward-secret, but signatures need proactive migration; the mechanics belong to the post-quantum and would-break siblings.

One boundary is worth fencing so it is never miscounted as a field incident.Wiener's small-$d$ attack recovers a too-small private exponent $d < \tfrac{1}{3} n^{1/4}$ from the public key by continued fractions (1990) [@wiener-1990], and Hastad's low-exponent broadcast recovers the same unpadded low-$e$ message sent to $e$ recipients via CRT and an integer $e$-th root (1988) [@hastad-1988]. Both are real, but they are parameter-choice, theoretical breaks -- the canonical argument for randomized padding -- not documented field incidents. They belong to How RSA Would Break. Parameter-choice attacks on deliberately bad exponents are a different genre from the deployment failures cataloged here.

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

10. What to Do on Monday

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

flowchart TD E{"Real entropy before keygen?"} -->|No| E1["Stop. Seed first. Never generate at unseeded boot."] E -->|Yes| K["FIPS 186-5 generation, 2048-bit or larger"] K --> SCAN{"Batch-GCD and ROCA detector"} SCAN -->|Flagged| REV["Regenerate and revoke"] SCAN -->|Clean| ENC{"Need RSA encryption?"} ENC -->|Yes| OAEP["OAEP, one constant-time generic error"] ENC -->|No| DHE["Prefer (EC)DHE, TLS 1.3"] OAEP --> SIG["Signatures: RSA-PSS, plan PQC"] DHE --> SIG SIG --> NEG["Disable SSLv2, export, and RSA_EXPORT, add downgrade protection"]

Key generation. Guarantee real entropy before the first key is generated; follow FIPS 186-5; never generate keys at unseeded first boot; use a 2048-bit minimum with validated generation; and run batch-GCD and the ROCA detector across your keys and CT logs, regenerating or revoking anything flagged. This prevents Debian enumeration, shared primes, and ROCA [@fips186-5, @factorable-2012, @roca-crocs].

Padding and encryption. Never use raw PKCS#1 v1.5. If you must do RSA encryption, use OAEP with constant-time, uniform-error handling -- one generic error, per Manger; better still, prefer (EC)DHE forward secrecy and drop RSA key transport, which TLS 1.3 does for you. This prevents Bleichenbacher, DROWN, ROBOT, and Marvin [@rfc8017, @manger-2001, @rfc8446].

Signatures. Use RSA-PSS, which is not what the oracles break, and plan the post-quantum signature migration ahead of Shor [@rfc8017].

Negotiation. Disable SSLv2, export ciphers, and RSA_EXPORT; enable downgrade protection; prefer TLS 1.3 over 1.2. This prevents FREAK and DROWN's SSLv2 channel [@rfc8446, @drown-2016].

Do this...	...and you reproduce	The fix
Generate keys at unseeded first boot	Debian enumeration, shared primes	Real entropy before keygen; batch-GCD
Trust a certified black box as structurally safe	ROCA	ROCA detector; regenerate
Reveal padding validity by error, reset, timeout, or timing	Bleichenbacher, DROWN, ROBOT, Marvin	Uniform constant-time errors; OAEP; drop RSA transport
Reuse one RSA key across protocols	DROWN, via SSLv2	Separate keys; disable SSLv2
Leave export ciphers or SSLv2 live	FREAK, DROWN	Remove export and SSLv2; downgrade protection
Assume "2048-bit means safe"	Every non-factoring break	Secure all three layers, not the key size

The batch-GCD check is not just an attacker's tool; it is your fleet audit. Run it against your own moduli:

{const gcd = (a, b) => { while (b) { [a, b] = [b, a % b]; } return a; }; // Public moduli scraped from your own devices or CT logs. const fleet = { 'host-a': 63900000000000000000000000000000000000000000002625100000000000000000000000000000000000000000026931n, 'host-b': 74700000000000000000000000000000000000000000003196300000000000000000000000000000000000000000034189n, 'host-c': 35510000000000000000000000000000000000000000001968800000000000000000000000000000000000000000010257n, 'host-d': 18130000000000000000000000000000000000000000001447800000000000000000000000000000000000000000026649n, }; const names = Object.keys(fleet); let flagged = 0; for (let i = 0; i < names.length; i++) { for (let j = i + 1; j < names.length; j++) { const g = gcd(fleet[names[i]], fleet[names[j]]); if (g > 1n) { flagged++; console.log('WEAK PAIR:', names[i], '&', names[j], '-> shared factor', g.toString()); } } } console.log(flagged ? ('Regenerate and revoke ' + flagged + ' compromised pair(s).') : 'No shared factors found.');}

To feed real keys in, extract each modulus first with a one-liner like `openssl x509 -in cert.pem -noout -modulus`, collect them into the list above, and run it. Any pair with a gcd greater than 1 is a compromised pair: regenerate and revoke both, then find out why two devices drew the same prime.

Note: One: validated high-entropy, structure-checked key generation (FIPS 186-5) plus fleet batch-GCD and ROCA scans. Two: OAEP for encryption and PSS for signatures with uniform, constant-time errors -- or, better, drop RSA key transport for (EC)DHE. Three: TLS 1.3, with SSLv2, export ciphers, and RSA_EXPORT disabled.

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

11. Misconceptions, Precisely Corrected

The paradox survives mostly because a few plausible, wrong statements keep getting repeated. Here they are, corrected, each answer tied back to a catalog entry and the three-pillar thesis.

Only *weak* keys: 512-bit export keys (FREAK), shared-prime keys, and ROCA-structured keys. The public *challenge* ceiling is the 829-bit RSA-250, which took about 2,700 core-years in 2020. No strong, correctly generated, deployed modulus has ever been factored [@rsa250-2020, @freakattack]. No. It is a decryption or signing *oracle*: the attacker decrypts one session or forges one signature, but the key is never extracted and the modulus is never factored [@robotattack, @bleichenbacher-1998]. No -- it is a different scheme. The padding oracle is on v1.5 *encryption*. PSS signatures, and even v1.5 signatures, are not what falls. Keep the two constructions distinct [@rfc8017]. No. RSA signing has no secret per-signature nonce. The per-signature $k$-reuse break behind the PlayStation 3 and Android incidents is an (EC)DSA phenomenon, told in its own article [@ps3-epic-fail-2010, @bitcoin-android-alert-2013]. Not for padding oracles, shared or structured primes, or downgrade -- those are deployment defects, independent of key size. Size only matters against brute factoring, which is exactly why 512-bit export was fatal and a strong key is not [@factorable-2012, @roca-crocs]. Not necessarily. ROCA's keys were CC EAL5+ certified; certification tested the RNG, not the public-key *structure*, and roughly 760,000 factorable keys shipped anyway [@roca-crocs]. The primitive, no. But stop using RSA key transport and raw PKCS#1 v1.5, prefer forward-secret (EC)DHE and OAEP or PSS, and plan the post-quantum signature migration ahead of Shor [@rfc8446, @rfc8017].

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

To Break RSA in the Field, You Never Factor a Strong Modulus

Return to the opening paradox, now resolved. The public factoring ceiling is an 829-bit challenge number that cost about 2,700 core-years, and no strong deployed key has ever fallen to it [@rsa250-2020]. And yet national ID cards were forgeable, a third of HTTPS was decryptable, embedded keys were recoverable, and sessions were man-in-the-middled -- because every one of those breaks happened at a layer the factoring problem knows nothing about.

The primes were weak before the math began: Debian, shared primes, ROCA. The padding check was an oracle: Bleichenbacher, DROWN, ROBOT. The negotiation forced a crippled key: FREAK. Three layers, seven deployed field breaks, and the factoring problem on a strong modulus untouched in all of them. RSA-250, the eighth row of the catalog, is the ceiling -- a strong-but-undeployed challenge number, not a field break.

Every fix changed how RSA is generated, used, or negotiated -- validated entropy and structure tests, OAEP and PSS and uniform errors, dead export and SSLv2 and TLS 1.3 -- never RSA. And where three incidents did end in a factorization, the deployment had already produced a weak modulus, so the math merely finished a job it had been handed.

When your RSA keys fall, don't ask whether someone factored the modulus. Ask which layer the math depends on but does not control gave way: the primes, the padding, or the negotiation.

One last time, keep the hedge honest: almost never, not never. Factoring is real and fell RSA-512, RSA-768, and RSA-250 as challenge numbers, and Shor's algorithm is coming for strong keys on a quantum computer -- but that is the story How RSA Would Break tells, and the constructive OAEP and PSS depth belongs to RSA Done Right.

The factoring problem was never the weak link in the field, and no bigger key would have saved a single one of these deployments. That is why this is Part 3 of a series about how things break in real life, not a chapter on the Number Field Sieve.

RSA Is a Trapdoor, Not a Cryptosystem: OAEP, PSS, and the 25-Year Padding-Oracle Lineage

noreply@paragmali.com (Parag Mali) — Sat, 11 Jul 2026 09:07:03 GMT

**RSA is a trapdoor permutation, not a cryptosystem** -- and almost every real-world RSA break came from treating the bare trapdoor as if it were already secure. Textbook RSA is deterministic and malleable. PKCS#1 v1.5 *encryption* turns "is this padding valid?" into a decryption oracle that leaked through ever-quieter channels for 25 years, from Bleichenbacher (1998) [@bleichenbacher98] through DROWN [@drown16] and ROBOT [@robot18] to Marvin's pure-timing attack (2023) [@marvin23]. "Done right" is a stack that must all hold at once: the right scheme (**OAEP** for encryption, **PSS** for new signatures), the right parameters (2048-bit floor, `e = 65537`, CSPRNG primes), and a **constant-time, fault-checked implementation** -- because security is a property of the scheme *and* its implementation, not of the math. And keep one split absolute: v1.5 *signatures* are unbroken and still dominant (verify strictly), while v1.5 *encryption* must be retired.

1. The Modulus Was Never Factored

In 2018, three researchers signed a message with the private key behind facebook.com's TLS certificate [@robot18]. They never factored Facebook's 2,048-bit modulus. Nobody has ever publicly factored a 2,048-bit modulus -- the public record stands at 829 bits, and that took roughly 2,700 core-years [@rsa250].

Instead, they asked one of Facebook's front-end servers the same yes-or-no question a few hundred thousand times -- is this padding valid? -- and let the pattern of answers spell out the secret [@robot18]. The attack they used was already nineteen years old [@robotsite]. Five years later, a Red Hat engineer reproduced the same break against software that was supposed to be immune, using nothing but a stopwatch, and called it Marvin [@marvin23].

Notice what did not happen. No prime was recovered. No number was factored. The RSA problem -- invert c = m^e mod N without the private key -- stood exactly as hard the day after as the day before. What broke was the server's reaction: the way it answered a question about a ciphertext it did not create.

That is the whole subject in one sentence. Textbook RSA -- the bare m^e mod N you meet in a first course -- is a trapdoor permutation, not a cryptosystem. It is a beautiful one-way function with a secret shortcut, and nothing more.

Everything that turns it into secure encryption or a secure signature lives around the permutation, in the padding, the parameters, and the code that runs the operation. Almost every famous RSA disaster of the last three decades is a variation on one theme: someone used the bare trapdoor as if it were already a cryptosystem, or let the machinery meant to secure it confess -- through an error message, a network timeout, a microsecond of timing, or an injected fault -- whether a check had passed.

The math was never broken. The padding check told the attacker whether it passed.

So here is the diagnostic question this article keeps asking, the one that unlocks the entire failure catalog: when a ciphertext or signature it did not create arrives, what does the receiver reveal about it -- through its answer, its timing, or its faults -- before and after it has checked the padding? Four names you may know as headlines -- Bleichenbacher, DROWN, ROBOT, Marvin -- are four answers to that question, each leaking the same single bit through a quieter channel than the last. To see why one yes-or-no question about padding is enough to reconstruct a session key, you first have to see what RSA actually is, and what it is not.

2. A Trapdoor for Diffie-Hellman's Challenge

In 1976, Whitfield Diffie and Martin Hellman wrote down the shape of a future that did not yet have an engine. Their paper New Directions in Cryptography described public-key encryption and, remarkably, the idea of a digital signature -- a value only you can produce but anyone can check [@dh76]. What they could not supply was a concrete trapdoor: a function easy to compute in one direction, hard to invert, yet effortless to invert if you hold a secret. Their paper is a challenge with a hole in it, and the hole is shaped exactly like RSA.

A year later, Ron Rivest, Adi Shamir, and Leonard Adleman filled it. Pick two large primes $p$ and $q$ and set $N = pq$. Choose a public exponent $e$, and compute a private exponent $d$ with $ed \equiv 1 \pmod{\lambda(N)}$. Publish $(N, e)$; keep $d$, $p$, and $q$ secret. To encrypt a message represented as a number $m < N$, raise it to the public exponent; to decrypt, raise the result to the private one [@rsa78]:

$$c = m^e \bmod N, \qquad m = c^d \bmod N.$$

Why does the second operation undo the first? Because of Euler's theorem (1763): for any $m$ coprime to $N$, $m^{\phi(N)} \equiv 1 \pmod N$, with the totient $\phi(N) = (p-1)(q-1)$. Its Carmichael-function refinement (Carmichael, 1910) gives the same identity for the smaller $\lambda(N) = \mathrm{lcm}(p-1, q-1)$. Since $ed \equiv 1 \pmod{\lambda(N)}$, we have $ed = 1 + k\lambda(N)$ for some integer $k$, so $c^d = m^{ed} = m \cdot (m^{\lambda(N)})^k \equiv m \pmod N$. The exponents cancel, and the plaintext falls out -- but only for someone who could compute $d$, and computing $d$ requires $\lambda(N)$, which requires the factors of $N$. That is the trapdoor: the factorization of $N$ is the secret that inverts the permutation.The original 1978 paper used $\phi(N) = (p-1)(q-1)$, Euler's totient. Modern standards use the smaller Carmichael function $\lambda(N) = \mathrm{lcm}(p-1, q-1)$, which yields a smaller valid $d$ and the same correctness. Either works; $\lambda(N)$ is now the convention in FIPS 186-5.

A function that is easy to evaluate in the forward direction, computationally hard to invert without a secret, and easy to invert with it. RSA's forward map is x maps to x raised to the e, modulo N; the trapdoor that inverts it is the factorization of N. A trapdoor permutation is a primitive, not a complete encryption scheme -- it says nothing about hiding partial information or resisting tampering.

The elegance that made RSA famous is that the same operation both encrypts and signs. Swap the roles of the exponents: to sign a message, raise it to the private exponent, $s = m^d \bmod N$, an act only the key holder can perform; to verify, raise the signature to the public exponent and check that $s^e \equiv m \pmod N$, which anyone can do [@rsa78]. One modular exponentiation, read in two directions, is both a lock only you can open and a seal only you can stamp. Boneh's survey calls this duality the source of both RSA's reach and its long catalogue of misuse [@boneh99].

Two engineering choices from this era matter later, because each returns as an attack surface. The first is the public exponent. Almost every deployed RSA key uses $e = 65537$.65537 is the Fermat prime $F_4 = 2^{16} + 1$. Written in binary it is 1 followed by fifteen 0s and a final 1 -- a Hamming weight of just 2 -- so public-key operations cost only sixteen squarings and one multiplication. Small enough to be fast, large enough to dodge the low-exponent traps of $e = 3$. The second is how the private operation is computed. Rather than one exponentiation modulo $N$, implementations work modulo $p$ and modulo $q$ separately and recombine, using the Chinese Remainder Theorem for roughly a fourfold speedup.

A technique for computing the private operation c raised to the d, modulo N, by working separately modulo p and modulo q on half-size numbers and then recombining the two halves. It cuts the cost of decryption and signing by about four times. Because it splits the secret operation across the two prime factors, it also opens a physical-fault attack surface that the single-modulus form does not have.

Hold those two choices in mind: the small public exponent and the CRT shortcut will each come back to bite an implementation that treats them casually. But the deepest seed was planted in the 1978 paper itself, and it was invisible at the time.

Rivest, Shamir, and Adleman demonstrated the trapdoor on raw message numbers. That bare application is deterministic, algebraically malleable, and carries structure an attacker can exploit -- three properties that, in 1978, looked like harmless features of a clean mathematical object. One operation, elegant enough to both lock and sign. So why is calling that operation directly -- what cryptographers now dismiss as "textbook RSA" -- treated as a bug in every serious codebase?

3. Why Textbook RSA Is Not a Cryptosystem

Encryption has a minimum bar -- lower than most people think -- and textbook RSA fails to clear it. The bar is called IND-CPA: an adversary who picks two plaintexts and receives the encryption of one cannot tell which, better than a coin flip. (Part 1 of this series builds that definition carefully; here we only need its consequences.) Bare RSA loses this game three separate ways, each a direct consequence of the naked permutation.

It is deterministic. The same plaintext always encrypts to the same ciphertext, because $m^e \bmod N$ is a function with no randomness in it. That is fatal whenever the message space is small or guessable. Suppose a server encrypts a one-word trading instruction, either BUY or SELL, under a known public key. An eavesdropper does not need to decrypt anything: they encrypt both candidate words, compare against the captured ciphertext, and read the plaintext with zero queries. Determinism can never be semantic security -- this is structural, not a missing optimization you can bolt on later.

It is malleable. RSA is multiplicatively homomorphic: multiply a ciphertext by $k^e$ and the plaintext is silently multiplied by $k$.

A cipher is malleable when an attacker can transform a ciphertext into another valid ciphertext whose plaintext is a predictable function of the original -- without decrypting anything. RSA satisfies the multiplicative relation: the encryption of m times the encryption-form of k decrypts to m times k, modulo N. Useful for some protocols, catastrophic for confidentiality, and the exact algebraic lever Bleichenbacher later pulls.

That relation is not a curiosity; it is the crowbar behind the entire padding-oracle lineage. The demonstration below uses toy primes so the arithmetic is legible in a browser, but the algebra is identical at 2,048 bits.

{` // Toy RSA: p=61, q=53, N=3233, e=17, d=2753. NOT secure sizes -- for illustration. function modpow(base, exp, mod) { base = base % mod; let r = 1n; while (exp > 0n) { if (exp & 1n) r = (r * base) % mod; base = (base * base) % mod; exp >>= 1n; } return r; } const N = 3233n, e = 17n, d = 2753n; const m = 42n;

// 1) Deterministic: encrypting the same message twice gives the same ciphertext. const c1 = modpow(m, e, N), c2 = modpow(m, e, N); console.log('encrypt 42 twice ->', c1.toString(), c2.toString(), '| identical?', c1 === c2);

// 2) Malleable: multiply the ciphertext by k^e and the plaintext scales by k. const k = 2n; const cForged = (c1 * modpow(k, e, N)) % N; // attacker never decrypts const mForged = modpow(cForged, d, N); // what the victim would recover console.log('tampered ct decrypts to', mForged.toString(), '= (42*2) mod N =', ((m * k) % N).toString()); `}

It leaks structure for small exponents and short messages. If a message is short enough that $m^e < N$, no modular reduction ever happens, so recovering $m$ is a plain integer $e$-th root -- no factoring required.

Johan Hastad showed in 1988 that if the same message is broadcast to $e$ recipients under $e = 3$, the plaintext falls out by the Chinese Remainder Theorem [@hastad88]. Don Coppersmith sharpened this in 1996 into a lattice method that recovers a message whenever the unknown part is smaller than $N^{1/e}$, breaking "stereotyped" messages with a small hidden field [@coppersmith97]. Every one of these is an attack on textbook RSA, not on the RSA problem itself -- the factoring assumption stays intact while the plaintext walks out the front door [@boneh99].

So a trapdoor permutation is not a cryptosystem. To become one, it needs a transformation applied to the message before the permutation -- padding -- and that padding has to do three separable jobs.

Key idea: A trapdoor becomes a cryptosystem only when the padding does three separable jobs: (1) add randomness, so equal plaintexts produce different ciphertexts; (2) add checkable redundancy, so the receiver can detect a tampered or malformed ciphertext; and (3) -- the job the field kept forgetting -- be implemented so that no observable behaviour reveals whether that check passed.

The first two jobs are about the scheme. The third is about the implementation, and the entire history of RSA breaks is the field learning, over and over, that the third job is not optional. Hold that third clause; it is the trap the next section springs.

Note: If your code invokes a modular-exponentiation "textbook RSA" function directly on a message -- no OAEP, no PSS, no padding layer -- it is broken before it ships. Every serious library hides the bare permutation precisely so that no application accidentally uses it as encryption or a signature.

The first widely deployed answer to those three jobs was PKCS#1 version 1.5, specified by RSA Laboratories in the early 1990s and republished as RFC 2313 in 1998 [@rfc2313]. For encryption, it wraps the message as 0x00 || 0x02 || PS || 0x00 || M, where PS is at least eight nonzero random bytes -- that random padding supplies job one [@rfc8017]. For signatures it uses a different, fixed frame, 0x00 || 0x01 || 0xFF...0xFF || 0x00 || DigestInfo, whose rigid structure supplies job two [@rfc8017].

On paper it fixed textbook RSA's two headline problems: the random bytes killed determinism, and the fixed structure gave the receiver something to check. For five years, it looked as if PKCS#1 v1.5 had turned the trapdoor into a cryptosystem. The structure was supposed to add security. In 1998, Daniel Bleichenbacher showed that the structure was the vulnerability.

4. The Atom and Its Echoes: The Encryption Padding-Oracle Lineage

Before the detailed walk, here is the whole story on one timeline -- two intertwined tracks, the schemes on one side and the breaks on the other, with each break forcing the next response.

timeline title RSA schemes and their breaks, 1976 to 2026 1977 : RSA trapdoor answers the Diffie-Hellman challenge 1990 : Wiener breaks small private exponents 1993 : PKCS#1 v1.5 padding deployed 1997 : Bellcore CRT fault factors N from one signature 1998 : Bleichenbacher padding oracle : OAEP standardized in response 2001 : Manger reopens the oracle inside OAEP decoders 2003 : Remote timing attacks proven practical : PSS standardized 2016 : DROWN revives the oracle through SSLv2 2017 : ROCA factors structured Infineon keys 2018 : ROBOT signs with the facebook.com key : TLS 1.3 deletes RSA key exchange 2023 : Marvin recovers keys by timing alone 2024 : NIST IR 8547 sets the quantum retirement clock 2025 : CFRG draft moves to deprecate v1.5 encryption

Bleichenbacher's insight was not about RSA the mathematics at all. It was about a server's manners. A TLS server in the 1990s received an RSA-encrypted pre-master secret, decrypted it, and checked whether the result had valid PKCS#1 v1.5 padding -- did it start with the bytes 0x00 0x02, with a nonzero pad and a delimiter in the right place? If not, it returned an error. That error, however polite, answered a question the attacker was not supposed to be able to ask: was this the encryption of a well-formed message? And because RSA is malleable, the attacker could turn that one bit of feedback into a full decryption.

Here is the mechanism. The attacker holds a target ciphertext $c$ that encrypts an unknown $m$ -- say, a captured TLS session key. They pick a value $s$, compute $c \cdot s^e \bmod N$, and send it to the server. By the homomorphic property, the server is really decrypting $m \cdot s \bmod N$. If the server reports valid padding, the attacker learns that $m \cdot s \bmod N$ begins with 0x00 0x02 -- which means it lies in the interval $[2B, 3B)$, where $B = 2^{8(k-2)}$ for a $k$-byte modulus.

Each conforming $s$ is a linear inequality on the secret $m$. Collect enough of them, adaptively choosing each new $s$ to bisect the surviving range, and the interval of possible $m$ collapses to a single value. Bleichenbacher's 1998 paper showed this takes on the order of $2^{20}$ -- about a million -- queries for a 1,024-bit key, and the private key is never touched [@bleichenbacher98].

sequenceDiagram participant A as Attacker participant S as Decrypting server Note over A: Holds target ciphertext c, wants secret m A->>S: Submit c times s to the e, for chosen s S->>S: Decrypt and check PKCS#1 v1.5 padding alt Decrypted value starts with 00 02 S-->>A: Conforming, no error or fast reply Note over A,S: Attacker learns m times s mod N is in 2B to 3B else Padding invalid S-->>A: Non-conforming, error, alert, or slow reply end Note over A: Narrow the possible range of m, choose next s A->>S: Repeat, roughly a million queries in total Note over A: Range collapses to one value, plaintext m recovered

A generation of engineers filed this under "performance" or "obscure edge case." It is neither. It is a correctness and security failure of the construction: the receiver's validity check, exposed through any observable side effect, is a decryption oracle for chosen ciphertexts. That is the symmetric-side padding-oracle attack of Part 6, transplanted to public-key land -- the same disease, a different organ.

Any observable behaviour -- an error message, a network reset, an injected fault, or a difference in response time -- that reveals whether a decrypted ciphertext had valid padding. Because the attacker chooses the ciphertexts, a padding-validity signal becomes a decryption oracle: enough yes-or-no answers reconstruct the plaintext without ever recovering the private key.

The break violates the strongest standard security goal for encryption, IND-CCA2, in which the adversary may submit chosen ciphertexts to a decryption oracle and still must not learn anything about a challenge plaintext.

The security goal a padding oracle destroys: an adversary who can submit arbitrary ciphertexts for decryption still cannot distinguish which of two chosen plaintexts a challenge ciphertext encrypts. PKCS#1 v1.5 encryption fails this because its validity check leaks. Part 1 of this series develops the full definition.

The scheme-level fix arrived almost immediately. In direct response to Bleichenbacher, RSA Laboratories standardized a new encryption padding, RSAES-OAEP, in PKCS#1 v2.0 (RFC 2437) later in 1998 [@rfc2437]. OAEP's design goal, spelled out in Section 6, is that any tampered ciphertext decodes to unstructured noise, so there is no "conformant" interval left to test -- the oracle has nothing to grade. It fixed the scheme. What it did not, and could not, fix by itself was the decoder.

James Manger proved that in 2001. OAEP's decoding has two distinct early failure modes: the recovered integer can be too large to fit the byte block, or it can fit but fail the padding check. A decoder that distinguishes those two cases through different errors or different timing hands the attacker a new oracle -- and Manger's variant is dramatically cheaper than Bleichenbacher's, needing on the order of $\log_2 N$ queries, roughly 2,048 for a 2,048-bit key, instead of $2^{20}$ [@manger01]. OAEP, the provably secure scheme, re-opened the identical class of attack through an imperfect implementation. The lesson the field wrote down, and then kept having to re-learn, was not "use OAEP." It was "use OAEP and decode it in constant time."

If Bleichenbacher's attack is the atom, the next quarter-century is three quieter echoes of it -- the same leaked bit, reached through channels that get progressively harder to see.

DROWN (2016): a cross-protocol channel. By 2016, TLS servers had long since patched the obvious padding-error message. But many still supported SSLv2, an obsolete protocol from the 1990s, often on a different service such as a mail server -- and often with the same RSA key. DROWN showed that an attacker could use the weak, deliberately export-crippled SSLv2 endpoint as the padding oracle, then use its answers to decrypt a modern TLS session that shared the key.The DROWN team measured that roughly 33 percent of all HTTPS servers were vulnerable at disclosure in March 2016, because key reuse across a TLS service and a forgotten SSLv2 service was rampant [@drownsite]. The math of the oracle was 1998's; only the delivery was new [@drown16].

ROBOT (2018): the same oracle, nineteen years on. Hanno Bock, Juraj Somorovsky, and Craig Young revisited the original attack and found it alive across the modern internet. The padding-error message was gone, but the oracle now leaked through subtler tells: a TCP reset here, a connection timeout there, a duplicated alert message somewhere else -- any behaviour that differed between conforming and non-conforming padding. It affected almost a third of the top 100 domains, including Facebook and PayPal, and traced to products from F5, Citrix, Radware, Palo Alto Networks, IBM, and Cisco [@robot18].To make the point unmissable, the ROBOT authors used the recovered oracle to sign a message with the private key behind facebook.com's certificate -- a decryption oracle repurposed to forge a signature, without ever touching the factorization [@robotsite].

Marvin (2023): pure timing, no error at all. The quietest channel yet removes the error entirely. Hubert Kario's Marvin attack observes only the time the decryption operation takes, since a conforming and a non-conforming padding often run through subtly different code paths. No alert, no reset, no message -- just a stopwatch. Marvin re-found exploitable leaks in implementations that had been declared immune after ROBOT, and it reaches well beyond TLS into S/MIME, JSON Web Tokens, and hardware tokens such as HSMs and smartcards [@marvin23]. The peer-reviewed write-up appeared at ESORICS 2023 under the fitting title Everlasting ROBOT [@eprint2023]. Its recommendation was blunt: stop using PKCS#1 v1.5 encryption.

Note: Every member of this lineage leaks the same single bit -- was the padding valid? -- through a different channel. You cannot patch your way to safety one channel at a time, because the next channel is always quieter than the last. The only durable fixes are structural: remove the mode (as TLS 1.3 did) or forbid it (as FIPS did). If a standard forces RSA encryption, use OAEP with constant-time decoding, never v1.5.

Read the four together and the pattern is impossible to miss. The channel gets quieter each time -- an error string in 1998, a cross-protocol zombie in 2016, a TCP quirk in 2018, a bare microsecond in 2023 -- but the leaked bit never changes. This is why "add more padding" was never the answer and constant-time, uniform-failure decoding was. The catalog below is the evidence for this article's whole argument: every row is some party using the bare trapdoor as if it were a scheme, or letting a check confess.

Attack	Year	Front	Leaked channel	Root cause	The rule it teaches
Textbook RSA [@rsa78]	1978	Encryption	None needed	Deterministic, malleable bare permutation	Never encrypt with the raw primitive
Hastad / Coppersmith [@hastad88, @coppersmith97]	1988 / 96	Params	Algebraic structure	Small e, short or related messages	Pad first, use e equals 65537
Bleichenbacher [@bleichenbacher98]	1998	Encryption	Padding-error message	v1.5 validity check is a decryption oracle	Uniform, unobservable failure
Manger [@manger01]	2001	Implementation	Error-type or timing split	Non-constant-time OAEP decode	OAEP AND constant-time decoding
DROWN [@drown16]	2016	Encryption	SSLv2 cross-protocol	Same RSA key on a weak zombie protocol	Never reuse keys, kill SSLv2
ROBOT [@robot18]	2018	Encryption	TCP reset, timeout, alert	v1.5 oracle still live behind subtle tells	Remove v1.5 key exchange
Marvin [@marvin23]	2023	Implementation	Decryption timing only	Non-constant-time v1.5 depadding	Retire v1.5 encryption entirely
e equals 3 forgery [@cve2006]	2006	Signature	None, forged offline	Lax verifier ignores trailing bytes	Verify strictly, parse it all
BERserk [@cve2014]	2014	Signature	None, forged offline	NSS mis-parses ASN.1 lengths	Verify strictly, re-encode and compare
Bellcore fault [@bdl97]	1997	Implementation	One faulty signature	CRT fault reveals a prime by gcd	Verify signature before release
Kocher, Brumley-Boneh [@kocher96, @brumleyboneh03]	1996 / 2003	Implementation	Exponentiation timing	Secret-dependent modexp time	Base blinding, constant time
Wiener [@wiener90]	1990	Params	Public key structure	Private exponent d too small	Never shrink d for speed
Mining Ps and Qs [@miningpq12]	2012	Params	Shared prime factors	Low boot-time entropy at keygen	Seed the CSPRNG properly
ROCA [@roca17]	2017	Params	Public modulus structure	Infineon's structured primes	Generate primes uniformly

Fourteen rows, one disease. But the encryption oracle is only one of four ways the bare trapdoor betrays its owner. The other three -- the lazy verifier, the glitched chip, and the badly chosen numbers -- are just as instructive, and one of them factors your modulus from a single fault.

5. The Rest of the Catalog: Signatures, Faults, and Bad Primes

If the encryption oracle is the trapdoor leaking through the decryptor's answer, the remaining breaks are the trapdoor leaking through the verifier's laziness, the hardware's faults, and the numbers you fed it. Three fronts, and the encryption-versus-signature split stays absolute across all of them.

Front A: the signature track, and the precision that governs it

Start with a fact that surprises people who lump all of v1.5 together: RFC 8017 records no known attack against the RSASSA-PKCS1-v1_5 signature scheme itself [@rfc8017]. Unlike v1.5 encryption, the signature padding has never been broken as a construction. It rests on a heuristic argument rather than a tight proof, which is why cryptographers reach for PSS in new designs, but it is legacy-not-broken. Where it is fragile is at the verifier -- and that fragility has bitten twice.

The $e = 3$ forgery (2006, CVE-2006-4339). Daniel Bleichenbacher -- the same name, a different result eight years later -- described a forgery that needs no private key at all. A v1.5 signature block ends with the ASN.1 DigestInfo structure, and a lazy verifier checks that the high-order bytes look right without confirming that the DigestInfo sits flush against the end with no trailing data.

With a small public exponent such as $e = 3$, an attacker can construct a number whose cube reproduces the correct prefix and hash in the leading bytes, then pack arbitrary garbage into the trailing bytes the verifier never inspects. Because cubing is cheap and the low bytes are free, the forged "signature" is just a carefully chosen cube root [@cve2006]. OpenSSL's advisory of 5 September 2006 traced it to exactly that omission: "not checking for excess data" after the exponentiation [@openssl2006].

BERserk (2014, CVE-2014-1568). Eight years on, the same antipattern returned in a different guise. Mozilla's NSS library mis-parsed ASN.1 length fields during signature verification, letting an attacker smuggle forged content past the check and produce signatures that NSS -- and therefore Firefox and Chrome builds of the era -- accepted as valid, including for TLS certificates [@cve2014]. Once again, no scheme was broken; a verifier was.

The recurring lesson is one line: verify strictly. Parse the entire structure, reject any trailing data, re-encode the expected block and compare it byte-for-byte, and never take an $e = 3$ shortcut. The provable alternative, PSS, removes the temptation to hand-roll a lenient check by making the encoding randomized and its verification total; its mechanism is in the next section [@pss96]. These verifier bugs live where v1.5 signatures live -- inside the X.509 and PKI machinery that Part 4 of this series covers.

"Still-deployed PKCS#1 v1.5" hides two opposite truths, and conflating them is the single most common error in RSA writing. v1.5 *encryption* (RSAES-PKCS1-v1_5) is fundamentally dangerous padding: its validity check is a decryption oracle, and it should be retired. v1.5 *signatures* (RSASSA-PKCS1-v1_5) are dominant across Web PKI, FIPS-approved in FIPS 186-5, and unbroken as a scheme -- keep them where mandated and verify strictly [@rfc8017], [@fips1865]. One phrase must never carry both meanings. When you read "RSA v1.5 is broken," ask which one, because the honest answer is "the encryption, not the signatures."

Front B: the physical layer

Here the secret is the factorization, so anything the hardware leaks about the private operation leaks the factors directly.

The CRT fault (Boneh, DeMillo, and Lipton, 1997). Recall that fast RSA signing computes the result modulo $p$ and modulo $q$ separately, then recombines. Suppose a single bit flips during the modulo-$p$ half -- from a voltage glitch, a clock fault, cosmic radiation, or a deliberate injection. The faulty signature $s'$ is now correct modulo $q$ but wrong modulo $p$. Then $s'^e - m$ is divisible by $q$ but not by $p$, so a single $\gcd(s'^e - m, N)$ hands you $q$ -- and the modulus is factored from one faulty signature [@bdl97]. The demonstration below does exactly that with toy primes.

{` // Bellcore fault: a fault in one CRT half leaks a prime of N. Toy primes for clarity. function modpow(base, exp, mod) { base = ((base % mod) + mod) % mod; let r = 1n; while (exp > 0n) { if (exp & 1n) r = (r * base) % mod; base = (base * base) % mod; exp >>= 1n; } return r; } function gcd(a, b) { while (b) { const t = a % b; a = b; b = t; } return a; } const p = 61n, q = 53n, N = p * q, e = 17n, d = 2753n; const m = 123n % N; // message representative to sign const dp = d % (p - 1n), dq = d % (q - 1n); const qInv = modpow(q, p - 2n, p);

// Correct CRT signature (Garner recombination): const sp = modpow(m, dp, p), sq = modpow(m, dq, q); const s = (sq + q * (((qInv * (sp - sq)) % p + p) % p)) % N; console.log('correct signature verifies?', modpow(s, e, N) === m);

// A fault corrupts ONLY the mod-p half: const spBad = (sp + 1n) % p; const sBad = (sq + q * (((qInv * (spBad - sq)) % p + p) % p)) % N; console.log('faulty signature verifies?', modpow(sBad, e, N) === m);

// One gcd factors the modulus: const diff = ((modpow(sBad, e, N) - m) % N + N) % N; console.log('gcd(sBad^e - m, N) =', gcd(diff, N).toString(), '-> a secret prime of N (61 or 53)'); `}

The fix is a single line of discipline: verify before release. Recompute $s^e \bmod N$ and confirm it equals $m$ before the signature ever leaves the chip. A faulty signature never escapes, and the gcd trick has nothing to work with.

Timing (Kocher, 1996; Brumley and Boneh, 2003). Paul Kocher observed in 1996 that the time to compute $c^d \bmod N$ depends on the secret bits of $d$, because square-and-multiply does extra work on 1 bits [@kocher96]. Folklore held that timing attacks needed local access. David Brumley and Dan Boneh demolished that in 2003 by recovering an OpenSSL server's private key over a network, measuring only response times [@brumleyboneh03].

The fix is base blinding: multiply the input by $r^e$ for a fresh random $r$ before exponentiating, then divide the result by $r$ afterward, so the timing depends on a value the attacker cannot predict. OpenSSL turned blinding on by default in 2003. Marvin, from the previous section, is this front's 2023 revival -- the timing channel never truly closed.

Front C: the parameters

The trapdoor is only as strong as the numbers behind it.

Wiener (1990). If you shrink the private exponent for speed so that $d < \tfrac{1}{3} N^{1/4}$, a continued-fraction expansion of $e/N$ recovers $d$ outright [@wiener90]. You cannot buy decryption speed by making the secret small.
Coppersmith (1996 to 1997). His lattice method sets the barrier $|x| < N^{1/e}$ that both enables low-exponent attacks on short or stereotyped messages and bounds them -- the same result that returns, weaponized, as ROCA [@coppersmith97].
Mining Your Ps and Qs (2012). Heninger and colleagues scanned the internet's public keys and computed pairwise gcds. Devices that generated keys at first boot, before they had gathered entropy, sometimes shared a prime -- and a shared prime means a free gcd factors both moduli. They computed private keys for about 0.50 percent of TLS hosts and 0.03 percent of SSH hosts this way [@miningpq12].
ROCA (2017, CVE-2017-15361). Infineon's key-generation library built primes with a special structure to speed things up. That structure let a Coppersmith attack factor the public modulus for a practical cost, and the affected chips were everywhere: TPMs, YubiKey 4 tokens, national electronic ID cards, and BitLocker deployments [@roca17], [@cve2017]. Coppersmith's 1996 barrier, patient for twenty years, collected its debt.

The root cause of the last two is not RSA math at all -- it is the CSPRNG that generates the primes, the subject of Part 2 of this series. Feed RSA weak randomness and no scheme, no padding, and no proof can save it.

Note: Turn the diagnostic question on each front and it answers itself. The verifier confesses through a check it skipped. The chip confesses through a fault it did not catch. The clock confesses through a branch it did not equalize. The keygen confesses through primes it did not draw uniformly. In every case the attacker reads the private key off the receiver's behaviour, not off the mathematics.

Keep the empirical yardstick in view: the largest RSA modulus ever publicly factored is RSA-250, at 829 bits.RSA-250 was factored on 28 February 2020 using the Number Field Sieve, at a cost of roughly 2,700 core-years of computation [@rsa250]. That is the real, measured cost of breaking RSA by its front door -- which is exactly why nobody attacks that door when a padding check will open the side gate for a million cheap queries. Four fronts, one disease. The cure is not a cleverer patch on any single front. It is a change in what we mean when we say a scheme is secure.

6. Security Is a Property of the Scheme AND the Implementation

There are two famous ideas behind "RSA done right," and a third, deeper one that the first two kept teaching the hard way.

Idea 1: OAEP, the all-or-nothing randomized transform

Optimal Asymmetric Encryption Padding, designed by Mihir Bellare and Phillip Rogaway in 1994, encodes the message before the RSA permutation so that the encoded block has no gradable structure for an attacker to probe [@oaep94]. Its construction is a two-round Feistel network with a hash-based mask-generation function, MGF1, as the round function -- the hashing machinery that Part 10 of this series develops. Writing $\Vert$ for concatenation and $\oplus$ for XOR, and starting from a random $\mathrm{seed}$:

$$\mathrm{DB} = \mathrm{lHash} \Vert \mathrm{PS} \Vert \texttt{0x01} \Vert M$$ $$\mathrm{maskedDB} = \mathrm{DB} \oplus \mathrm{MGF1}(\mathrm{seed}), \qquad \mathrm{maskedSeed} = \mathrm{seed} \oplus \mathrm{MGF1}(\mathrm{maskedDB})$$ $$\mathrm{EM} = \texttt{0x00} \Vert \mathrm{maskedSeed} \Vert \mathrm{maskedDB}$$

Then the RSA permutation is applied to $\mathrm{EM}$ [@rfc8017]. The two Feistel rounds make every bit of the encoded block depend on every bit of the message and the random seed. That is the property that kills the padding oracle: flip a single bit of an OAEP ciphertext and the decoded block is randomized wholesale, so a tampered ciphertext decodes to noise with overwhelming probability. There is no conformant interval to bisect, no structured remnant to grade.

With the randomness supplying non-determinism and the all-or-nothing mixing supplying tamper-detection, OAEP is not only semantically secure but also non-malleable and secure against chosen-ciphertext attack -- IND-CCA2 in the random-oracle model [@oaep94abs].

Optimal Asymmetric Encryption Padding: a randomized, all-or-nothing transform applied to a message before the RSA permutation. It mixes the message with a random seed through two mask-generation passes -- a two-round Feistel network -- so that every bit of the encoded block depends on every bit of the input. Flipping any ciphertext bit randomizes the whole decoded block, which destroys malleability and yields chosen-ciphertext security in the random-oracle model. OAEP's history includes a moment cryptography should be proud of. In 2001, Victor Shoup showed that the celebrated 1994 security proof did not go through for an arbitrary trapdoor permutation -- it quietly assumed more than the definition guarantees [@shoup01]. The scheme was not broken; the *argument* was. Later that year, Fujisaki, Okamoto, Pointcheval, and Stern repaired it, proving RSA-OAEP is chosen-ciphertext secure in the random-oracle model under the RSA assumption, by leaning on a property called partial-domain one-wayness -- though the resulting reduction is non-tight [@fops04]. A public "our proof, not our scheme, was wrong," followed by a public fix, is exactly how a mature field is supposed to work.

Idea 2: PSS, the salted encoding with a tight proof

For signatures, the Probabilistic Signature Scheme, also from Bellare and Rogaway, plays the analogous role [@pss96]. To sign, it hashes the message to $\mathrm{mHash}$, draws a random $\mathrm{salt}$, and forms $M' = \texttt{padding} \Vert \mathrm{mHash} \Vert \mathrm{salt}$; sets $H = \mathrm{Hash}(M')$; builds $\mathrm{DB} = \mathrm{PS} \Vert \texttt{0x01} \Vert \mathrm{salt}$; masks it as $\mathrm{maskedDB} = \mathrm{DB} \oplus \mathrm{MGF1}(H)$; and assembles $\mathrm{EM} = \mathrm{maskedDB} \Vert H \Vert \texttt{0xbc}$ before applying the RSA private operation [@rfc8017].

The randomization and MGF mixing buy something v1.5 signatures never had: a tight exact-security reduction. A forger against PSS implies an algorithm that inverts RSA at almost the same cost -- so breaking the signatures is essentially as hard as the RSA problem itself, not merely conjectured to be [@pss96]. That is strictly stronger than v1.5's heuristic argument. PSS entered the standard in PKCS#1 v2.1 (RFC 3447) in 2003 and remains in the current v2.2 [@rfc3447]. Yet the split holds: PSS is the provable upgrade, but v1.5 signatures are not superseded in deployment -- they remain the Web PKI default.Beyond these two deployed schemes, the literature holds academic-only refinements -- SAEP/SAEP+, OAEP+, three-round OAEP, tight RSA-KEM variants, and message-recovery PSS-R -- which tighten proofs or trim assumptions but never displaced OAEP and PSS in practice. A pointer, not a section.

Probabilistic Signature Scheme: a randomized, salted RSA signature encoding. A fresh random salt and MGF1 mixing make every signature of the same message different, and the scheme comes with a tight security reduction -- a forger would yield an almost-equally-efficient algorithm for inverting RSA, the strongest guarantee any RSA scheme offers.

Idea 3: the one the first two kept teaching

Here is where the whole article turns. OAEP is provably secure, yet Manger re-opened the identical oracle inside a non-constant-time decoder. PSS is provably secure, yet a fault or a timing leak in the signer factors the key. The scheme was never the whole story.

Key idea: Security is a property of the scheme AND its implementation, not of the math. A perfect scheme run by a decoder that leaks whether padding verified is exactly as broken as no scheme at all. The implementation disciplines below are part of the construction, not optional hygiene layered on top.

Three disciplines close the three channels the catalog exposed:

Constant-time depadding with implicit rejection. On any decryption failure, do not branch or return a distinguishable error; substitute a deterministic pseudo-random value and continue, so whether the padding verified stays unobservable. OpenSSL 3.2 ships this by default and aligned its behaviour with NSS so neither library can be an oracle for the other [@openssl32], [@gorsa].
CRT verify-before-release. Recompute and check the signature before it leaves the device, defeating Bellcore faults [@bdl97].
Base blinding. Randomize the input before exponentiation so timing reveals nothing about the secret [@kocher96], [@brumleyboneh03].

A decryption strategy in which a padding failure does not produce a distinguishable outcome. Instead of branching or returning a specific error, the code substitutes a deterministic pseudo-random value derived from the private key and ciphertext and proceeds. Success and failure become indistinguishable through content, error type, or timing, so there is no oracle left to query. flowchart TD M[Message or ciphertext arrives] --> SCH{"Scheme layer"} SCH -->|Encrypt| OAEP[RSAES-OAEP, randomized all-or-nothing] SCH -->|Sign| PSS[RSASSA-PSS, salted with tight proof] OAEP --> IMPL{"Implementation layer"} PSS --> IMPL IMPL --> CT[Constant-time depad, implicit rejection] IMPL --> VBR[CRT verify-before-release] IMPL --> BL[Base blinding] CT --> PAR{"Parameter layer"} VBR --> PAR BL --> PAR PAR --> P1[Modulus at least 2048 bits, e equals 65537, CSPRNG primes] P1 --> GATE{"Does any behaviour reveal the padding verdict?"} GATE -->|No| SAFE[RSA done right] GATE -->|Yes| BROKEN[Oracle reopens, the catalog repeats]

The libraries now say this in plain language. Go's standard library deprecated its v1.5 decryption function outright, with a warning that doubles as the thesis of this article:

"PKCS #1 v1.5 encryption is dangerous and should not be used ... whether this function returns an error or not discloses secret information." -- Go crypto/rsa package documentation [@gorsa]

That is the whole discipline in one sentence: done right closes the padding-oracle class Part 6 traces across all of cryptography, and it does so at the implementation layer, not the math. So what does the whole stack look like in 2024 to 2026 -- and which parts are quietly being switched off?

7. State of the Art (2024 to 2026): Done Right Is a Stack, Not a Method

Most primitives have a single "best" option you can name. RSA does not. "Done right" in 2026 is a conjunction of independent choices that must all hold at once. Remove any one and the 25-year catalog reopens at that layer. Here is the stack, layer by layer.

Mode	Job	What it adds	Security status	Still requires
v1.5 encryption	Encrypt	Randomness only	Broken as a target -- padding oracle	Retire it; no safe deployment
RSAES-OAEP	Encrypt	Randomness plus all-or-nothing mixing	IND-CCA2 in the random-oracle model	Constant-time, implicit-rejection decode
v1.5 signature	Sign	Fixed checkable structure	Unbroken scheme, heuristic argument	Strict verification, no e equals 3 shortcut
RSASSA-PSS	Sign	Salt plus MGF, tight proof	Provably as hard as the RSA problem	CRT verify-before-release, blinding

Encryption scheme. When a standard genuinely mandates RSA encryption of a small payload, the answer is RSAES-OAEP with SHA-256 and MGF1-SHA-256, decoded in constant time [@rfc8017]. But note the capacity ceiling: a 2,048-bit OAEP-SHA-256 ciphertext carries at most about 190 bytes of plaintext [@sp80056b]. "Encrypt a file with RSA-OAEP" is therefore not just risky but physically wrong -- RSA encryption is for keys, never bulk data.

Signatures. New designs use RSASSA-PSS, which TLS 1.3 makes mandatory for handshake signatures [@pss96], [@rfc8446]. Yet RSASSA-PKCS1-v1_5 signatures remain dominant and FIPS-approved across X.509 and TLS certificates [@fips1865]. This is not a contradiction: keep v1.5 signatures where they are mandated, and verify them strictly [@rfc8017].

Implementation hardening. This is the layer that actually stops the attacks. OpenSSL 3.2 enables constant-time depadding with implicit rejection by default [@openssl32], Go has deprecated its v1.5 decryption entry point [@gorsa], and the CFRG's 2025 implementation-guidance draft folds all of this into formal advice amending RFC 8017 [@cfrgdraft].

Parameters. A 2,048-bit modulus is the floor for 112-bit security; use 3,072 or 4,096 bits for long-term secrets; keep $e = 65537$; and draw primes from a properly seeded CSPRNG [@sp80057], [@fips1865].

Deployment and policy. The most durable fixes were structural, not cryptographic. TLS 1.3 deleted RSA key exchange entirely, which killed the Bleichenbacher-on-TLS class at the protocol level rather than patching each oracle [@rfc8446]. FIPS policy disallows RSA v1.5 key transport after 31 December 2023 [@sp800131a], [@sp80056b]. And NIST IR 8547 puts a clock on RSA itself, deprecating 112-bit strength after 2030 and disallowing it after 2035 [@ir8547].

If you operate under FIPS 140-3, the encryption side of this is not advisory. NIST SP 800-131A Rev. 2 and SP 800-56B Rev. 2 together disallow RSAES-PKCS1-v1_5 key transport after 31 December 2023; approved RSA key establishment must use OAEP [@sp800131a], [@sp80056b]. The signature side is the opposite: RSASSA-PKCS1-v1_5 signatures remain FIPS-approved under FIPS 186-5 [@fips1865]. Same version number, opposite compliance verdicts -- which is exactly why the encryption-signature split is not pedantry.

Note: Right scheme (OAEP to encrypt, PSS for new signatures), right implementation (constant-time depad with implicit rejection, CRT verify-before-release, base blinding), right parameters (2,048-bit floor, e equals 65537, CSPRNG primes), inside the right protocol (TLS 1.3, no RSA key exchange). Every deployed disaster in the catalog removed exactly one of these. None of it is new in 2026; the interesting movement is not toward a better RSA but away from RSA entirely.

RSA done right is stable. The genuinely current story is mostly about what to switch off and what is migrating away -- because for both of RSA's jobs, something smaller and faster is already taking over.

8. What RSA Is Losing To: ECDH, KEM-DEM, and the Post-Quantum Elephant

RSA is not being fixed into the future; it is being replaced out of it -- and the reasons have nothing to do with padding.

The cleanest of those reasons is a design pattern that removes the attacker's target entirely. Never RSA-encrypt data. Instead, encapsulate a fresh random symmetric key with the public key, and let an authenticated cipher carry the bulk. The public-key operation then transports only a uniform random key -- there is no attacker-chosen, structured plaintext for any oracle to grade. The entire Bleichenbacher-to-Marvin family loses its object, because the thing being decrypted is indistinguishable from random by construction [@rfc8446].

A two-part construction for hybrid encryption. A Key Encapsulation Mechanism (KEM) uses the public key to transport a freshly generated random symmetric key; a Data Encapsulation Mechanism (DEM) then encrypts the actual data with that key under an authenticated cipher. Because the public-key step only ever carries a uniform random key -- never a chosen, structured message -- there is no padding structure for an oracle to probe, so the padding-oracle class simply does not apply. sequenceDiagram participant S as Sender participant R as Recipient Note over R: Publishes a public key S->>S: Encapsulate, generate a random key K for the recipient S->>S: Stretch K with a KDF, AEAD-encrypt the data S->>R: Send the encapsulation and the AEAD ciphertext R->>R: Decapsulate to recover K, run the same KDF R->>R: AEAD-decrypt and verify the data Note over R,S: The public-key part carried only a random K, nothing to grade

This is why elliptic-curve key agreement (ECDH, with Ed25519 and ECDSA for signatures) displaced RSA key transport: it does the same jobs with far smaller keys, faster operations, and forward secrecy -- a property RSA key transport never had, and the direct reason TLS 1.3 could delete RSA key exchange rather than merely patch it [@rfc8446]. The KEM-DEM composition is developed in Part 11 of this series, the KDF step in Part 13, and the AEAD that carries the payload in Part 7.

Then there is the elephant. Peter Shor's algorithm factors integers in polynomial time on a large fault-tolerant quantum computer, which makes all factoring-based cryptography -- every RSA key length, done right or not -- eventually breakable. NIST has already named the destination: ML-KEM (FIPS 203) for key encapsulation, and ML-DSA and SLH-DSA (FIPS 204 and 205) for signatures [@fips203], [@fips204], [@fips205].

The migration is lopsided. Key encapsulation is moving fast -- hybrid X25519 plus ML-KEM-768 already carries a double-digit percentage of Cloudflare's TLS 1.3 traffic -- while post-quantum signatures lag badly, because they run 10 to 200 times larger than an RSA signature and no public post-quantum certificate infrastructure existed before roughly 2026 [@cloudflare24], [@ir8547]. The lattice and hash-based internals belong to a later part of this series; here they matter only as RSA's replacement, not its repair.

Quantum risk is not only a future problem. An adversary can record RSA-encrypted traffic today and decrypt it once a capable quantum computer exists. For any secret that must stay confidential past roughly 2030, the exposure is *present tense* -- which is why NIST IR 8547 frames the transition as urgent rather than eventual, and why hybrid key exchange is being deployed now rather than when the machine arrives [@ir8547], [@cloudflare24].

Laid side by side, the trade-offs explain why key transport migrated first and signatures are dragging. For moving a key:

Key transport	Forward secrecy	Padding-oracle exposure	Relative cost	Quantum status
RSAES-OAEP [@rfc8017]	No	Yes, if decode is not constant-time	Large ciphertext, slow keygen	Broken by Shor
ECDH (X25519) [@rfc8446]	Yes	None, no RSA decryption	Small and fast	Broken by Shor
ML-KEM-768 [@fips203]	Yes (ephemeral)	None	Kilobyte-scale, fast	Resistant
Hybrid X25519 + ML-KEM-768 [@cloudflare24]	Yes	None	Sum of both, still practical	Resistant if either holds

And for signing:

Signature	Provable security	Approx. signature size	Main failure mode	Quantum status
RSASSA-PSS [@pss96]	Yes, tight in ROM	256 bytes at 2048-bit	Fault or timing in the signer	Broken by Shor
RSASSA-PKCS1-v1_5 [@rfc8017]	No, heuristic only	256 bytes at 2048-bit	Lax-verifier forgery	Broken by Shor
ECDSA / Ed25519 [@rfc8446]	Yes	64 bytes	Nonce reuse (ECDSA)	Broken by Shor
ML-DSA-65 [@fips204]	Yes, lattice	About 3.3 kilobytes	Implementation bugs	Resistant
SLH-DSA [@fips205]	Yes, hash-based	Many kilobytes	Large and slow	Resistant

The signature column is the migration's hard problem, which is why post-quantum certificates lag key exchange by years [@ir8547]. If RSA is on the clock, it is worth asking where its security actually came from in the first place -- and why nobody has ever proved it was there.

9. Theoretical Limits: Where the Security Comes From, and Its Ceiling

Here is the uncomfortable truth a first course skips: there is no proof that RSA is secure.

Start with the assumption itself. The RSA problem is to compute $e$-th roots modulo $N$ without the factorization. We know this is no harder than factoring -- if you can factor $N$, you can compute $d$ and invert everything, so RSA $\le$ factoring. What nobody has shown is the reverse. It is an open question whether breaking RSA is equivalent to factoring, and Boneh and Venkatesan gave evidence that a broad class of algebraic reductions from factoring to low-exponent RSA is unlikely to exist -- suggesting the two problems may not be equivalent at all [@bv98].

Worse, factoring itself is not known to be hard in any proven sense: it sits in NP intersect co-NP, which is evidence it is probably not NP-complete, and no one has proved a super-polynomial lower bound for it. RSA's security is heuristic and empirical -- it has survived decades of attack, and that is the entire argument [@boneh99].

The empirical ceiling is concrete. The best classical algorithm, the General Number Field Sieve, runs in sub-exponential time, and the public record is RSA-250 at 829 bits, factored in February 2020 for roughly 2,700 core-years [@rsa250]. RSA-250 was one of the RSA Factoring Challenge moduli that RSA Laboratories first published in 1991 as public benchmarks for exactly this kind of progress [@rsanumbers]. That record sets the practical floors:

RSA modulus	Symmetric-equivalent strength	Status
1024-bit	About 80 bits	Broken within reach, disallowed
2048-bit	112 bits	Current minimum, deprecated after 2030
3072-bit	128 bits	Long-term use
4096-bit	About 140 bits (interpolated)	High assurance
7680-bit	192 bits	Next tabulated SP 800-57 step
15360-bit	256 bits	Shows how badly RSA scales

Those equivalences come from NIST SP 800-57, except the 4,096-bit figure -- a common interpolation, since the standard steps directly from 3,072 bits (128) to 7,680 bits (192). The last row is the quiet punchline: matching a 256-bit symmetric key needs a 15,360-bit RSA modulus, because RSA strength grows only sub-exponentially in key length while the cost of using it grows with the cube [@sp80057]. RSA scales badly, and that alone pushes new systems toward elliptic curves.

Then the cliff. On a large fault-tolerant quantum computer, Shor's algorithm factors in polynomial time -- not faster, but categorically faster, collapsing the whole assumption. The only question is engineering, and the estimates are falling fast. In 2019, Gidney and Ekera estimated 20 million noisy qubits and 8 hours to factor a 2,048-bit modulus [@gidney19]; by 2025, Gidney had cut the qubit estimate to under a million [@gidney25].A 20-fold reduction in the resource estimate in six years, with no fundamental barrier in sight, is precisely the trend that drove NIST to put firm dates -- 2030 and 2035 -- on RSA's retirement in IR 8547. The deadline is set by the slope, not by any single machine.

Three impossibility results frame the whole subject, each already seen in this article. First, determinism can never be IND-CPA -- that is structural, not fixable, which is why padding must randomize. Second, there is no known standard-model proof of IND-CCA2 for RSA-OAEP under the plain RSA assumption; the guarantee is random-oracle-model only, and even there non-tight [@shoup01], [@fops04]. Third, Coppersmith's barrier $|x| < N^{1/e}$ both enables low-exponent attacks and bounds them, a hard mathematical edge that no parameter choice moves [@coppersmith97].

Key idea: RSA's safety lives in an unproven gap -- breaking it is no harder than factoring, but maybe strictly easier, and factoring is not even proven hard -- and that gap sits on the near side of a quantum cliff with a falling date on it. "Done right" buys you security against every known classical attack. It does not buy you a proof, and it cannot buy you time past Shor.

If the ground under RSA is this uncertain, what exactly is still unsettled -- and which of those open problems can bite you today?

10. Open Problems: What Remains Genuinely Unsettled

Some of these are for theorists. Others are live in your dependency tree right now.

Is the RSA problem equivalent to factoring? We have only one direction, RSA $\le$ factoring; the reverse is open, with evidence it may fail [@bv98]. It matters because RSA's whole security story rests on a hardness we have never actually pinned down.
A deployed, standard-model IND-CCA2 RSA scheme. Constructions that avoid the random-oracle model exist on paper, but none is a shipping default; practice sidesteps the gap entirely by using KEM-DEM instead of RSA encryption [@fops04].
Constant-time RSA is a perpetually moving target. Marvin re-found timing leaks in implementations previously believed immune, and only a handful -- such as BearSSL and BoringSSL -- passed its tests; leaks hide in general-purpose bignum code and even in error-logging paths, which is why the CFRG draft concludes the only safe path is to deprecate v1.5 encryption outright rather than keep hardening it [@marvin23], [@cfrgdraft].
The long tail of v1.5 encryption. HSMs, PKCS#11 tokens, S/MIME, and JWE still use it in places that cannot simply be switched off -- exactly where Marvin keeps finding live oracles [@marvin23], [@gorsa].
Generation-time entropy and structured primes. Mining Your Ps and Qs and ROCA are operational failures with no clean universal fix: you cannot prove every device in the world seeded its CSPRNG correctly [@miningpq12], [@roca17].
The post-quantum migration timeline. Key exchange is migrating; signatures are years behind, and harvest-now-decrypt-later keeps the pressure on [@cloudflare24], [@ir8547].

Note: Most of this list is someone else's research agenda. Two entries are not: the v1.5 encryption long tail and weak key-generation entropy are the ones most likely to be sitting in your own stack right now, in an HSM integration or an embedded device you inherited. Audit those two first.

Enough theory. Here is the whole argument compressed into rules you can apply on Monday.

11. The Practical Guide and the Misuse Catalog

Every rule below is one named break from the catalog, turned inside out. If you remember nothing else, remember the decision tree.

flowchart TD START{"What do you need?"} -->|Confidentiality| ENC{"Can you avoid RSA encryption?"} START -->|Authenticity| SIG{"New design or legacy mandate?"} ENC -->|Yes| KEM[Use ECDH or hybrid X25519 plus ML-KEM-768] ENC -->|No, a standard forces RSA| OAEP[RSAES-OAEP, SHA-256, constant-time decode, at least 2048-bit] SIG -->|New design| PSS[RSASSA-PSS with SHA-256] SIG -->|Legacy mandate| V15[v1.5 signature, verify strictly, no e equals 3 shortcut] KEM --> KEYS[Keys: e equals 65537, CSPRNG primes, verify-before-release, blinding] OAEP --> KEYS PSS --> KEYS V15 --> KEYS KEYS --> PQ{"Secret must survive past 2030?"} PQ -->|Yes| HY[Deploy hybrid post-quantum now] PQ -->|No| DONE[Ship it]

Spelled out as decision rules:

Encryption and key transport. Prefer ECDH or a KEM, migrating to hybrid X25519 plus ML-KEM-768. If a standard forces RSA encryption, use RSAES-OAEP with SHA-256 and MGF1-SHA-256, a modulus of at least 2,048 bits, and a constant-time decoder with implicit rejection -- never v1.5 encryption [@rfc8017], [@sp80056b]. Never RSA-encrypt a payload; encapsulate a symmetric key and let an AEAD carry the data.
Signatures. Use RSASSA-PSS for new designs [@pss96], [@fips1865]. Use v1.5 signatures only where mandated, and then verify strictly: full parse, re-encode and compare, reject trailing data, no $e = 3$ shortcut [@rfc8017].
Keys and parameters. A 2,048-bit floor, 3,072 or 4,096 bits for long-term secrets; $e = 65537$; independent CSPRNG-drawn primes per key; CRT with verify-before-release; base blinding [@sp80057], [@fips1865].
Migration. Deploy hybrid post-quantum key agreement now, and inventory every RSA usage against the IR 8547 2030 and 2035 clock [@ir8547].

The same rules as a lookup table:

Task	Use	Key parameters	Because (which break)
Key transport, preferred	ECDH or hybrid X25519 + ML-KEM-768	Ephemeral keys	Forward secrecy, no oracle, quantum hedge
Key transport, if RSA forced	RSAES-OAEP, constant-time decode	SHA-256, MGF1-SHA-256, at least 2048-bit	Bleichenbacher, Manger, Marvin
Signature, new design	RSASSA-PSS	SHA-256, random salt	v1.5 hand-wave, e equals 3 forgery
Signature, legacy mandate	v1.5, verified strictly	Full parse, reject trailing bytes	e equals 3 forgery, BERserk
Key generation	e equals 65537, CSPRNG primes	2048 floor, 3072+ long-term	Wiener, ROCA, Mining Ps and Qs
Private operation	CRT verify-before-release, base blinding	Recompute before output	Bellcore fault, Kocher timing
Long-term secrets	Hybrid post-quantum now	Inventory to IR 8547 clock	Shor, harvest-now-decrypt-later

Now the misuse catalog. Each antipattern maps to exactly one rule it violates -- the findings that recur in real code review:

v1.5 encryption "kept for compatibility." The single most dangerous line in an RSA integration. Violates: retire v1.5 encryption.
Non-constant-time OAEP or v1.5 decode. A decoder that branches or times differently on padding failure. Violates: constant-time, implicit-rejection decoding (Manger, Marvin).
Distinct decryption error messages, or branch timing. Any observable difference between "bad padding" and "other error." Violates: uniform, unobservable failure (Bleichenbacher).
Missing CRT verify-before-release. Signing without recomputing the result first. Violates: verify before release (Bellcore fault).
Unblinded exponentiation. A modexp whose time depends on the secret. Violates: base blinding (Kocher, Brumley-Boneh).
An $e = 3$ shortcut in a verifier. Checking the prefix without rejecting trailing data. Violates: verify strictly (e-equals-3 forgery, BERserk).
Textbook RSA copied from a tutorial. The raw permutation on a message. Violates: never call the raw primitive.
RSA-encrypting a large payload. Treating RSA as a bulk cipher. Violates: encapsulate a key, never encrypt data.
Weak, shared, or reused-modulus keys. Primes drawn from a cold CSPRNG or a structured library. Violates: seed the CSPRNG, draw primes uniformly (Mining Ps and Qs, ROCA).
OAEP hash or label mismatch, or MGF1 silently defaulting to SHA-1. A quiet interoperability and downgrade trap. Violates: pin the hash and MGF explicitly.
Treating a "small" side channel as unexploitable. Marvin demolished that folklore -- a few microseconds recovered keys [@marvin23]. Violates: assume every observable leaks.

Grep for the dangerous entry points and confirm every RSA decryption path uses OAEP with a constant-time decoder:

Go: search for DecryptPKCS1v15 and EncryptPKCS1v15; move to DecryptOAEP and EncryptOAEP. The v1.5 decryptor is deprecated for the reason quoted earlier [@gorsa].
Java: flag Cipher.getInstance("RSA/ECB/PKCS1Padding"); require RSA/ECB/OAEPWithSHA-256AndMGF1Padding.
OpenSSL CLI: openssl pkeyutl -encrypt -pubin -inkey pub.pem -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256.

If a dependency genuinely still needs v1.5 decryption, confirm it runs a constant-time, implicit-rejection decoder -- OpenSSL 3.2 does so by default [@openssl32].

Note: In practice, three violations dominate real audits: RSA v1.5 encryption still enabled "for a legacy client," a decryption path that is not verifiably constant-time, and RSA being used to encrypt bulk data instead of a symmetric key. Fix those three and you have closed most of the catalog [@marvin23], [@gorsa], [@openssl32].

Read the whole failure catalog again as this checklist, and one pattern remains.

12. Trapdoor, Not Cryptosystem

Return to where we began. The researchers who signed with facebook.com's key never factored its modulus, and neither did anyone in the twenty-five years of breaks between Bleichenbacher and Marvin. The factoring problem stood untouched the whole time. What fell, every single time, was something else: the decryptor's error handling, the signer's fault behaviour, the implementation's clock, or the generator's entropy. The attacker's real move is never to solve the hard math -- it is to turn the receiver's own reaction into the private-key operation.

The attacker does not factor the modulus. They turn the decryptor's reaction into the private-key operation -- and "done right" is the discipline of leaving that reaction with nothing to say.

That is why "RSA done right" is a stack and not a setting. The right scheme, OAEP to encrypt and PSS for new signatures, does two of the three jobs. The right parameters -- a 2,048-bit floor, $e = 65537$, primes from a real CSPRNG -- keep the trapdoor strong. And the constant-time, fault-checked, blinded implementation does the third job, the one the field kept forgetting: it leaves no observable behaviour that answers the attacker's one question.

Every deployed disaster in this article is a stack with exactly one layer missing. Textbook RSA is broken not because the math is weak but because it is only the trapdoor, with none of the layers that make a trapdoor into a cryptosystem.

The forward horizon makes the discipline sharper, not softer. RSA done right is stable against every known classical attack, and it still has an expiration date, because the one gap RSA can never close is the quantum one. The destination is not a better RSA. It is KEM-DEM composition and post-quantum algorithms -- constructions where the public-key operation carries only a uniform random key, and where Shor has no polynomial-time shortcut to wait for.

So ask the diagnostic question one final time, now that it is answerable. When a ciphertext or signature it did not create arrives, what does the receiver reveal about it -- through its answer, its timing, or its faults? Done right, the answer is nothing at all.

No, but the word "RSA" hides three different answers. Textbook RSA is broken. PKCS#1 v1.5 *encryption* is dangerous and should be retired [@marvin23]. Done-right RSA -- OAEP or PSS, constant-time, at least 2,048 bits, public exponent 65537 -- is fine against every known classical attack, right up until a large quantum computer exists, which is why you should be planning migration in parallel [@ir8547]. No. Encapsulate a fresh random symmetric key with the public key and let an authenticated cipher encrypt the file. RSA-OAEP at 2,048 bits carries only about 190 bytes of plaintext anyway, so it was never meant for bulk data -- it moves keys, not files [@sp80056b]. No. OAEP fixes the *scheme*, not the decoder. James Manger showed that a non-constant-time OAEP decoder re-opens the very same padding oracle, and more cheaply than the original Bleichenbacher attack [@manger01]. The rule is "OAEP AND constant-time decoding," never OAEP alone. Not as a scheme -- there is no known attack against the RSASSA-PKCS1-v1_5 signature construction itself [@rfc8017]. What breaks is lax *verifiers*: the 2006 e-equals-3 forgery and the 2014 BERserk bug both forged signatures past sloppy verification, not by breaking the scheme [@cve2006], [@cve2014]. Verify strictly -- parse the entire structure and reject any trailing data. Only with correct padding and a strict verifier, and it is not worth the risk. A small exponent has repeatedly enabled Hastad's broadcast attack, Coppersmith's low-exponent attacks, and signature forgeries [@hastad88], [@coppersmith97]. Use 65537: it is fast and dodges every low-exponent trap. Yes for today -- a 2,048-bit modulus gives about 112 bits of security [@sp80057]. Use 3,072 bits or more for anything that must stay secret long-term, and start post-quantum planning: NIST deprecates 112-bit RSA after 2030 and disallows it after 2035 [@ir8547]. For most new work, yes. ECDH and Ed25519 give smaller, faster keys with the forward secrecy RSA key transport never had [@rfc8446], and hybrid X25519 plus ML-KEM-768 is already carrying real TLS traffic for the quantum transition [@cloudflare24]. RSA's destination is retirement, not repair.

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.