Parag Mali - tag: rsa

How Q-Day Breaks Everything: Shor's Algorithm and the Simultaneous Fall of RSA, Diffie-Hellman, and ECC

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

RSA, Diffie-Hellman, DSA, and elliptic-curve cryptography look like four independent security systems, but they secretly rest on one structure: a hidden period in a finite abelian group. A single fault-tolerant quantum computer running Shor's algorithm reads that period directly with the quantum Fourier transform, breaking all four in polynomial time -- and enlarging keys does not help, because Shor scales with the logarithm of the key. Symmetric cryptography (AES, SHA-2/3) survives Q-Day intact because it hides no such period, so it faces only Grover's quadratic speedup, which doubling the key size neutralizes. No such machine exists in 2026 -- the best hardware runs about one below-threshold logical qubit -- but "harvest now, decrypt later" means the migration to post-quantum cryptography cannot wait for it to arrive.

1. One Break, Four Falls

Four cryptographers, working in four different decades on four different branches of mathematics, built the fortresses that guard almost every secret you have ever sent: a 2048-bit RSA key, a 2048-bit Diffie-Hellman group, a DSA signature, and a 256-bit elliptic curve. They look nothing alike -- different keys, different math, different inventors -- so we deployed them side by side and called it diversity.

This article is about the afternoon a single machine running a single idea knocks all four down at once, while AES-256 in the field next door barely looks up -- and about why the reason those four fall together is exactly the reason the fifth survives.

Here is the thesis, stated plainly before any mathematics arrives to defend it: the four are not four problems. They are one. Underneath RSA's factoring, Diffie-Hellman's discrete logarithm, DSA's signatures, and elliptic-curve cryptography's smaller keys lies a single shared object -- a hidden period in a finite abelian group. A quantum computer running Peter Shor's 1994 algorithm reads that period more or less in one shot, and when the period falls, all four fortresses built on top of it fall with it [@shor-1994].

Symmetric cryptography survives for the mirror-image reason: a well-built cipher hides no period at all, so there is nothing for the same machine to read.

The event has a name.

Q-Day is the hypothetical day a cryptographically relevant quantum computer first runs Shor's algorithm at scale against deployed keys, breaking the public-key cryptography (RSA, Diffie-Hellman, DSA, and elliptic-curve schemes) that secures most of the internet. It is a threshold, not a gradual slope: the same machine that cannot break a 2048-bit key at all on Monday can break it in hours once it crosses the fault-tolerance threshold.

Two questions organize everything that follows, and the whole article is their answer: why do these four fall together? and why not AES? Hold both in your head. The first is a story about a hidden unity nobody designed on purpose. The second is a story about a boundary so sharp it can be stated as a theorem -- and that same boundary turns out to be the entire design premise of the cryptography we are now scrambling to deploy.

RSA, Diffie-Hellman, DSA, and elliptic curves were never four independent bets. They are one bet -- that a hidden period in a finite abelian group is hard to find -- made four times in four disguises. Shor's algorithm collects on all four at once.

One honesty flag, planted here and never lowered: no such machine exists in 2026. Not almost, not in a lab somewhere -- none. The best error-corrected hardware yet demonstrated encodes about one reliable logical qubit [@google-willow-2025], and a real attack needs on the order of a thousand of them holding still for hours. So this is a loaded gun on the table, not a fired one. That gap between a proven algorithm and an unbuilt machine is not a reason to relax; as we will see, it is precisely the deadline.

The journey runs in seven moves: how the world came to trust just two hard problems, the one quantum trick that matters, the breakthrough that turned factoring into period-finding, the same trick applied three more times, the asymmetry that spares AES, the machine's true price tag, the limits of the blast radius, and why one proven fact already forces a global migration. To see why one machine breaks four fortresses, you first have to see how the world ended up trusting just two hard problems in the first place.

2. Two Problems the Whole World Rested On

Rewind to 1976. Two strangers want to agree on a shared secret while an eavesdropper records every bit that passes between them. For millennia this was considered impossible: to share a secret you first had to share a secret. Then Whitfield Diffie and Martin Hellman published a construction that let the two strangers mix public numbers into a private one the eavesdropper could not reconstruct, and modern cryptography was born [@diffie-hellman-1976]. Its security rested on a new assumption -- that one specific arithmetic operation is easy forward and hard backward.

In a cyclic group generated by an element $g$, exponentiation is easy: given $g$ and $x$, computing $h = g^x$ is fast. The discrete logarithm problem is the reverse: given $g$ and $h$, recover the exponent $x$. In the multiplicative group of integers modulo a large prime -- and, later, in the group of points on an elliptic curve -- recovering $x$ is believed to require super-polynomial classical effort. That belief is the security assumption beneath Diffie-Hellman, DSA, and elliptic-curve cryptography.

A year later, Ron Rivest, Adi Shamir, and Leonard Adleman turned a different one-way asymmetry into a full encryption-and-signature system: multiplying two large primes is easy, but factoring their product back into those primes is hard [@rsa-1978]. RSA bet its life on integer factoring; Diffie-Hellman had bet on the discrete logarithm. Two bets, two problems.

Then the bets consolidated. In 1985 Victor Miller, and independently in 1987 Neal Koblitz, moved the discrete logarithm onto elliptic curves, where the best known classical attacks are far weaker and so the keys can be dramatically smaller for the same classical security [@miller-1986][@koblitz-1987]. Elliptic-curve cryptography was not a new hard problem -- it was the same discrete logarithm relocated to a group where classical attackers had less traction.This is the seed of a cruel irony we will harvest in Section 5. ECC's whole selling point is that it achieves equal classical security with smaller keys, because no sub-exponential attack like index calculus applies to well-chosen curves [@koblitz-1987]. Against a quantum computer, "smaller keys" means "fewer qubits to attack," so the classical strength inverts into a quantum liability.

By the 1990s the accounting was stark. Strip away the packaging and essentially all deployed public-key cryptography reduced to exactly two hard problems: integer factoring and the discrete logarithm. The classical attacks that calibrate their key sizes -- the general number field sieve for factoring, index calculus for finite-field discrete logs, Pollard's rho for elliptic curves -- are the subject of this series' earlier posts on RSA and the discrete logarithm, and I will not re-derive them here [@bernstein-lange-2017].

What matters is the structural fact: the entire public-key world put all its eggs in two baskets, and nobody chose those two baskets because they were secretly connected. They looked like independent bets.

Nobody chose factoring and the discrete logarithm because they were related. They looked like two independent bets. They were the same bet.

While the defense lineage was consolidating, a second, unrelated lineage was quietly assembling the machine that would read both. In 1982 Richard Feynman observed that simulating quantum physics on a classical computer seems to require exponential resources, and proposed turning the problem around: build a computer that is quantum-mechanical and let physics do the bookkeeping [@feynman-1982]. In 1985 David Deutsch made the idea rigorous, defining the universal quantum computer and the principle that it could simulate any physical process [@deutsch-1985].

This was pure physics and computability theory. Nobody in 1985 thought it had anything to do with RSA. The two lineages were on tracks that had not yet touched.

flowchart LR subgraph Defense["Defense lineage -- the fortresses"] DH["1976 Diffie-Hellman: discrete log assumption"] RSA["1977 RSA: integer factoring"] ECC["1985 to 1987 Miller and Koblitz: elliptic curves"] end subgraph Attack["Attack lineage -- the machine"] FEY["1982 Feynman: simulate physics with a quantum computer"] DEU["1985 Deutsch: universal quantum computer"] SIM["1994 Simon: period-finding template"] end DH --> SHOR["1994 Shor: period-finding topples all four"] RSA --> SHOR ECC --> SHOR FEY --> DEU DEU --> SIM SIM --> SHOR SHOR --> GID["2021 to 2025 Gidney: concrete qubit bill"]

Two problems, one machine, a decades-long collision course -- and in 1994 a single person connected them. The bridge between the two lineages started as one strange little algorithm about a hidden XOR mask, and to understand how it grew into the break, you have to understand the one quantum trick that makes all of this work.

3. The One Trick That Matters

Before we can watch four fortresses fall, we have to kill a myth, because the myth predicts the wrong outcome. The popular story says a quantum computer "tries all the keys at once and reads out the winner." If that were true, it would break AES just as easily as RSA -- every symmetric cipher would fall too, and the entire second half of this article would be wrong. It is not true. A quantum computer does something far stranger and far more specific, and the specificity is the whole point.

Start with the one genuinely non-classical resource.

A register of $n$ qubits can occupy a weighted combination of all $2^n$ basis states at once, written $\sum_x \alpha_x |x\rangle$ where each complex number $\alpha_x$ is an amplitude. Applying a function to that register evaluates it on every input simultaneously. But the result is an internal state, not a readable list: when you measure, you get exactly one outcome $x$, drawn at random with probability $|\alpha_x|^2$, and the rest of the superposition vanishes.

This is where the myth breaks. Yes, you can evaluate a function on all $2^n$ inputs at once. No, you cannot read the answers. Measurement hands you a single random input-output pair, which is no better than guessing. Superposition alone buys you nothing. The art -- the entire art of quantum algorithms -- is what you do to the amplitudes before you measure.

The tool for that is interference. Amplitudes are complex numbers, and like waves they can add or cancel. If you can arrange the computation so that every path leading to a wrong answer is met by another path of opposite sign, the wrong answers cancel to near-zero amplitude, while the right answers reinforce. Measurement then returns a useful outcome with high probability -- not because you searched, but because you sculpted the wavefunction so that only the structure you care about is left standing.

Note: "A quantum computer tries every key in parallel and reads the winner" is wrong, and the error is not a detail. Parallel evaluation produces a superposition you cannot read; a single measurement collapses it to one random result. Every real quantum speedup comes from interference that cancels wrong answers -- and interference only helps when the problem has structure to exploit. Unstructured problems, like guessing an AES key, expose no such structure, which is exactly why they resist.

So which structure can interference exploit? The most powerful answer known is periodicity. Suppose a function $f$ is periodic: it repeats with some hidden period $r$, so that $f(x)$ and $f(x + r)$ always agree. Evaluate $f$ over a superposition of all inputs, and the state quietly organizes itself around that period. The instrument that reads it is the quantum Fourier transform.

The QFT is the quantum analogue of the discrete Fourier transform, applied to the amplitudes of a quantum state rather than to a list of numbers. Fed a state whose amplitudes repeat with a hidden period $r$, it concentrates the total amplitude onto the frequencies that match $r$, so that measuring the transformed state returns a multiple of $1/r$ with high probability. On an $n$-qubit register it runs in about $O(n^2)$ elementary gates [@nielsen-chuang-2010].

Put those pieces together and you have a machine that does exactly one magical thing: it takes a function with a hidden period and hands you that period. Superpose over all inputs, evaluate the function, and the act of computing it entangles the input register with the output so that the input register's amplitudes now repeat with the function's period. Apply the QFT, and interference collapses that repeating pattern onto its frequency. Measure, and you read out information about $r$ -- the period no classical observer could see without effectively checking the inputs one by one.

flowchart TD A["Superpose over all inputs x"] --> B["Evaluate f(x) into a second register"] B --> C["Measuring or entangling leaves the input register repeating with period r"] C --> D["Quantum Fourier transform concentrates amplitude on multiples of 1 over r"] D --> E["Measure: read a multiple of the hidden frequency"] E --> F["Classical post-processing recovers r"]

Key idea: A quantum computer does not search in parallel and read the winner. It engineers interference so that wrong answers cancel and only a function's hidden period survives measurement. No period, no exponential speedup -- which is precisely why the same machine that shatters RSA cannot touch a well-built symmetric cipher.

The first person to turn this into a concrete algorithm was Daniel Simon. In 1994 he built a toy problem -- a function that secretly satisfies $f(x) = f(x \oplus s)$ for a hidden bit-string $s$ -- and showed that quantum interference recovers $s$ exponentially faster than any classical method possibly could [@simon-1994].Simon's algorithm is the direct ancestor Shor read. Its "period" is a hidden XOR mask in a group of bit-strings, which breaks nothing anyone deployed. Shor's leap was to see the same template hiding inside a problem the entire economy depended on, and to swap Simon's simple transform for the QFT over the integers modulo $N$ [@simon-1994].

Simon's hidden period lived in a toy group and broke nothing real. But it proved the template: encode a secret as the period of a function, then let interference read it. The question that ended an era was the obvious next one -- what real, deployed, load-bearing problem is secretly period-finding in disguise?

4. The Breakthrough: Factoring Is Period-Finding

In 1994, at Bell Labs, Peter Shor answered that question with a move so clean it still reads like sleight of hand. Factoring -- the problem RSA stakes its life on -- is secretly a period-finding problem. Watch the reduction before the machinery, because the reduction is the whole trick.

To factor a large number $N$, pick a random integer $a$ with no common factor with $N$. Now consider the innocent-looking function $f(x) = a^x \bmod N$. Because there are only finitely many residues modulo $N$, this function must eventually repeat, and it repeats with a period: the smallest $r$ for which $a^r \equiv 1 \pmod N$. That period has a name.

The multiplicative order of $a$ modulo $N$ is the smallest positive integer $r$ such that $a^r \equiv 1 \pmod N$. It is exactly the period of the function $f(x) = a^x \bmod N$. Classically, finding $r$ appears about as hard as factoring $N$ itself. Quantumly, it is the one thing the QFT does well.

Here is why the order cracks the factorization. Suppose $r$ is even. Then $a^r - 1 = (a^{r/2} - 1)(a^{r/2} + 1)$ is divisible by $N$. Unless $a^{r/2} \equiv -1 \pmod N$ (a case you detect and retry), neither factor on the right is a multiple of $N$ by itself, so each shares only part of $N$'s prime structure. Computing $\gcd(a^{r/2} \pm 1,, N)$ with Euclid's ancient algorithm then hands you a non-trivial factor. For a random $a$, this works with probability at least one-half, so a couple of tries suffice [@shor-1994].

Every step in that paragraph is classical arithmetic you can run right now -- except one: finding the order $r$. That single sub-problem is where the quantum computer earns its keep, and it is period-finding exactly as Section 3 described it.

Superpose over all exponents $x$, compute $a^x \bmod N$ reversibly into a second register (this modular exponentiation is the dominant cost of the whole circuit), and the first register is left repeating with period $r$. Apply the QFT, and amplitude concentrates on multiples of $1/r$; measure, and you get an estimate of some $k/r$. A classical continued-fraction expansion then recovers $r$ from that estimate.

flowchart TD A["Pick random a in the range 2 to N minus 1"] --> B{"a coprime to N?"} B -->|no| Z["gcd(a, N) is already a factor -- lucky"] B -->|yes| C["Quantum step: find the order r of a mod N by QFT period-finding"] C --> D["Classical step: continued fractions recover r from the measured fraction"] D --> E{"r even and a^(r/2) not -1 mod N?"} E -->|no| A E -->|yes| F["Classical step: gcd(a^(r/2) +/- 1, N) yields a non-trivial factor"]

You do not need a quantum computer to see the reduction work, because only the order-finding is quantum. Compute the order by brute force on a small $N$, feed it into the same greatest-common-divisor step Shor uses, and a real factor drops out.

{` from math import gcd

def find_order(a, N): # multiplicative order of a mod N: smallest r >= 1 with a^r = 1 (mod N) x = a % N r = 1 while x != 1: x = (x * a) % N r += 1 if r > N: # safety: a was not coprime to N return None return r

def factor_via_order(N, a): if gcd(a, N) != 1: return gcd(a, N), N // gcd(a, N) # lucky: a already shares a factor r = find_order(a, N) if r is None or r % 2 != 0: return None # r odd -> pick another a and retry y = pow(a, r // 2, N) if y == N - 1: return None # a^(r/2) = -1 mod N -> retry return gcd(y - 1, N), gcd(y + 1, N)

for (N, a) in [(15, 7), (21, 2), (2047, 5)]: print("N =", N, " a =", a, " order r =", find_order(a, N), " factors =", factor_via_order(N, a))

N = 15 a = 7 order r = 4 factors = (3, 5) N = 21 a = 2 order r = 6 factors = (7, 3) N = 2047 a = 5 order r = 44 factors = (23, 89)

Add `(3233, 3)` to the list and it factors $3233 = 61 \times 53$ cleanly. Now add `(3233, 2)` and it returns `None`: with $a = 2$ the order is even but $a^{r/2} \equiv -1 \pmod{3233}$, the one case the reduction cannot use, so it must retry with a fresh $a$. That single `None` is the "probability at least one-half" caveat made concrete -- some choices of $a$ simply do not yield a factor, which is exactly why Shor picks $a$ at random and expects to need a couple of attempts.

The classical order search above is exponential in the number of digits -- run it on a 2048-bit $N$ and it never returns. Shor's contribution is to replace that one line with a quantum circuit that finds the same $r$ in polynomial time.Alexei Kitaev reformulated the quantum step in 1995 as phase estimation on the operator that multiplies by $a$, recovering $r$ from the eigenvalue's phase. It is mathematically equivalent to Shor's order-finding and is how most modern textbooks present the algorithm [@kitaev-1995]. How polynomial? The whole circuit is about $O((\log N)^3)$ gates, dominated by the modular exponentiation; the QFT itself is only $O((\log N)^2)$ [@nielsen-chuang-2010].

One precision point, flagged loudly because it will haunt Sections 7 and 8: that $O((\log N)^3)$ is a circuit size on a perfect, noiseless, fault-tolerant machine. It counts logical gates, not seconds. The distance between "a polynomial-size circuit exists" and "a machine ran it before lunch" is measured in millions of physical qubits, and we will pay that bill in full later.

Now the consequence that inverts fifty years of defensive instinct.

Note: Every classical attack on RSA gets exponentially harder as the key grows, so the entire history of the field has been "when the attacker catches up, add bits." Shor breaks that reflex. Its cost is polynomial in the number of bits $n = \log N$. Going from RSA-2048 to RSA-4096 roughly doubles $n$, so it multiplies the qubit and gate counts by a small constant -- not the exponential wall classical attackers slam into. The first move everyone reaches for is worthless here.

Shor's cost grows with the logarithm of the key, not the key. Against this attack, RSA-4096 is not meaningfully safer than RSA-2048 -- it is a rounding error safer.

Factoring was the first fortress to fall. But Shor's 1994 paper had a second half that almost nobody quotes, and it is the reason Diffie-Hellman, DSA, and elliptic curves fall too -- not by coincidence, but by the same mechanism running one dimension higher.

5. The Same Trick, Three More Times

If factoring is secretly period-finding, the natural question is: what else is? The answer is the entire argument of this article. Almost everything the deployed public-key world rests on is period-finding in disguise -- and Shor's own 1994 paper proved the second case himself.

Recall the discrete logarithm: given $g$ and $h = g^s$ in a cyclic group of order $r$, recover the exponent $s$. Shor's insight was that $s$ is also hidden inside a periodicity, only now the period lives in two dimensions instead of one. Here is the mechanism in full, because it is the load-bearing step and hand-waving it would cheat you of the aha.

Define the two-variable function

$$f(x, y) = g^x , h^y = g^{,x + s y}.$$

This function takes the same value whenever the exponent $x + s y$ is unchanged modulo $r$. So the set of shifts that leave $f$ invariant -- its hidden period, now a lattice of vectors rather than a single number -- is

$$L = {(x, y) \in \mathbb{Z}^2 : x + s y \equiv 0 \pmod{r}}.$$

That lattice encodes the secret $s$ directly in its slope. To read it, Shor superposes over both exponent registers and applies a two-dimensional QFT. Interference concentrates the amplitude onto the dual frequency vectors $(k_1, k_2)$ satisfying $k_1 + s,k_2 \equiv 0 \pmod{r}$. A single measurement returns one such pair, and whenever $\gcd(k_2, r) = 1$ you solve for the secret in one line of classical arithmetic:

$$s \equiv -,k_1 , k_2^{-1} \pmod{r}.$$

Look at what just happened. This is the exact same period-extraction that factored $N$ in Section 4 -- superpose, evaluate, transform, measure, post-process -- run in two dimensions instead of one [@shor-1994]. The discrete logarithm does not resist Shor any harder than factoring does; it surrenders the secret exponent directly. Finite-field Diffie-Hellman, DSA, and ElGamal all rest on precisely this discrete logarithm, so all three fall in the same stroke.

Elliptic curves are the same story one more time. The points on an elliptic curve form a finite abelian group under a geometric addition law, and "discrete logarithm" there means recovering the integer $s$ with $Q = sP$ for public points $P$ and $Q$. It is the same $f(x,y)$, the same two-dimensional period, the same 2-D QFT -- only the group operation changes. John Proos and Christof Zalka worked out the elliptic-curve version explicitly in 2003, and with it ECDH, ECDSA, and EdDSA join the list [@proos-zalka-2003].

Now the unification that turns three coincidences into one sentence.

Given a finite abelian group $G$ and a function $f$ on $G$ that is constant on the cosets of some hidden subgroup $H$ (and takes different values on different cosets), the abelian hidden subgroup problem is to find $H$. Order-finding, the finite-field discrete logarithm, and the elliptic-curve discrete logarithm are all special cases -- and the QFT with phase estimation solves every abelian instance in polynomial time [@kitaev-1995].

Alexei Kitaev supplied this abstraction in 1995 [@kitaev-1995]. Before it, "Shor breaks RSA" and "Shor breaks Diffie-Hellman" looked like two separate results that happened to use the same author's trick. After it, they are two instances of a single mathematical fact: the quantum Fourier transform reads a hidden period in any finite abelian group. Factoring hides its period in one dimension; both discrete logs hide theirs in two; the machine does not care which.

flowchart TD F1["Integer factoring -- RSA"] --> HSP["Abelian hidden subgroup problem: f is constant on the cosets of a hidden subgroup"] F2["Finite-field discrete log -- DH and DSA"] --> HSP F3["Elliptic-curve discrete log -- ECDH and ECDSA"] --> HSP HSP --> QFT["Quantum Fourier transform reads the hidden period"] QFT --> O1["RSA falls"] QFT --> O2["Diffie-Hellman and DSA fall"] QFT --> O3["ECDH and ECDSA fall"]

Key idea: The four are not four security problems. They are one -- a hidden abelian period -- wearing four disguises. Factoring hides it in one dimension; the two discrete logs hide it in two. One machine, one idea, four falls.

Two precautions before the table. First, "together" means the same machine class and the same breakthrough, not one identical circuit pressing a single button. RSA, a finite field, and an elliptic curve need different arithmetic units compiled into the machine; what they share is that each reduces to the abelian HSP, so one fault-tolerant quantum computer running Shor's family of circuits dispatches all of them. Second -- and this is the counterintuitive kicker -- the four do not fall in the order their reputations suggest. Elliptic-curve cryptography, the strongest of the four against classical attack, falls first.

Why? Because ECC's classical strength is small keys. No sub-exponential attack applies to a well-chosen curve, so a 256-bit elliptic key matches the classical security of a 3072-bit RSA key [@nist-sp800-57]. Against Shor, "fewer bits" simply means "fewer logical qubits to build."

Martin Roetteler and colleagues estimated in 2017 that breaking the NIST P-256 curve needs about 2330 logical qubits [@roetteler-2017] -- materially fewer than the roughly 6200 logical qubits (about $3n$) a 2048-bit RSA break requires [@gidney-ekera-2021]. Proos and Zalka had already found the same inversion in 2003: about 1000 qubits for 160-bit ECC versus about 2000 for the security-equivalent 1024-bit RSA [@proos-zalka-2003].Those small keys also pay a purely classical dividend that has nothing to do with quantum computers: at equal classical security an ECC certificate and its handshake messages are a fraction of the size of the RSA equivalent, which trims bandwidth and storage on every connection they protect.

"ECC is an easier target than RSA." -- Roetteler, Naehrig, Svore, and Lauter, 2017

The full ledger, with the survivor included so the contrast is unmissable:

Primitive	Underlying hard problem	Hidden abelian period?	Quantum attack	Do bigger keys help?	Logical-qubit estimate
RSA-2048	Integer factoring	Yes -- one-dimensional order	Shor order-finding	No	~6200 (about $3n$) [@gidney-ekera-2021]
Finite-field DH / DSA-2048	Discrete log modulo a prime	Yes -- two-dimensional period	Shor DLP variant	No	Comparable to RSA-2048 [@gidney-ekera-2021]
ECDH / ECDSA (P-256)	Elliptic-curve discrete log	Yes -- two-dimensional period	Shor via Proos-Zalka	No	~2330 -- falls first [@roetteler-2017]
AES-256	None -- unstructured key	No period at all	Grover only (quadratic)	Yes -- doubling suffices	Not applicable [@bbbv-1997]

Three rows share the "yes" column, and that shared "yes" is the entire vulnerability. One machine, one idea, four falls -- and yet AES-256 in the field next door survives untouched. That survival is not luck, and it is not a gap someone will patch next year. It is the second half of the thesis, and it has a proof.

6. Why Symmetric Crypto Only Loses a Square Root

Return to AES-256, standing untouched in the next field. The same machine that reads RSA's period in polynomial time barely dents it. The reason is exactly the reason RSA falls: AES hides no period. There is no abelian structure inside a well-designed cipher for the QFT to grab, so the exponential engine has nothing to bite on. What is left is the generic attack that works on any search problem, structured or not.

Grover's algorithm finds a marked item in an unstructured space of $N$ candidates using about $\sqrt{N}$ evaluations of a test function, a quadratic speedup over the roughly $N/2$ a classical search expects [@grover-1996]. For an $n$-bit key there are $N = 2^n$ candidates, so Grover's query count is about $2^{n/2}$: AES-128 drops to about $2^{64}$ queries, AES-256 to about $2^{128}$.

At a glance that looks alarming -- $2^{64}$ sounds within reach. Hold that thought; it is the most misunderstood number in the field, and we will dismantle it in a moment. First, the structural point, because it is what makes the symmetric world safe by design rather than by luck.

The quadratic speedup is not a weak version of Shor's exponential one. It is a different kind of thing, and its weakness is provable. Bennett, Bernstein, Brassard, and Vazirani proved in 1997 that any quantum algorithm searching an unstructured space needs at least on the order of $\sqrt{N}$ queries -- the $\Omega(\sqrt{N})$ lower bound [@bbbv-1997]. Grover is optimal; you cannot do better against a structureless target.

This is the single most important bound in the article, because it converts "we do not know a better attack on AES" into "there provably is no better generic attack." Shor exists because factoring has structure. Grover is the best you can ever do precisely when there is none.

{` // Classical brute force is 2^n; Grover's floor is 2^(n/2). // This compares EXPONENTS -- it is a query lower bound, not a runtime. function keyStrength(nBits) { return { classical: nBits, grover: nBits / 2 }; // log2 of each cost }

for (const n of [128, 192, 256]) { const s = keyStrength(n); console.log("AES-" + n + ": classical 2^" + s.classical + " vs Grover floor 2^" + s.grover); }

// Doubling the key restores the pre-quantum margin: const groverAes256 = keyStrength(256).grover; // 2^128 const classicalAes128 = keyStrength(128).classical; // 2^128 console.log("AES-256's Grover floor 2^" + groverAes256 + " equals AES-128's old classical margin 2^" + classicalAes128); // AES-128: classical 2^128 vs Grover floor 2^64 // AES-256: classical 2^256 vs Grover floor 2^128 `}

So doubling the key exactly undoes Grover: AES-256's $2^{128}$ Grover floor restores the $2^{128}$ margin AES-128 used to enjoy classically. But "double the key" undersells how safe AES-128 already is, and here is where the popular $2^{64}$ falls apart.

That $2^{64}$ is a floor on operations, not a feasible runtime. Three facts, each independently decisive, separate the number from any real attack. First, Grover is inherently sequential: its roughly $2^{n/2}$ iterations must be applied one after another, and each iteration contains a full evaluation of AES as a reversible quantum circuit -- a deep block of gates, not a single step [@grassl-2015]. You cannot collapse the iterations into a shallow parallel circuit.

Second, it barely parallelizes: split the search across $P$ machines and each one's work drops by only $\sqrt{P}$, not $P$. Christof Zalka proved this is fundamental -- quantum searching "cannot be parallelized better than by assigning different parts of the search space to independent quantum computers" [@zalka-1999]. Throwing a thousand quantum computers at AES-128 buys a factor of about 31, not 1000.

Third, and most concrete: real machines have a maximum circuit depth. NIST's post-quantum call formalized this as MAXDEPTH, with plausible values of ${2^{40}, 2^{64}, 2^{96}}$ serial logical gates -- roughly a year, a decade, and a millennium of continuous computation. Under that constraint, NIST estimated the cost of a Grover key search on AES-128 at about $2^{170}/\text{MAXDEPTH}$ quantum gates, versus $2^{143}$ classical gates -- because "one has to run many smaller instances of the algorithm in parallel, which makes the quantum speedup less dramatic" [@nist-cfp-2016].

Even with MAXDEPTH at a decade ($2^{64}$), that is about $2^{106}$ gates. Depth-restricted analyses of explicit AES Grover oracles confirm the picture and underpin NIST's security categories [@jaques-2020]. The clean $2^{64}$ was always a lower bound on abstract queries, never a wall-clock estimate.

Note: Symmetric cryptography survives not by being stronger than RSA but by being structureless: no hidden period, so no Shor, only a provably quadratic nibble -- and even that nibble is a floor on operations under a depth limit, not a runtime. AES-256 is not a nervous hope. It is a proof-backed hedge.

The comparison, side by side:

Property	Symmetric (AES-256, SHA-384)	Asymmetric (RSA, DH, DSA, ECC)
Exploitable abelian period?	No	Yes
Best quantum attack	Grover search	Shor period-finding
Speedup over classical	Quadratic (square-root)	Exponential
Provably optimal attack?	Yes -- $\Omega(\sqrt{N})$ [@bbbv-1997]	Not applicable -- structure gives it away
Effect of doubling the key	Restores the full margin	Negligible
Survives Q-Day?	Yes	No

Note: For symmetric primitives the fix is boring and effective: prefer AES-256 over AES-128, and SHA-384 or SHA-512 over SHA-256. Because Grover is only quadratic -- and, under a depth limit, far weaker than even that -- doubling the security parameter is not just adequate, it is sufficient with margin to spare [@nist-cfp-2016]. No new mathematics, no migration project. The hard problem is entirely on the public-key side.

One honest fence marks the edge of that "only Grover" claim.

There is a model in which symmetric constructions fall exponentially, not quadratically. In the superposition-query (Q2) model, where an attacker can query a secret-keyed device on a superposition of inputs, Kaplan and colleagues showed in 2016 that Simon's algorithm breaks specific *modes* -- Even-Mansour, CBC-MAC, GMAC -- in polynomial time [@kaplan-2016]. This is real and important, but note what it requires: physical access to a keyed oracle that will accept quantum superpositions as input, an implementation-and-protocol assumption, not a structural weakness of the AES primitive. This article's contract is structural-only, and under the realistic classical-query model the "symmetric loses just a square root" claim holds. The Q2 mode attacks belong to the sibling post on how cryptography breaks in real life, alongside side channels and fault attacks.

So the break is real, the boundary is sharp, and the algorithm has been proven on paper for thirty years. Only one thing still stands between the mathematics and your ciphertext: a machine that does not yet exist. Building it is where the story turns from algorithms to engineering -- and where the price tag appears.

7. From Algorithm to Machine: Fault Tolerance and the Qubit Bill

A polynomial-time algorithm is not a polynomial-time afternoon. Shor's circuit is small on paper, but "on paper" assumes qubits that never make a mistake and never forget. Real qubits do both, constantly. Run a bare Shor circuit on today's noisy hardware and it dissolves into random noise long before the modular exponentiation finishes. Closing the gap between the proof and the machine is an engineering problem measured in millions of qubits, and it has a structure worth understanding, because that structure is where the cost estimates come from -- and where they are falling.

Begin with the distinction the whole field turns on.

A physical qubit is one noisy device -- a superconducting transmon, a trapped ion, a neutral atom -- with an error rate around $10^{-3}$ per operation. A logical qubit is an error-corrected qubit assembled from many physical ones, whose effective error rate can be pushed arbitrarily low by adding more physical qubits, provided each is already below a threshold error rate. Shor's circuit counts logical qubits and logical gates; the machine must manufacture them out of vastly more physical hardware.

The manufacturing method is quantum error correction, and the workhorse is the surface code.

The surface code lays physical qubits on a two-dimensional grid and repeatedly measures local parity checks that reveal where errors occurred without measuring -- and thus destroying -- the stored quantum information. Its defining property: the logical error rate falls exponentially as the code distance $d$ (roughly the grid width) grows, as long as physical errors stay below about $1\%$. It is the code behind every concrete Shor resource estimate [@google-willow-2025].

Error correction handles the memory and the easy gates, but Shor also needs "non-Clifford" gates -- the T and Toffoli operations that do the genuinely quantum arithmetic -- and those cannot be done directly on surface-code qubits. They are supplied through a separate factory that distills noisy inputs into clean "magic states."The modern version of that factory is magic-state cultivation, which reaches logical error rates as low as $2 \times 10^{-9}$ under $10^{-3}$ circuit noise and, in its authors' words, hints that "further magic state distillation may never be needed in practice" -- shaving one of the largest overheads in the whole bill [@magic-state-cultivation-2024]. Stack it all together and you get the fault-tolerance pyramid every estimate rests on.

flowchart TD P["Thousands of noisy physical qubits, about 1 percent error each"] --> S["Surface-code patch: parity checks suppress errors exponentially in code distance"] S --> L["One reliable logical qubit"] M["Magic-state cultivation: clean T and Toffoli states"] --> G["Non-Clifford gates that Shor requires"] L --> G G --> SHOR["Fault-tolerant Shor circuit: about 3n logical qubits, billions of gates"]

Now the part that reframes the entire threat. Line up the resource estimates chronologically and hold the hardware assumptions fixed, and you see the price of Q-Day collapsing -- not because anyone built a better qubit, but because the algorithms kept improving.

Year	Target	Qubits	Runtime	What changed	Source
2003	160-bit ECC	~1000 logical	--	First elliptic-curve estimate	Proos-Zalka [@proos-zalka-2003]
2017	P-256 ECC	2330 logical	--	Simulation-backed qubit formula	Roetteler et al. [@roetteler-2017]
2020	ECC curves	fewer logical gates	--	Optimized ECDLP circuits	Haner et al. [@haner-2020]
2021	RSA-2048	20 million physical	8 hours	First full fault-tolerant bill	Gidney-Ekera [@gidney-ekera-2021]
2023	RSA-2048	asymptotic	~$O(n^{3/2})$ gates	First asymptotic gate win in ~30 years	Regev [@regev-2023]
2025	RSA-2048	under 1 million physical	under a week	Better algorithms, same 2019 hardware	Gidney [@gidney-2025]

Read the last three rows slowly. In 2021 Craig Gidney and Martin Ekera published the first end-to-end physical estimate: about 20 million noisy physical qubits, 8 hours, assuming a surface code with $10^{-3}$ gate error, a microsecond cycle time,A surface-code cycle is one full round of parity measurement across the patch; the estimate assumes roughly one microsecond per round, so an 8-hour run is on the order of tens of billions of rounds. and short-discrete-log refinements from Ekera and Hastad folded in [@gidney-ekera-2021][@ekera-hastad-2017].

In 2023 Oded Regev found the first asymptotic reduction in Shor's gate count in three decades -- roughly $O(n^{3/2})$ gates -- though he flagged it as resting on a heuristic and not clearly practical, and its variant trades gate count for extra space whose real-world cost is still unsettled [@regev-2023]. Then in 2025 Gidney returned with a new estimate: fewer than one million physical qubits, under a week -- and, in a line worth pausing on, the same 2019 hardware assumptions he used in the 20-million estimate [@gidney-2025].

Twenty million qubits to under one million in six years -- same author, same hardware assumptions, one-twentieth the machine. The mathematics improved, not the metal.

That drop happened with no improvement in the underlying qubits at all: the estimate, not the machine, was the moving part, which means the cost of Q-Day keeps falling on the strength of pure algorithm design, independent of when good hardware arrives. That is the uncomfortable dynamic hiding behind every "quantum is decades away" headline: the target keeps moving toward us on the math axis while we wait for the hardware axis. The algorithm's price tag is collapsing on its own schedule. So the only question left is the one everyone actually asks -- how close is the machine itself?

8. Where the Hardware Actually Is (and Isn't)

State the honesty anchor flatly, because everything downstream depends on it: as of 2026, no cryptographically relevant quantum computer exists. Not "almost," not "in a classified lab somewhere." None. The public state of the art is three to four orders of magnitude short of a Shor attack, and it helps to see exactly how short, because the headlines and the reality use the same words to mean different things.

A CRQC is a quantum computer large and reliable enough to run Shor's algorithm against real deployed keys -- on the order of a few thousand logical qubits held coherent through billions of gates, which with today's overheads means roughly a million physical qubits. It is a specific threshold. A 100-qubit noisy processor, however valuable for physics, is not a small CRQC and cannot be scaled into one without error correction.

The state of the art splits cleanly into two regimes, and conflating them is the source of most confusion. The first is fully below-threshold error correction -- the hard, scalable kind, where adding qubits genuinely drives the error down.

Google's Willow is the reference point: a distance-7 surface-code patch, a 7-by-7 array of 49 data qubits totaling 101 physical qubits, encoding exactly one logical qubit. The logical error is suppressed by a factor $\Lambda = 2.14 \pm 0.02$ for each two-step increase in code distance, and its lifetime beats its best physical qubit by 2.4 times [@google-willow-2025].That $\Lambda$ greater than 1 is the whole result: it is the first convincing demonstration that a real surface code operates below threshold, so that making the patch bigger makes the logical qubit better rather than worse. The number to remember is the ratio: about 100 physical qubits for one good logical qubit, today [@google-willow-2025]. So the scalable frontier stands at roughly one logical qubit built from about a hundred physical ones.

The second regime is error detection at low code distance, and it is where the "tens of logical qubits" headlines come from. A neutral-atom processor from a Harvard, MIT, and QuEra collaboration entangled up to 48 logical qubits using small [[8,3,2]] code blocks (alongside 40 color-code qubits and a surface-code logical operation scaled across code distances) on up to 280 physical qubits [@bluvstein-2024]. That is a genuine milestone -- but these are transversal, post-selected error-detection demonstrations, which throw away runs where an error is spotted, not a scalable below-threshold memory that can run for billions of gates.

On the trapped-ion side, Quantinuum ran a handful of logical qubits with full repeated error correction: a [[7,1,3]] code and a [[12,2,4]] code based on Knill's C4/C6 scheme (two logical qubits), the first reaching error rates 9.8 to 500 times below the physical rate and the second 4.7 to 800 times below it [@quantinuum-2024].

Put the three numbers next to the requirement and the chasm is obvious. Fully below-threshold correction reaches about one logical qubit on superconducting hardware and a couple on trapped ions; error detection reaches a few tens on neutral atoms.

A CRQC needs about 2330 logical qubits for the P-256 curve [@roetteler-2017], or roughly $3n$ -- at least 6200 -- for RSA-2048, backed by fewer than a million physical qubits [@gidney-2025]. Between "48 post-selected logical qubits in a detection demo" and "a few thousand fully corrected logical qubits running Shor for hours" lie three to four orders of magnitude and several unsolved engineering problems.

When, then? The honest answer is a window, not a date. Expert judgment clusters the arrival of a CRQC in roughly the 2030 to 2035 range with wide uncertainty on both sides. The most-cited proxy, the Global Risk Institute and evolutionQ expert-survey timeline, reports figures on the order of 28 to 49 percent probability within ten years [@quantum-threat-timeline] -- but that number must be quoted with its qualifier: it is a survey of expert opinion, not a measured or primary-verified quantity, and the defensible claim is the qualitative window, not any single percentage.

Note: The absence of a machine today would be comforting if secrets expired the moment they were sent. They do not. An adversary can record your encrypted traffic now and store it until a CRQC arrives, then decrypt it retroactively. For any data whose confidentiality must outlive the 2030s, "no quantum computer exists yet" provides exactly zero protection. The clock started when the ciphertext was first captured, not when the machine boots.

The gun is loaded and sitting on the table. Its trigger is an engineering trajectory, not a delivered capability, and the timeline is a judgment rather than a promise -- but a judgment that says "sometime in the next decade" is not a judgment you can safely ignore for data that must stay secret into the 2040s. Before we talk about who has to move first, one question decides everything downstream: what, exactly, does this machine not break?

9. What Q-Day Does Not Break

The blast radius is bounded, and the boundary is the thesis restated as a theorem: Shor breaks exactly the abelian-hidden-subgroup primitives, and nothing else structurally. Everything on the safe side of that line survives Q-Day, and a whole field of cryptography was deliberately built there.

Start the inventory. Symmetric ciphers and hashes survive with only Grover's quadratic nibble, as Section 6 proved. Hash-based signatures such as SLH-DSA rest on nothing but the preimage and collision resistance of a hash function, so they inherit that same square-root safety and no more [@fips-205]. And the new public-key families -- lattices, codes, isogenies, multivariate systems -- survive because not one of them is an abelian hidden-subgroup problem. The QFT has no period to read.

The sharpest way to say why is to name the structure lattices actually touch.

The dihedral group is non-abelian: its elements do not all commute. The hidden subgroup problem over it is the natural non-abelian cousin of the one the QFT dispatches so easily -- but the Fourier machinery that concentrates amplitude so neatly in the abelian case does not do so here. Despite two decades of effort, the best known quantum algorithm is Kuperberg's, running in sub-exponential but still super-polynomial time $2^{O(\sqrt{\log N})}$ [@kuperberg-2003]. Certain lattice problems relate to it, which is one reason lattice cryptography is believed quantum-resistant.

Notice the symmetry. The abstraction that unifies the attack -- the abelian HSP -- is the very same abstraction that bounds it. Cross from abelian to non-abelian structure and the QFT stops working, Shor's polynomial-time guarantee evaporates, and the best anyone has managed in twenty years is sub-exponential. That single conceptual line is the design premise of post-quantum cryptography.

But here precision matters more than anywhere else in the article, because the most natural way to summarize this is wrong and plants a misconception. It is tempting to write that the best quantum attack on lattice schemes is Kuperberg's sub-exponential algorithm. It is not, for three reasons worth stating explicitly.

First, the attack that actually sets lattice key sizes is not a hidden-subgroup attack at all. It is lattice sieving -- quantum-accelerated BKZ -- and it is exponential. Heuristic quantum sieving for the shortest-vector problem runs in about $2^{0.312n + o(n)}$, against the classical $2^{0.384n + o(n)}$ [@laarhoven-2013]. Quantum search shaves the constant in the exponent; it never reaches sub-exponential. Lattice parameters are chosen against that exponential wall.

Second, the famous link between lattices and the dihedral HSP is a one-directional reduction, not a usable attack. Regev showed in 2004 that a dihedral-HSP solver by coset sampling would break the unique shortest-vector problem [@regev-2004] -- but there is no known way to prepare the required dihedral coset states from an actual lattice instance. The implication runs from "hypothetical dihedral solver" to "broken lattice," not the other way, so you cannot feed a real lattice problem into Kuperberg's algorithm and get an attack out.

Third, Kuperberg's sub-exponential algorithm genuinely is the best known attack -- but for a different family. Commutative-isogeny schemes like CSIDH are built on an abelian group action, a hidden-shift problem, and there Kuperberg's algorithm really does set the parameters [@csidh-2018][@kuperberg-2003]. The "Kuperberg" label belongs on a CSIDH row, never on the lattice row. With that fixed, here is the honest ledger of what falls and what stands.

Primitive	Underlying problem	Abelian HSP?	Best known quantum attack	Verdict
RSA / DH / DSA / ECC	Factoring, discrete log	Yes	Shor -- polynomial	Broken
AES-256, SHA-384/512	Unstructured key or preimage	No	Grover -- quadratic (optimal)	Safe: double the parameter [@bbbv-1997]
SLH-DSA (hash signatures)	Hash preimage and collision	No	Grover -- quadratic	Safe [@fips-205]
ML-KEM / ML-DSA (lattice)	Module-LWE	No	Exponential lattice sieving $2^{\Theta(n)}$	Believed safe [@laarhoven-2013]
CSIDH (commutative isogeny)	Abelian group action, hidden shift	Group action	Kuperberg -- sub-exponential	Sized against Kuperberg [@kuperberg-2003]

Key idea: The line Shor cannot cross is the line between abelian and non-abelian structure -- and that single line is the entire design premise of post-quantum cryptography. Lattice schemes are not "probably too hard to bother with"; they sit provably on the far side of the abstraction that makes Shor work.

Two counterweights keep this from becoming triumphalism, and they cut in opposite directions.

Note: Nobody has ever proven that factoring or the discrete logarithm is classically hard. Factoring's decision version sits in NP intersect co-NP and is not believed NP-complete, so Shor exploits special structure, not raw NP-hardness. That means Shor is the known structural break -- not a proof that no classical shortcut exists. The public-key world was never standing on proven ground; it was standing on ground nobody had found a way through yet.

In 2022 Wouter Castryck and Thomas Decru broke SIDH, a leading isogeny-based candidate, recovering the key of SIKEp434 in about ten minutes on a single classical core [@castryck-decru-2022]. No quantum computer was involved. Two lessons follow. First, do not conflate "elliptic-curve" with "Shor target": SIDH is isogeny-based, a different hard problem, and it fell to classical mathematics, not to Q-Day. Second, the post-quantum assumptions are themselves young and unproven, and SIDH is proof that a scheme can be quantum-immune and still catastrophically broken. Note also that SIDH is not CSIDH: one collapsed classically, the other still stands, sized against Kuperberg.

So Shor is a scalpel, not a bomb. It cuts exactly one structure -- the abelian hidden period -- and a whole field of cryptography was engineered to live on the parts it cannot reach. That field exists for exactly one reason, and with every piece now on the table, it is time to name it.

10. Why This One Event Is the Whole Reason PQC Exists

Assemble the pieces and one sentence follows that you now have every reason to accept. Because RSA, Diffie-Hellman, DSA, and elliptic-curve cryptography share exactly one crack -- the abelian period the QFT reads -- that crack is not four separate vulnerabilities. It is a single point of failure for nearly the entire deployed public-key world. And a single point of failure of that magnitude does not get patched. It gets routed around, by building a replacement on the far side of the abelian line.

One shared crack under four fortresses is not four vulnerabilities. It is one -- a single point of failure for nearly all deployed public-key cryptography. Post-quantum cryptography is the world's response to that one fact.

That response is already machinery, and every gear traces back to Shor. In 2016 NIST opened a public competition to standardize quantum-resistant algorithms [@nist-pqc-project]; on 13 August 2024 it published the first three standards -- FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for signatures, and FIPS 205 (SLH-DSA) for hash-based signatures [@fips-203][@fips-204][@fips-205].

The NSA's CNSA 2.0 suite sets a national-security transition timeline and, tellingly, keeps AES-256 and SHA-384/512 on the symmetric side because those need no replacement [@nsa-cnsa-2.0]. And in 2026 the United States made it binding: Executive Order 14412 requires high-value systems to adopt post-quantum key establishment by 31 December 2030 and post-quantum signatures by 31 December 2031 [@eo-14412].

There is a quiet revival buried in that timeline. The lattice hardness now anchoring ML-KEM and ML-DSA is not new: Miklos Ajtai put worst-case lattice hardness on a rigorous footing in 1996, and NTRU shipped a ring-based lattice cryptosystem in 1998 [@ajtai-1996][@ntru-1998]. Both sat in a niche for two decades. What changed their fortunes was not a new theorem -- it was Shor turning "hardness the quantum Fourier transform cannot read" into the single most valuable property a cryptosystem can have, and a generation of survey work mapping out the lattice, code, hash, and isogeny families that possess it [@bernstein-lange-2017].

But standards and deadlines only matter if they beat the clock, and the clock is subtle, because it started ticking before the machine exists. Michele Mosca captured the logic in a single inequality.

Let $X$ be the years your organization needs to migrate to quantum-safe cryptography, $Y$ the years your data must stay confidential, and $Z$ the years until a CRQC exists. If $X + Y > Z$, then data you protect today will still be sensitive when the machine arrives -- so you are already exposed, no matter how far off Q-Day turns out to be [@mosca-2018]. flowchart LR X["X: years to migrate"] --> SUM["X + Y"] Y["Y: years data must stay secret"] --> SUM Z["Z: years until a CRQC exists"] --> CMP{"X + Y greater than Z?"} SUM --> CMP CMP -->|yes| EXP["Already exposed: harvested ciphertext will be readable"] CMP -->|no| OK["Safe, for this data, for now"]

The inequality has teeth because of the harvesting strategy that makes $Z$ irrelevant for confidentiality.

Harvest-now-decrypt-later is the practice of recording encrypted traffic today and storing it until a quantum computer can decrypt it. It converts a future capability into a present threat: the confidentiality of a long-lived secret is compromised the moment its ciphertext is captured, not the moment Q-Day arrives.

Note: If an adversary is recording your encrypted traffic now -- and for high-value targets it is safe to assume someone is -- then every secret with a shelf life into the 2030s is effectively in the open already. You cannot un-send the ciphertext. This is the reason the migration cannot wait for proof that a CRQC exists: by the time the proof arrives, the harvested data is decades into its exposure. The empirical side of this -- who is harvesting, what is already at risk, and what the captured traffic looks like -- is the subject of the companion post, "How Q-Day Is Already Breaking Things: Harvest Now, Decrypt Later."

This is the hinge of the whole series, so state it without hedging. The post-quantum migration is not a bet on when quantum computers will arrive. It is a response to one already-proven mathematical fact -- that Shor's algorithm reads the shared abelian period under RSA, Diffie-Hellman, DSA, and ECC -- combined with one strategic fact, that adversaries can harvest today and decrypt later. Neither of those facts depends on a machine booting up. Which means the work starts now, not on Q-Day. So what, concretely, do you do before the machine that does not yet exist finally does?

11. What To Do Before Q-Day

You cannot buy a cryptographically relevant quantum computer, and you cannot wait for one to appear before acting -- harvest-now-decrypt-later has already seen to that. The good news is that the pre-Q-Day checklist follows directly from the thesis, and every item on it is doable today with shipping standards.

1. Inventory every use of RSA, DH, DSA, ECDH, and ECDSA. Build a cryptographic bill of materials: where each algorithm lives, which keys protect what, and how long each secret must last. This is not busywork. Because all four primitives share one crack, nothing on that list is safe by virtue of key size, curve choice, or obscurity -- the inventory is the map of your entire exposure.

2. Triage by secrecy lifetime. Run Mosca's inequality on each data class. Anything whose confidentiality must outlive the CRQC window -- health records, state secrets, long-lived credentials, genomic data -- migrates first, because for that data $X + Y > Z$ already holds [@mosca-2018]. You can compute the gap directly.

{` // If migration time X + secrecy lifetime Y exceeds time-to-CRQC Z, you are exposed. function mosca(X, Y, Z) { const exposed = (X + Y) > Z; const gap = (X + Y) - Z; // positive gap = years of exposure return { exposed, gap }; }

3. Deploy hybrid key establishment now. Combine a classical exchange with a lattice one -- for example the X25519MLKEM768 hybrid -- so that a future CRQC cannot decrypt today's captured sessions, while a flaw in the young post-quantum scheme still leaves the classical layer standing [@fips-203]. Hybrids are the pragmatic answer to "the abelian period is readable" and "the new assumptions are unproven" at the same time.

4. Migrate signatures on their own timeline. Move to ML-DSA or SLH-DSA, but recognize the urgency differs from confidentiality [@fips-204][@fips-205]. A forged signature requires a CRQC at signing time; there is nothing an adversary can harvest today and forge later. Confidentiality is the harvestable asset, so it leads.

Harvest-now-decrypt-later threatens *confidentiality*: recorded ciphertext sits waiting for the machine. Signatures are different -- forgery needs a CRQC while the signing key is still trusted, so there is no equivalent of a stored capture that becomes forgeable in hindsight. This is why key establishment carries the earlier deadline in Executive Order 14412 than signatures do. The exception is long-lived roots of trust -- certificate-authority roots, firmware-signing keys valid for a decade or more -- whose validity windows reach into the CRQC era and so deserve early attention.

5. Take the cheap symmetric hedge. Prefer AES-256 over AES-128 and SHA-384 or SHA-512 over SHA-256. As Section 6 established, Grover is only quadratic -- and under a realistic depth limit, far weaker than even that -- so doubling the security parameter is sufficient, not merely hopeful [@bbbv-1997]. This is the one part of the migration that costs almost nothing.

6. Build crypto-agility. Design so the algorithm can be swapped without re-architecting the protocol, so the next transition is a configuration change rather than another decade-long project.

Crypto-agility is building systems so a cryptographic algorithm can be replaced without redesigning the protocol or application around it. It turns a future migration from a rebuild into a swap.

Crypto-agility is doubly warranted here, because the destination assumptions are young. SIDH's classical collapse in 2022 is the standing reminder that a scheme can look quantum-safe and still fail for reasons no one anticipated [@castryck-decru-2022]. Agility is how you survive being wrong about the replacement.

For the details of what to migrate to -- parameter sets, performance trade-offs, and deployment patterns -- this series' post-quantum-toolkit and crypto-agility installments carry the load, and the implementation-hardening questions (side channels, fault attacks, and the rest) belong to the empirical sibling, per this article's structural-only contract. None of it waits for the machine. That is the whole point -- and it is why the last few questions people always ask deserve straight, mechanism-grounded answers.

12. Sharp Questions, Straight Answers

No. The threat to confidentiality is already live through harvest-now-decrypt-later: an adversary records your encrypted traffic today and decrypts it once a CRQC exists [@mosca-2018]. If your data must stay secret into the 2030s, the absence of a machine in 2026 protects nothing -- the ciphertext is already captured, and you cannot un-send it. No. Symmetric primitives expose no abelian period, so Shor does not apply; they face only Grover's quadratic speedup, which is provably the best any quantum attacker can do against unstructured search [@bbbv-1997]. And even that is a floor on operations, not a runtime: under NIST's MAXDEPTH depth limit, an AES-128 key search costs about $2^{170}/\text{MAXDEPTH}$ quantum gates [@nist-cfp-2016]. Prefer AES-256 and SHA-384/512 and the problem is closed. No, and this is the counterintuitive part. Shor's cost is polynomial in the number of key bits, so going from RSA-2048 to RSA-4096 buys a small constant, not security [@shor-1994]. Worse for the intuition: elliptic curves use *smaller* keys, so they need *fewer* logical qubits and fall first -- about 2330 logical qubits for P-256 versus roughly 6200 for RSA-2048 [@roetteler-2017][@gidney-ekera-2021]. Same machine class and same breakthrough, not one identical circuit. RSA, a finite field, and an elliptic curve need different arithmetic compiled into the machine, but each reduces to the abelian hidden-subgroup problem, so one CRQC running Shor's family dispatches all of them [@kitaev-1995]. If anything, elliptic-curve schemes fall a step ahead because they need the fewest qubits [@roetteler-2017]. No -- and this conflation is a common trap. The broken isogeny scheme SIDH was not defeated by Shor at all; Castryck and Decru broke it with classical mathematics in about ten minutes on one core [@castryck-decru-2022]. "Elliptic-curve" is not the same as "Shor target." Isogeny problems are a different structure, and their risks (as SIDH showed) can be entirely classical. The migration is not a bet on hardware timing. Mosca's inequality shows that if migration time plus secrecy lifetime exceeds time-to-CRQC, you are already exposed [@mosca-2018]. Meanwhile the cost estimates keep falling on algorithmic progress alone -- 20 million qubits to under a million in six years, same hardware assumptions [@gidney-ekera-2021][@gidney-2025] -- and the underlying algorithm has been proven for three decades. The proof is not in doubt; only the schedule is.

Step back to the single image the whole article was built to earn. Four cryptographers, four decades, four branches of mathematics -- and one hidden period beneath all of them. RSA, Diffie-Hellman, DSA, and elliptic curves were never four independent bets. They were one bet, that a hidden abelian period is hard to find, made four times in four disguises.

Shor's algorithm reads that period with the quantum Fourier transform and collects on all four at once, while AES-256 in the next field survives for the mirror-image reason: it hides no period, so the same machine can do no better than a provably quadratic nibble. That asymmetry -- abelian falls, non-abelian stands -- is not a footnote. It is the exact line post-quantum cryptography was engineered to live behind.

The shared quantum vulnerability of RSA, Diffie-Hellman, DSA, and elliptic curves is a single point of failure, and that single point is the whole reason post-quantum cryptography exists. The algorithm is proven; the machine is not here yet; and the distance between those two facts is not your safety margin -- it is your deadline.

The gun is loaded and on the table. No one has fired it, and no one can say precisely when someone will. But the mathematics that makes it fire was settled in 1994, the price of ammunition is falling every year, and some of the secrets it will read are being recorded right now. That is why the work does not start on Q-Day. It starts today.

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.

How RSA Would Break: Why Factoring Is the Slow Path and Coppersmith Is the Fast One

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

Most people picture an RSA break as someone factoring the modulus. That is the slowest, least-likely path there is: the best classical sieve methods (the quadratic sieve, then the General Number Field Sieve) are sub-exponential, and the record has crawled from 426-bit RSA-129 in 1994 to 829-bit RSA-250 in 2020, still a universe short of a 2048-bit key [@boudot-rsa250-2020]. The fast cracks never factor `N` at all. Coppersmith's lattice method, Wiener's small-`d` attack, and their relatives run in polynomial time, but only when a parameter or key-generation choice deviates from the ideal [@boneh-survey-1999]. Against a correctly generated RSA-2048 key with `e = 65537`, a full-size random `d`, and OAEP padding, every one of those preconditions is absent, so the fast lane has no applicable attack. The only structural attack that breaks a well-formed key is Shor's quantum algorithm, which as of 2026 waits on hardware that does not yet exist [@shor-siam-1997; @gidney-2025].

1. The break never comes through the front door

Ask a room of engineers how RSA breaks, and almost everyone reaches for the same answer: someone factors the modulus. They are describing the slowest, least-likely path there is. The attacks that actually work never touch N at all, and the one attack that could break a flawlessly generated key has not been built yet, because it needs a computer that does not exist.

That is the whole argument of this article, and it runs against the common intuition hard enough to be worth stating plainly. RSA's security is usually explained as "factoring is hard, and your key is a big number nobody can factor." Both halves are true, and together they still point you at the wrong threat. Factoring your modulus is the one attack a bigger key genuinely slows down, which is exactly why it is the attack that will almost certainly never be the way your key falls.

Here is the organizing lens for everything that follows: a two-speed map with a third road. The slow lane attacks the hardness assumption directly by factoring N. It works on any key, needs no mistake on your part, and is asymptotically glacial.

The fast lane ignores N entirely and attacks the instantiation, the specific way this key and this message were built. It runs in polynomial time and is genuinely fast, but only when the parameters or the key generation leaked structure they should not have. And the third road, Shor's quantum algorithm, reopens the front door itself by changing the machine you compute on, breaking even a perfect key, if and only if someone builds the hardware.

Key idea: The front door of RSA is bolted, and it opens only at a crawl: factoring is the slow path, not the likely one. The fast cracks come through side windows that a well-generated key never leaves open. And the single attack that opens the front door itself is quantum, on a machine that has not been built.

flowchart TD A["Break RSA-2048"] --> B["Slow lane: factor N directly"] A --> C["Fast lane: attack the instantiation"] A --> D["Third road: change the machine"] B --> B1["GNFS, sub-exponential, glacial"] C --> C1["Coppersmith, Wiener, polynomial"] D --> D1["Shor, polynomial, needs a quantum computer"] B1 --> E{"Beats a correct key?"} C1 --> E D1 --> E E -->|"slow lane, not in practice"| F["Correct key survives classically"] E -->|"fast lane, only with a defect"| F E -->|"third road, yes, on hardware that does not exist"| G["The one real structural threat"]

One boundary before we begin, because it decides what counts as an answer. This is a structural story about the mathematics of the algorithm itself. The attacks that steal real data most often never touch RSA's math at all; they break the implementation or the protocol around it. Here we stay inside the equations, where the only question is whether the numbers themselves give way.

Note: This article analyzes cryptanalysis of RSA's own mathematics. Side channels, fault and power attacks, implementation bugs, weak random-number generators, key-generation library defects such as ROCA, padding oracles such as Bleichenbacher's, and protocol downgrades such as FREAK are all out of scope. They are how RSA breaks in practice, and they are covered by the companion article. One exception that belongs to the math: Shor's quantum algorithm counts as a structural break and is in scope. Grover's algorithm, a generic search speedup, is only mentioned to mark the edge of the map.

So if factoring is the slow path, what makes the fast one fast, and why does it never touch N? To see that, start where RSA started: with a bet nobody could prove they would win.

2. A wager on a problem no one has proven hard

In 1977, three researchers at MIT, Ron Rivest, Adi Shamir, and Leonard Adleman, answered an open call. A year earlier, Whitfield Diffie and Martin Hellman had described what public-key cryptography should do without giving a concrete way to do it: a lock anyone can snap shut but only the keyholder can open [@diffie-hellman-1976]. Rivest, Shamir, and Adleman supplied the lock [@rivest-shamir-adleman-1978].

That August, Martin Gardner's Mathematical Games column in Scientific American handed it to the public as a dare: a 129-digit number to factor, a modest cash prize, and the confident promise that reading the encrypted message would take far longer than any reader would live to see [@gardner-1977; @atkins-rsa129-1995].

The question worth holding onto is whether that confidence was earned or merely borrowed.

RSA itself is almost aggressively simple. Pick two large primes and multiply them into a public modulus $N = pq$. Publish N and a public exponent e. To encrypt a message m, compute $c = m^e \bmod N$; to decrypt, compute $m = c^d \bmod N$, where the private exponent d is chosen so that $ed \equiv 1 \pmod{\varphi(N)}$ and $\varphi(N) = (p-1)(q-1)$ is Euler's totient [@rivest-shamir-adleman-1978]. Encryption is a modular exponentiation anyone can perform. Decryption is the same operation with a secret exponent that only the keyholder knows.

Everything rests on one hinge. To recover d, the obvious route is to compute $\varphi(N)$, and to compute $\varphi(N)$ you need p and q, which means factoring N. So RSA is believed to be as hard to break as factoring is hard to do. Read that sentence twice, because the load-bearing word is "believed." Rivest, Shamir, and Adleman did not prove that breaking RSA requires factoring, and no one has proven it since. RSA is a wager that a specific problem is hard, staked on decades of failed attempts to make it easy rather than on a theorem.

A function that is easy to compute in the forward direction but hard to invert, unless you hold a secret piece of information (the trapdoor) that makes inversion easy. RSA's forward direction is modular exponentiation, its trapdoor is the factorization of `N`, and its entire security is the conjecture that without the trapdoor, inversion stays hard.

What makes the RSA story unusually honest is that the field turned this belief into a dated, public experiment. In March 1991, RSA Security launched the RSA Factoring Challenge: a published list of moduli, cash bounties, and an open invitation to factor them [@wiki-rsa-factoring-challenge]. Every time a challenge number fell, the community learned precisely how far the sharpest available methods and machines could reach in a given year. The result is something most security assumptions never get: a fifty-year measured record of exactly how hard factoring has proven to be in practice.

timeline title Fifty years of RSA cryptanalysis 1977 : RSA published : Gardner challenge 1985 : Hastad low-exponent broadcast 1990 : Wiener small-d attack : Number Field Sieve 1994 : Shor quantum factoring : RSA-129 factored 1996 : Coppersmith small-root method 1999 : Boneh-Durfee small-d lattice : Boneh survey 2009 : RSA-768 factored 2020 : RSA-250 factored 2025 : Shor estimate under one million qubits

That timeline is also a map of everything this article covers, and it splits cleanly into the two speeds. Some entries, the Number Field Sieve, RSA-129, RSA-768, RSA-250, are the slow lane: brute assaults on the factoring problem itself, dated by when a bigger number finally fell. Others, Hastad, Wiener, Coppersmith, Boneh-Durfee, are the fast lane: polynomial-time attacks that never factor anything, dated by when someone noticed a new way for a careless instantiation to give itself away. Only one entry, Shor, belongs to neither lane, because it changes the machine.

It is worth naming the excluded failures precisely, because they, not the mathematics, are what actually break RSA deployments in the wild: timing and power side channels that leak the private key, fault attacks that corrupt a computation to expose a factor, weak random-number generators that hand out repeated or flawed primes (the ROCA vulnerability), padding oracles such as Bleichenbacher's that turn a chatty server into a decryption service, and protocol downgrades such as FREAK. Every one is a genuine break, and not one of them factors `N` or attacks RSA's mathematics. They are implementation and protocol failures, and they belong to the empirical sibling, *How RSA Breaks in Real Life*. This article is about the equations.

If the whole system rests on one unproven assumption, the obvious move is to attack that assumption head-on and just factor N. Fifty years of the sharpest minds in computational number theory tried exactly that. Here is how far they got.

3. The slow lane: attacking factoring head-on

The direct attack writes itself: break RSA by factoring the modulus. The punchline is not triumph but frustration. Even the reigning champion algorithm is, at cryptographic sizes, glacial.

The ladder is a genealogy, and each rung earned its place by beating the one below it. At the bottom sits trial division and Fermat's method, fully exponential in the size of N and useless past a few dozen digits. Then come the special-purpose methods: John Pollard's p-1 method (1974), fast whenever p-1 happens to have only small prime factors [@pollard-pm1-1974], and his rho method (1975), which finds a small factor p in about $O(p^{1/2})$ steps using almost no memory [@pollard-rho-1975]. These are lethal against unlucky primes but hopeless against a balanced modulus whose factors are both enormous.

The real lineage of general-purpose factoring begins with a single idea: instead of searching for a factor directly, manufacture a congruence of squares $x^2 \equiv y^2 \pmod{N}$ with $x \not\equiv \pm y$, and read a factor off $\gcd(x-y, N)$. Morrison and Brillhart's continued-fraction method, CFRAC (1975), was the first to collect many small relations and combine them into that square with linear algebra, and the first general method to run in sub-exponential time [@morrison-brillhart-1975]. Carl Pomerance's Quadratic Sieve (1985) replaced slow per-number testing with a fast sieve and dominated the 1980s and early 1990s at heuristic cost $L_N[1/2, 1]$ [@pomerance-qs-1985]. Then, in 1990, the Number Field Sieve dropped the exponent from one half to one third, the single largest asymptotic improvement in the history of factoring, and the last one to date [@lenstra-nfs-1990].

Factoring costs are written with $L_N[\alpha, c] = \exp\big((c + o(1))(\ln N)^{\alpha}(\ln\ln N)^{1-\alpha}\big)$. The exponent $\alpha$ interpolates between two worlds: $\alpha = 1$ is fully exponential in the bit-length, $\alpha = 0$ is polynomial, and $\alpha = 1/3$ sits in between, "sub-exponential." Sub-exponential is genuinely faster than exponential, which is why big numbers can be factored at all, and genuinely slower than polynomial, which is why they cannot be factored at cryptographic sizes. The fastest known classical algorithm for factoring a general large integer, with heuristic running time $L_N[1/3, (64/9)^{1/3}] \approx L_N[1/3, 1.923]$ [@lenstra-nfs-1990]. It builds a congruence of squares by collecting relations that are simultaneously smooth on a rational side and an algebraic side, then solves a very large linear system. Every RSA factoring record since the late 1990s has used a GNFS implementation [@zimmermann-records]. An integer is B-smooth if every one of its prime factors is at most `B`. Smoothness is the lever every modern factoring algorithm pulls: the sieve hunts for values that are B-smooth, because only those factor completely over a fixed, small "factor base" of primes and can be fed into the linear algebra. The art of the Number Field Sieve is arranging for enough smooth relations to appear.

Definitions establish that GNFS is sub-exponential. The record trajectory shows what sub-exponential feels like against real keys, and it is the heart of this section's argument. Do not take "glacial" on faith. Watch the dates.

Challenge	Modulus size	Year factored	Method and reported effort
RSA-129	426 bits (129 digits)	1994	Quadratic sieve, worldwide volunteer effort [@atkins-rsa129-1995]
RSA-155	512 bits	1999	Number Field Sieve [@cavallar-rsa155-2000]
RSA-768	768 bits	2009	GNFS, nearly 2000 core-years [@kleinjung-rsa768-2010]
RSA-250	829 bits	2020	GNFS, roughly 2700 core-years [@boudot-rsa250-2020]

Read the first and last rows together. From RSA-129 in 1994 to RSA-250 in 2020 is roughly 400 bits of progress in 26 years [@zimmermann-records; @wiki-rsa-numbers]. A deployed RSA key is 2048 bits. The record is still more than 1,200 bits short of it, and RSA-250 alone burned about 2,700 core-years of computation on the open-source CADO-NFS software [@boudot-rsa250-2020; @cado-nfs].A core-year is one processor core running flat out for a year, so 2,700 core-years is a large cluster running for months. The same team's peer-reviewed 240-digit experiment documents the sieving-and-linear-algebra methodology behind these records [@boudot-dlp240-2020]. The gap is not a matter of waiting a few more years for a faster cluster, because the cost curve is sub-exponential, so each additional bit is more expensive than the last. You can compute just how much more expensive.

{` from math import log, exp

Heuristic GNFS cost L_N[1/3, (64/9)^(1/3)] as a function of bit-length.

def L(bits, alpha=1/3, c=(64/9)(1/3)): lnN = bits * log(2) # ln N for a 'bits'-bit modulus return exp(c * lnNalpha * (log(lnN))**(1 - alpha))

cost_829 = L(829) # RSA-250, the current classical record cost_2048 = L(2048) # a deployed key

print("GNFS constant (64/9)^(1/3) =", round((64/9)**(1/3), 4)) print("Relative L-cost at 829 bits: %.3e" % cost_829) print("Relative L-cost at 2048 bits: %.3e" % cost_2048) print("RSA-2048 is harder than RSA-250 by a factor of about: %.3e" % (cost_2048 / cost_829)) print() print("RSA-250 already cost ~2700 core-years; scaling by that factor gives") print("about %.1e core-years for RSA-2048 -- far beyond any foreseeable cluster." % (2700 * cost_2048 / cost_829)) `}

The numbers that fall out are not "a thousand times harder" or "a million times harder." They are astronomical: the same sober L[1/3] curve that predicted RSA-250 puts a 2048-bit modulus permanently outside the reach of any classical machine anyone can foresee. This is the slow lane in one image. It works on every key, it needs no mistake by the defender, and it will almost certainly never reach a modern modulus.

flowchart TD A["Trial division and Fermat: fully exponential"] --> B["Pollard p-1 (1974) and rho (1975): special-purpose"] B --> C["CFRAC (1975): first sub-exponential"] C --> D["Quadratic Sieve (1985): exponent one half"] D --> E["Number Field Sieve (1990): exponent one third"] E --> F["No asymptotic gain since 1990"] A --> G["ECM (1987): niche, cost set by the smallest factor"]

The ladder has texture worth pausing on. When RSA-129 fell in 1994, the recovered plaintext was a puzzle phrase the designers had hidden inside the challenge.The RSA-129 plaintext was "THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE" [@atkins-rsa129-1995]. A widely repeated web summary claims it read "SEND MORE MONEY"; that is simply wrong. Pollard's p-1 method left a lasting mark on how primes were chosen: for years, key-generation guidance called for "strong primes," primes p where p-1 has a large prime factor, precisely so the p-1 attack could not bite.The strong-prime design rule is a direct descendant of Pollard's 1974 p-1 method [@pollard-pm1-1974]. Modern guidance mostly dropped the requirement once GNFS made the specific structure of p-1 irrelevant to the dominant attack, but the historical lineage is exact. And one rung of the ladder never went away, it just found a different job.Hendrik Lenstra's Elliptic Curve Method (1987) has a running time that depends on the size of the smallest factor, not the whole modulus [@lenstra-ecm-1987]. That makes it superb at peeling small primes off a number and useless against a balanced RSA modulus whose two factors are each half the bits. It is a living tool, in the wrong weight class for this fight.

The slow lane also has a recurring failure mode that is not technical but sociological, and it is worth immunizing against before the fast lane tempts you.

Every few years, a preprint claims to have shattered RSA, and every few years it evaporates on contact with implementation. The cleanest recent specimen is Claus Schnorr's 2021 IACR ePrint, whose abstract ended with the sentence "This destroys the RSA cryptosystem" [@schnorr-eprint-2021; @schneier-2021]. It did not. The claimed speedup relied on finding enough short lattice vectors to generate factoring relations, and when Leo Ducas implemented the method as *SchnorrGate*, it produced zero usable relations at cryptographic size [@ducas-schnorrgate]. Bruce Schneier's response carried the whole verdict in its title, and later revisions of the preprint quietly deleted the offending sentence [@schneier-2021]. The lesson is durable: an extraordinary cryptanalytic claim is worth exactly as much as its implementation, and until someone factors a real challenge number, the record trajectory stands. "No, RSA Is Not Broken." -- Bruce Schneier, on the 2021 claim that short-vector lattice algorithms had destroyed the RSA cryptosystem [@schneier-2021].

So the front door is bolted, and it opens only at a crawl. Fifty years of the best available mathematics moved the record about 400 bits, and the cost curve guarantees the next 1,200 bits are not coming on any classical machine. A defender who only worries about factoring has been watching the wrong door. Because a locksmith's insight changes the whole game: what if you never had to open the front door at all? What if you never factored N?

4. The fast lane opens: Hastad and Wiener

The insight that reroutes the entire story is deceptively small: you do not have to factor N at all. Factoring is the hardest way to break RSA, not the easiest. If the way this particular key or this particular message was built leaks structure, the key can fall in polynomial time, and N stays untouched the whole time. Two attacks from the late 1980s and early 1990s proved the fast lane exists, and each one falls out of a single leaked parameter.

The first is Johan Hastad's low-exponent broadcast attack (introduced at CRYPTO '85 and generalized in his 1988 SIAM paper). Suppose a sender uses a tiny public exponent, say $e = 3$, and sends the same message m to several recipients, each with their own modulus $N_i$, without randomized padding. Each recipient sees $c_i = m^3 \bmod N_i$. An eavesdropper who collects three of these ciphertexts applies the Chinese Remainder Theorem to combine them into a single value congruent to $m^3$ modulo $N_1 N_2 N_3$ [@hastad-1988].

Since m is smaller than every $N_i$, the true $m^3$ is smaller than the product $N_1 N_2 N_3$, so the combined congruence is an equation over the integers: the combined value simply equals $m^3$, with no modular wraparound. Take an ordinary integer cube root and you have the message. No factoring, no lattice, just arithmetic [@hastad-1988].

The precondition is loud, and it is the reason a good key is immune. Hastad needs a tiny exponent and the same message broadcast unpadded to several recipients. Use $e = 65537$ instead of 3, or pad each message with fresh randomness so no two ciphertexts encrypt the same integer, and the broadcast structure that made $m^3$ recoverable is gone. The attack does not get slower; it stops applying.

The second attack targets the other exponent. Michael Wiener's small private-exponent attack (1990) shows that shrinking d to speed up decryption is fatal. When the private exponent is small, specifically $d < \tfrac{1}{3}N^{1/4}$, the public ratio $e/N$ becomes an extraordinarily good rational approximation to the secret ratio $k/d$ that lurks in the key equation [@wiener-1990]. And there is a classical theorem of number theory that says the only fractions that approximate a real number that well are its continued-fraction convergents. So the attacker expands $e/N$ as a continued fraction, and the secret denominator d appears as one of the convergents' denominators, recovered from nothing but the public key (e, N) [@wiener-1990].

Any real number can be written as a nested fraction $a_0 + 1/(a_1 + 1/(a_2 + \cdots))$. Truncating that expansion after a few terms gives a sequence of rational approximations $h_i/k_i$ called convergents, and they are provably the *best* rational approximations for their denominator size. Wiener's attack turns key recovery into a search through the convergents of $e/N$: one of their denominators is the secret exponent `d`.

Because the whole attack is a short walk through a list of fractions, it is genuinely fast, and it is easy to watch happen. The code below builds an RSA key with a deliberately small d, publishes only (e, N), and then recovers d from the public key alone.

{` from math import isqrt, gcd

Build a deliberately weak RSA key with a very small private exponent d.

p = 999999937 q = 999999893 N = p * q phi = (p - 1) * (q - 1)

Wiener succeeds whenever d < (1/3) * N**(1/4). Take the largest such d.

bound = isqrt(isqrt(N)) // 3 d = next(x for x in range(bound, 2, -1) if gcd(x, phi) == 1) e = pow(d, -1, phi) # matching public exponent print("Public key: N =", N) print(" e =", e) print("Hidden small d =", d, " (Wiener bound about", bound, ")")

The attacker sees only (e, N). Expand e/N as a continued fraction; each convergent's denominator is a candidate for d.

def convergents(num, den): a = [] x, y = num, den while y: a.append(x // y) x, y = y, x % y h0, h1 = 0, 1 k0, k1 = 1, 0 for ai in a: h0, h1 = h1, ai * h1 + h0 k0, k1 = k1, ai * k1 + k0 yield h1, k1 # (candidate k, candidate d)

for k_cand, d_cand in convergents(e, N): if k_cand == 0: continue if (e * d_cand - 1) % k_cand == 0: # phi(N) must be an integer phi_guess = (e * d_cand - 1) // k_cand s = N - phi_guess + 1 # candidate p + q disc = s * s - 4 * N # roots of x^2 - s*x + N if disc >= 0 and isqrt(disc) ** 2 == disc: print("Recovered d =", d_cand, " correct:", d_cand == d) break `}

Once again the precondition is the whole story. Wiener needs a small d. A correctly generated key uses a full-size random d on the order of N itself, and there is no low-denominator convergent of $e/N$ to find, so the attack has nothing to grab.

Notice what these two attacks share, and where each falls short. Both exploit a leaked parameter, not the modulus. Both run in polynomial time. And both were, at first, treated as clever isolated tricks: a broadcast maneuver here, a continued-fraction maneuver there. Hastad even needs an awkward number of near-identical ciphertexts, and Wiener's $N^{1/4}$ bound is visibly loose, as if it could be pushed further with a better tool. For eight years the fast lane stayed a grab-bag of one-offs. Then someone found the single principle hiding underneath all of them.

5. Coppersmith's master key

In 1996, Don Coppersmith found the idea that turned the grab-bag into a theory. Stated plainly, it is one of the most useful facts in applied cryptography, and once you see it you cannot unsee it in any of the fast-lane attacks.

Here is the theorem. Take a polynomial $f(x)$ of degree d, and suppose it has a root $x_0$ modulo N that is small, meaning $|x_0| < N^{1/d}$. Then you can find $x_0$ in time polynomial in $\log N$ and d, using lattice reduction [@coppersmith-1997]. That is the whole master key. Not "factor N," not "guess the message," but: whenever an unknown quantity is small and sits inside a known algebraic structure, you can solve for it directly.

A lattice is the set of all integer combinations of some basis vectors, an infinite grid of points in space. The same lattice has many bases, some "long and skew," some "short and nearly perpendicular." The Lenstra-Lenstra-Lovasz (LLL) algorithm, from 1982, efficiently turns a bad basis into a reduced one whose vectors are short and close to orthogonal. Throughout this article LLL is a black box with one job: hand it a lattice, and it returns a surprisingly short vector in polynomial time [@may-survey-2009].

The bridge from "small modular root" to "short lattice vector" is the contribution of Nick Howgrave-Graham (1997), whose reformulation is the version taught and coded today [@howgrave-graham-1997]. The trick is elegant. You do not attack $f$ directly. Instead you build a lattice out of shifted and scaled multiples of $f$, all of which vanish at the same secret root $x_0$ modulo powers of N.

LLL finds a short combination of them, and shortness has a precise payoff: a polynomial with small enough coefficients that, at the small value $x_0$, it cannot merely be congruent to zero modulo N; it must be exactly zero as an integer [@howgrave-graham-1997]. The modular problem has become an ordinary equation over the integers, and ordinary equations over the integers are easy to solve for their roots. That is the same "collapse to the integers" trick that let Hastad's cube root work, generalized into a machine.

flowchart LR A["Known structure plus a small unknown"] --> B["Write it as f(x) with a small root mod N"] B --> C["Build a lattice from shifted multiples of f"] C --> D["LLL returns a short vector"] D --> E["A new polynomial, same root, small enough to hold over the integers"] E --> F["Ordinary root-finding recovers x0"] A polynomial-time algorithm that, given a monic polynomial $f(x)$ of degree `d` and a modulus `N`, finds every integer root $x_0$ with $|x_0| < N^{1/d}$ satisfying $f(x_0) \equiv 0 \pmod{N}$ [@coppersmith-1997]. The size bound $N^{1/d}$ is the load-bearing threshold: it is generous for tiny degree (a cube-root-sized unknown for $d = 3$) and shrinks fast as the degree grows, which is exactly why a large public exponent starves the method of anything to find.

Key idea: Every fast-lane attack in this article is the same sentence in a different costume: known structure plus a small unknown lets you solve for the unknown. Hastad's broadcast, stereotyped messages, related messages, partial key exposure, and the strongest small-d attack are all instances of Coppersmith's small-root method, powered by LLL whenever the unknown is smaller than $N^{1/d}$. The zoo is one animal.

Watch Hastad collapse to a corollary. His broadcast attack is just the small-root method for the polynomial $f(x) = x^e - c$ with the tiny exponent making the root findable; the CRT step is a convenience, not the essence [@coppersmith-1997]. The purest instance of all is textbook RSA with $e = 3$ and no padding, where the message itself is the small root. If $m^3 < N$, the ciphertext never wrapped around the modulus, so the "encryption" is just a cube, and a cube root is the entire attack.

{` def icbrt(n): # Exact integer cube root via Newton's method (works for huge integers). if n < 2: return n x = 1 << ((n.bit_length() + 2) // 3) while True: y = (2 * x + n // (x * x)) // 3 if y >= x: return x x = y

N = (1 << 2047) + 12345 # a 2048-bit stand-in modulus e = 3 m = 42424242424242 # a short message: m^3 stays far below N c = pow(m, e, N) # textbook RSA "encryption": c = m^3 mod N

print("Is m^3 < N ?", m**3 < N) print("recovered m =", icbrt(c), " correct:", icbrt(c) == m)

Real padding widens the message so that m2^3 exceeds N and wraps around.

m2 = (1 << 700) | m c2 = pow(m2, e, N) print("Is (padded m2)^3 < N ?", m2**3 < N) print("plain cube root now fails:", icbrt(c2) != m2) `}

The second half of that snippet is the entire defense in miniature. Once the message is widened by real padding so that its cube exceeds N, the ciphertext wraps around the modulus, the "small root" is no longer small, and the cube root returns garbage. The attack did not get harder to run; its precondition vanished. Hold onto that distinction, because it is the shape of every result in the next section: one theorem, many doors. So which locks does the master key actually open on a real RSA deployment, and, just as important, which ones stay firmly shut?

6. The Coppersmith family today

The mature fast lane is the master key reused, deliberately, by name. Each member of the family has the same shape, known structure hiding one small unknown, and each is neutralized by exactly one standard parameter choice. Walk them in order and the pattern becomes impossible to miss.

Stereotyped and known-bits messages. Suppose an attacker knows most of a message, a fixed template B, and only a short secret block x is unknown, so the plaintext is $B + x$. With public exponent e, the ciphertext gives the polynomial $f(x) = (B + x)^e - c$, whose small root is the secret block, recoverable whenever $|x| < N^{1/e}$ [@coppersmith-1997]. A low exponent and a mostly-known message is all it takes. Raise e to 65537 and the recoverable window $N^{1/e}$ shrinks to almost nothing; randomize the message with padding and the "small unknown" becomes the entire plaintext, far too big to be a small root.

Factoring with high bits of p known. Coppersmith's method also attacks the modulus, but only with a head start. If an attacker already knows roughly the top half of the bits of p, the remaining low bits form a small root of a polynomial modulo N, and the method recovers them, factoring N in polynomial time [@coppersmith-1997; @may-survey-2009]. The precondition is severe: you must already know half of a secret prime. Generate both primes from a good random source and no such head start exists.

Related messages and short pads. If two messages satisfy a known linear relation and are sent under the same small exponent, the attacker forms two polynomials sharing the plaintext as a root and takes their polynomial greatest common divisor, which reveals it. This is the Franklin-Reiter base case [@cfpr-1996]. Coppersmith extended it to the case where the relation is an unknown but short pad, solved with the small-root method, the short-pad attack [@cfpr-1996]. Both need a small e and a short or structured relationship between messages. OAEP's long, fully random pad destroys any such relation, which is precisely what it was designed to do.

Partial key exposure. Perhaps the most unsettling member: a fraction of the private key's bits can reconstruct the rest. Boneh, Durfee, and Frankel showed in 1998 that for a low public exponent, roughly a quarter of the least-significant bits of d suffice to recover the whole exponent [@bdf98-1998]. Ernst, Jochemsz, May, and de Weger removed the low-exponent restriction in 2005, extending partial key exposure to full-size exponents with multivariate Coppersmith techniques [@ernst-pke-2005]. The precondition is a leak: some bits of d or p must escape. With no leakage, there is nothing to extend, and how bits leak, timing, power, a fault, is the implementation sibling's subject, not RSA's mathematics.

Boneh-Durfee. Finally, the master key circles back to finish what Wiener started. Boneh and Durfee re-aimed Coppersmith's lattice at the key equation itself and pushed the vulnerable small-d bound from Wiener's $N^{1/4}$ up to $d < N^{0.292}$, the strongest small-exponent attack known [@boneh-durfee-1999]. It is the same lattice engine, pointed at a different polynomial. And it dies against the same defense: a full-size random d on the order of N sits far above the $N^{0.292}$ threshold.

These are cryptanalytic tools, not shipped software, but they are entirely practical to run. LLL and its stronger cousin BKZ live in the open-source fplll library and its Python binding fpylll [@fplll; @fpylll], and Coppersmith's small-root method is a single function call, small_roots(), in SageMath [@sagemath-smallroots]. The barrier to using them is never the tooling. It is finding a key with a precondition to attack.

A stereotyped-message attack in SageMath looks close to this: work in `Zmod(N)`, define the polynomial `f = (B + x)^e - c` whose small root is the secret block, and call `f.small_roots(X=bound, beta=1)`. The library builds the lattice, runs LLL, and returns the root, with no hand-rolled lattice at all [@sagemath-smallroots]. Swap in a different `f` and the same call becomes factoring-with-known-bits or a related-message attack: one engine, pointed at a different polynomial. flowchart TD E["Coppersmith small-root engine"] --> A["Stereotyped or known-bits message: short secret block"] E --> B["Factoring with high bits of p known: half of p leaks"] E --> C["Franklin-Reiter and short-pad: same small e, short or known pad"] E --> D["Partial key exposure: a fraction of d's bits leak"] E --> F["Boneh-Durfee: deliberately small private exponent d"]

Lay the whole family in a table and the argument writes itself. Every row is a real, polynomial-time attack. Every row also has a right-hand column that a correctly generated RSA-2048 key fills in by default.

Fast-lane attack	Exact precondition it needs	Closed by
Hastad broadcast	tiny `e`, same message sent unpadded to many recipients	$e = 65537$ or randomized padding [@hastad-1988]
Stereotyped / known-bits	most of the message is a known template, short secret block	randomized OAEP padding [@rfc8017]
Factoring, high bits of `p`	roughly half the top bits of `p` already known	independent, well-sourced random primes [@may-survey-2009]
Franklin-Reiter / short-pad	same small `e`, a known or short relation between messages	$e = 65537$ plus OAEP's long random pad [@cfpr-1996]
Partial key exposure	a constant fraction of `d`'s or `p`'s bits leaked	no key-bit leakage; full-size random `d` [@ernst-pke-2005]
Wiener small-`d`	$d < \tfrac{1}{3}N^{1/4}$	full-size random `d` [@wiener-1990]
Boneh-Durfee small-`d`	$d < N^{0.292}$	full-size random `d` near `N` [@boneh-durfee-1999]

The randomized padding scheme standardized for RSA encryption in PKCS #1 v2.2 (RFC 8017) [@rfc8017]. Before exponentiation, OAEP mixes the message with fresh random bytes through a two-round structure, so that the integer actually raised to the power `e` is large, high-entropy, and different every time, even for identical plaintexts. That single step removes the "known structure" and the "small unknown" that every Coppersmith-family attack needs, which is why OAEP is the defense that closes most of the table at once.

There is something almost paradoxical here, and it is the sharpest structural point in all of RSA cryptanalysis. None of these attacks is wrong. None is slow. None has been refuted or patched away. They remain perfectly correct, polynomial-time algorithms. They are simply inapplicable to a key that never grants their precondition. The fast lane does not fail against a good key by being outrun, the way the slow lane is outrun by a big modulus. It fails by precondition-absence: there is nothing for the lattice to grab.

Note: This is the mental model to keep. A larger key defeats the slow lane by making factoring more expensive. Nothing defeats the fast lane, because the fast lane was never a contest of speed. It is a contest of whether a defect exists. Remove the defect, small exponent, small d, missing padding, leaked bits, correlated primes, and each attack does not slow down; it simply has no input. A correct RSA-2048 key wins the fast lane by forfeit.

An attack that is perfectly correct yet perfectly inapplicable is the sharpest point in RSA cryptanalysis. Against a well-generated key, the fast lane has no applicable attack.

So put the two lanes together against a specific, correct target: RSA-2048 with $e = 65537$, a full-size random d, two independent well-sourced primes, and OAEP padding. The slow lane is available but glacial, more than 1,200 bits and an astronomical cost curve away from success. The fast lane is polynomial but inert, because every precondition in the table above is absent [@boneh-survey-1999; @rfc8017]. Against that key, the classical state of the art is a phrase worth memorizing: no applicable attack.

The fast lane is fast but conditional; the slow lane is universal but glacial. Put all three roads on one table, and ask the only question that matters: which one actually threatens a well-generated key?

7. Three roads, compared

Everything so far has been building one picture. Lay the slow lane, the fast lane, and the third road side by side, and the article's thesis stops being a claim and becomes something you can read straight off a table.

Dimension	Slow lane: GNFS	Fast lane: Coppersmith family	Third road: Shor
What it attacks	the hardness assumption (factor `N`)	the instantiation (a specific defect)	the hardness assumption (factor `N`)
Input required	`N` only	`N` plus a parameter or key-gen defect	`N` only
Precondition	none	small `e`, small `d`, no padding, leaked bits, or correlated primes	a working quantum computer of the right size
Worst-case time	$L_N[1/3, 1.923]$, sub-exponential	polynomial	polynomial in $\log N$
Breaks a correct RSA-2048 key?	not in practice	no	yes
Computational model	classical	classical	quantum

Read the table as three sentences. The slow lane breaks any key, needs no mistake, and is asymptotically stalled: its $L_N[1/3, 1.923]$ cost has not improved since 1990, and against 2048 bits it is glacial [@lenstra-nfs-1990]. The fast lane is genuinely polynomial and genuinely fast, but it goes completely dark against a correct key, because every one of its attacks needs a defect the key does not have [@coppersmith-1997]. Two roads, and neither threatens a well-generated RSA-2048 key in practice: one is too slow, the other has no opening.

That is the corner the argument has painted us into, and it forces the third road into view. If the slow lane is stalled and the fast lane is inert, then the only way to break a correct key is to stop playing the classical game entirely, to change the machine. That is Shor's algorithm, first announced at FOCS in 1994 and published in full in 1997 [@shor-focs-1994; @shor-siam-1997].

It attacks the same hardness assumption as the slow lane, factoring N with no defect required, but it runs in time polynomial in the number of digits of N, an exponential speedup over GNFS. It is the one entry in the table that breaks a flawless key, and it carries the one precondition no careful key generation can supply or deny: a large, fault-tolerant quantum computer, which does not exist as of 2026.

The mechanism is the subject of the next section; for now, the table has delivered its verdict. The only structural attack left standing against a good key is a change of computational model.

That verdict points at one uncomfortable question the table cannot answer. The slow lane is stalled, and we have been treating that as if it were a law of nature. But is factoring actually hard, or have we simply not found the trick yet? The honest answer is more unsettling than either the optimists or the doomsayers usually admit.

8. Is factoring even hard, and how hard?

Beneath fifty years of engineering confidence lies an uncomfortable truth: nobody has ever proven that factoring is hard. RSA's security is a conjecture that has survived a long time, which is a very different thing from a theorem.

Start with the most common misconception, because correcting it reframes everything. People often say factoring is NP-hard, as if RSA inherited the full difficulty of the hardest problems in NP. It did not. The decision version of factoring sits in $\text{NP} \cap \text{co-NP}$: a factor is a short certificate that the answer is "yes," and because primality can be checked efficiently, there is also a short certificate for "no" [@hac-1996]. A problem in that intersection cannot be NP-complete unless NP equals co-NP, which almost no one believes.

So factoring is very likely not among the hardest problems in NP, and the casual "RSA is NP-hard" intuition is simply false [@hac-1996].

It may be worse than that, in a precise and interesting way: breaking RSA might be strictly easier than factoring. Boneh and Venkatesan gave evidence that no "algebraic reduction" can turn an efficient low-exponent RSA-breaker into a general factoring algorithm, which would mean recovering a message does not require the full strength of factoring [@boneh-venkatesan-1998].

Aggarwal and Maurer later proved that breaking RSA is equivalent to factoring, but only in the restricted "generic ring model," where the attacker is forbidden from exploiting the specific bit-representation of numbers [@aggarwal-maurer-2009]. Put together, the honest statement is that we do not know whether the RSA problem and factoring are equally hard. We only know the assumption rests on belief, layered on belief.

What we can state precisely are the upper bounds, and the gap between them is the whole story. Classically, the best we can do is GNFS, sub-exponential $L_N[1/3, 1.923]$ [@lenstra-nfs-1990]. On a quantum computer, Shor's algorithm factors in time polynomial in the number of digits of N, an exponential improvement [@shor-siam-1997].

There is no known classical lower bound anywhere near the upper bound, so the space between "maybe there is a fast classical algorithm we have not found" and "there is definitely a fast quantum algorithm" is enormous and almost entirely unmapped.

Shor's mechanism deserves to be seen, because it is not a faster search; it is a genuinely different idea. Factoring N is reduced to finding the period of the function $a^x \bmod N$ for a random base a, that is, the smallest r with $a^r \equiv 1 \pmod{N}$. Classically, finding that period is as hard as factoring.

Quantumly, a superposition over all x, a modular exponentiation, and a quantum Fourier transform extract r efficiently. Once you have an even r with $a^{r/2} \not\equiv -1 \pmod N$, an ordinary classical greatest-common-divisor, $\gcd(a^{r/2} \pm 1, N)$, hands you a factor [@shor-siam-1997]. It is a classical reduction wrapped around a single quantum subroutine.

flowchart TD A["Pick a random a coprime to N"] --> B["Quantum: find the period r of a^x mod N with the QFT"] B --> C{"r even and a^(r/2) not congruent to -1?"} C -->|"no, retry"| A C -->|"yes"| D["Classical: compute gcd(a^(r/2) plus or minus 1, N)"] D --> E["A nontrivial factor of N"] A quantum computer large and reliable enough to run Shor's algorithm against real cryptographic parameters, for example to factor a 2048-bit RSA modulus. Because Shor needs many high-fidelity logical qubits maintained through a long computation, a CRQC requires fault-tolerant error correction over a vast number of physical qubits. No such machine exists as of 2026, and building one is an unsolved engineering problem, not merely a matter of scaling up today's devices.

How far is that machine? The honest answer comes from the people doing the most careful accounting, and their numbers are moving in a way worth understanding. In 2019, Craig Gidney and Martin Ekera estimated that factoring a 2048-bit RSA key with Shor would take roughly 20 million noisy physical qubits running for about 8 hours [@gidney-ekera-2021]. In May 2025, Gidney revised the estimate to fewer than one million noisy qubits in under a week, under the same hardware assumptions as the 2019 analysis [@gidney-2025].

Read those two figures together carefully. The twentyfold drop did not come from better hardware; it came from better algorithms for organizing the computation. The estimate is improving far faster than the machines, and today's largest quantum devices remain orders of magnitude below even the reduced requirement [@gidney-2025]. No cryptographically relevant quantum computer exists as of 2026.

Note: It is easy to slide from "the resource estimates are dropping fast" to "a quantum break is imminent." That slide is not supported here. As of 2026 there is no machine capable of running Shor against RSA-2048, and predicting when, or whether, one will be built is genuinely uncertain. What the falling estimates establish is that the paper cost of the attack is shrinking, not that the hardware has arrived. Treat any specific date you see quoted, from anyone, as a forecast, not a fact.

Two facts about scale make the quantum threat qualitatively different from the classical one, and both cut against the defender's usual instinct. First, a bigger key does not help. Shor's cost grows only polynomially in the number of digits of N, so doubling the modulus from 2048 to 4096 bits multiplies the quantum work by a small constant, not by the astronomical factor that same doubling imposes on GNFS. The move that defeats the slow lane is nearly useless against the third road.

Second, and for the same reason, there is no "safe classical margin" to buy. Against Shor, the defense is not a larger RSA key; it is a different kind of cryptography entirely.

Grover's algorithm is the other quantum result people invoke, and it is a boundary marker, not a structural break [@grover-1996]. It gives a generic square-root speedup for brute-force search, turning a $2^{n}$ key search into about $2^{n/2}$. That halves the effective strength of a symmetric key, which is why AES-256 is favored for post-quantum margin [@nist-sp800-57], but it does nothing structural to RSA: it does not factor `N`, and a square-root speedup on an already-astronomical factoring search changes nothing.

Sit with what this section actually established, because it is the third and deepest shift in the whole article. We cannot prove factoring is hard; its decision problem is not even NP-complete, so RSA rests on a belief rather than a theorem. The fast lane is inert against a correct key, and the slow lane has been asymptotically frozen since 1990. Therefore the only structural break left standing against a well-generated key is a change of computational model, Shor's, and against that change a bigger key does essentially nothing.

The confidence that "a large enough RSA key is safe forever" quietly dissolves. What replaces it is not panic but humility: the security you rely on is an assumption with a possible expiry date you cannot see.

So we cannot prove it is hard, and we cannot yet build the machine that makes it easy. That leaves a precise list of things the field genuinely does not know, and one of them carries a deadline that is invisible precisely because no one can read it.

9. What is genuinely unresolved

Strip away the settled results and four honest unknowns remain. This is where the frontier actually sits, and naming the unknowns precisely is more useful than any confident prediction.

Is factoring in P? No polynomial-time classical factoring algorithm is known, and none has been ruled out. The strongest evidence for "hard" is negative and empirical: the GNFS exponent has not moved off one third since 1990, and RSA-250 still stands as the largest general-purpose factorization [@lenstra-nfs-1990; @zimmermann-records]. But "we have not found a faster algorithm in 35 years" is not a proof that none exists, and no lower bound forbids one. This is the open problem the entire slow lane rests on.

Is the RSA problem strictly easier than factoring? Also open. Boneh and Venkatesan's evidence points toward "yes, at least for algebraic reductions," while Aggarwal and Maurer's equivalence holds only inside the generic ring model [@boneh-venkatesan-1998; @aggarwal-maurer-2009]. Whether recovering an RSA plaintext genuinely requires factoring, in the full model where an attacker can do anything, is unresolved.

How far can the small-d lattice bound be pushed? Boneh-Durfee reaches $d < N^{0.292}$, and Boneh and Durfee themselves conjecture the true insecurity threshold is $d < N^{0.5}$ [@boneh-durfee-1999]. The gap between $0.292$ and $0.5$ has resisted every attempt to close it, and subsequent lattice reformulations reach the same $0.292$ more cleanly without surpassing it [@may-survey-2009]. Nobody knows where the real boundary lies.

The exponent $0.292\ldots$ is not a round number; it is exactly $1 - 1/\sqrt{2} \approx 0.2929$, a quadratic irrational (the root of $2\delta^2 - 4\delta + 1 = 0$) that falls out of the lattice determinant condition [@boneh-durfee-1999]. Two honesty caveats travel with it: the conjectured true bound $N^{0.5}$ is only a conjecture, and even the proven $N^{0.292}$ result relies on the standard, unproven heuristic that the short lattice vectors LLL returns are algebraically independent. The fast lane's strongest result is itself built on an assumption.

When does a cryptographically relevant quantum computer arrive? Genuinely unknowable. And this is the unknown with teeth, because it does not need to be answered to be dangerous.

An attacker records encrypted traffic today and stores it, betting that a cryptographically relevant quantum computer will exist before the data stops being sensitive. When that machine arrives, the archived ciphertext is decrypted retroactively with Shor's algorithm. The threat is live *now*, even though the tool to exploit it does not exist yet, because the interception happens today and only the decryption waits. Harvest-now-decrypt-later is what converts an unpredictable timeline into a present-day decision. If your data must stay confidential for ten or twenty years, medical records, state secrets, long-term financial or identity data, then the relevant question is not "does a quantum computer exist today?" but "might one exist within the confidentiality lifetime of what I am encrypting now?" For long-lived secrets, the honest answer is that you cannot rule it out, and the falling resource estimates make ruling it out harder each year [@gidney-2025]. That is the entire case for beginning migration to [post-quantum key-establishment](/blog/one-event-three-assumptions-five-answers-a-field-guide-to-th/) even though no CRQC exists and no credible timeline can be given. You are not reacting to a machine; you are protecting data whose lifetime outruns your ability to forecast.

Unknowable timelines are not an excuse for paralysis. If you ship RSA today, all four open problems collapse into one concrete, answerable question: what do you actually do?

10. How not to be the vulnerable key

Here is the practical reward for all this theory: every fast-lane attack in this article maps to exactly one parameter choice that closes it. The defense is not vigilance or luck. It is a short, checkable list, and mainstream libraries already implement most of it by default.

Do this	It closes	Anchor
Use at least 2048-bit keys; 3072-bit for long-lived data	the slow lane (GNFS)	[@nist-sp800-57]
Set $e = 65537$, never 3	Hastad, stereotyped, Franklin-Reiter and short-pad	[@hastad-1988]
Use a full-size random `d`, never a small one	Wiener, Boneh-Durfee	[@boneh-durfee-1999]
Encrypt with OAEP, never textbook RSA	known-bits and related-message recovery	[@rfc8017]
Generate two independent, well-sourced random primes	known-bits-of-`p` factoring	[@may-survey-2009]
Begin migrating long-lived secrets to post-quantum schemes	Shor plus harvest-now-decrypt-later	[@gidney-2025]

NIST maps key sizes to security levels calibrated directly against the GNFS cost curve: RSA-2048 gives roughly 112-bit security and RSA-3072 roughly 128-bit, which is why 3072 bits is the right choice for data that must survive well past 2030 [@nist-sp800-57]. That single row is the only place where "use a bigger key" is the correct advice, because it is the only threat, the slow lane, that key size actually defends against.

Why $e = 65537$ specifically? It is $2^{16} + 1$, a Fermat prime. Being greater than the tiny exponents lets it defeat the low-exponent attacks, Hastad's broadcast, stereotyped-message recovery, Franklin-Reiter, while being only 17 bits long, with just two set bits, so encryption stays fast: a square-and-multiply exponentiation needs only 17 steps. It is the sweet spot: recommended by RFC 8017 [@rfc8017] and now the near-ubiquitous default in practice.

The two scaling facts from the last two sections invert the usual intuition. A bigger key buys you nothing against a fast-lane defect: an RSA-4096 key with a small d falls to Wiener exactly as fast as an RSA-2048 key with a small d, because the attack never touched the modulus size. And a bigger key buys you nothing against Shor, whose cost grows only polynomially in the key length.

Key idea: A bigger RSA key does one thing: it makes the slow lane slower. It does nothing against a fast-lane defect, because those attacks ignore the modulus, and nothing against Shor, whose cost barely grows with key size. Security against the fast lane comes only from removing the precondition; security against the third road comes only from changing the primitive. Neither is bought with bits.

Note: Use a 2048-bit key (3072-bit for long-lived data), the default $e = 65537$, a full-size random d, two independent random primes from a vetted generator, and OAEP for encryption via your library's high-level API. That configuration closes the entire fast lane by construction and pushes the slow lane past any classical machine. The remaining work is not choosing better parameters, it is starting to plan a migration path for secrets whose confidentiality must outlast the arrival of a quantum computer.

One honest reminder, because a checklist can create false comfort. This list closes the structural attacks, the subject of this article. It does not, by itself, protect you from the implementation and protocol failures that break RSA far more often in the real world: padding oracles, timing and fault leaks, weak random-number generators, the ROCA key-generation defect, and downgrade attacks such as FREAK. Those are a different discipline, covered by the empirical sibling How RSA Breaks in Real Life. A perfectly parameterized key in a leaky implementation is still a broken key.

Follow the checklist and the entire fast lane goes dark while the slow lane stays glacial, which leaves exactly one way a correctly generated key ever breaks.

11. The verdict

Return to the two-speed map, now carrying everything the article has shown. The front door, factoring the modulus, is bolted, and it opens only at a crawl. In 26 years the classical record moved from RSA-129 to RSA-250, roughly 400 bits, and it is still more than 1,200 bits short of a deployed 2048-bit key, on a cost curve that makes the remaining distance astronomical [@zimmermann-records; @boudot-rsa250-2020]. The engineers who picture a break as "someone factors my key" are watching the one door a bigger key actually guards.

The fast cracks come through side windows, and a well-generated key never leaves them open. Against RSA-2048 with $e = 65537$, a full-size random d, two independent primes, and OAEP, every Coppersmith-family precondition is absent, and the classical state of the art is simply no applicable attack [@boneh-survey-1999; @rfc8017]. The fast lane is not slow against a good key; it is inapplicable, which is a stronger and stranger kind of safety.

The one attack that opens the front door itself is Shor's, structural, polynomial, and almost indifferent to key size. It breaks even a flawless key, and it waits on hardware that does not exist as of 2026, with no credible timeline [@shor-siam-1997]. So the most-likely eventual structural break of a good RSA key is not a classical factoring breakthrough at all. It is quantum, on a machine not yet built, and harvest-now-decrypt-later is what makes that future-tense sentence something to act on in the present [@gidney-2025].

The most-likely eventual break of a good RSA key is quantum, on a machine that has not been built. That is exactly why the forecast is actionable today.

The misconceptions this reframing overturns, "RSA is already broken," "a quantum computer just cracked it," "factoring is NP-hard," "a bigger key stops everything," deserve direct answers, which the questions below provide. This article asked how RSA would break. The answer is a two-speed map with a quantum horizon, and every road on it is now labeled.

12. Frequently asked questions

The claims below are the ones that come up most often, corrected against the evidence in this article.

No. A correctly generated RSA-2048 key with $e = 65537$, a full-size random `d`, independent primes, and OAEP padding has no applicable classical attack: the slow lane (GNFS) is astronomically far from a 2048-bit modulus, and every fast-lane attack needs a defect this key does not have [@boneh-survey-1999; @boudot-rsa250-2020]. RSA is not broken. It is a well-understood assumption with a known and distant classical threat, and a structural quantum threat that has no hardware yet. No. Recurring headlines claim exactly this, and none has broken RSA-2048. No cryptographically relevant quantum computer exists as of 2026 [@gidney-2025]. The quantum result people most often conflate with a break, Grover's search algorithm, is only a quadratic speedup and is not a structural attack on RSA [@grover-1996]. The classical "shortcut" claims follow the same pattern as Schnorr's 2021 preprint, whose method produced zero usable relations at cryptographic size when implemented [@ducas-schnorrgate; @schneier-2021]. No, and this is the most common technical misconception. The decision version of factoring lies in the intersection of NP and co-NP, so it cannot be NP-complete unless NP equals co-NP, which is widely disbelieved [@hac-1996]. RSA does not inherit the difficulty of the hardest problems in NP. Its security rests on the specific, unproven belief that factoring is hard, not on a theorem [@hac-1996]. No. Shor's cost grows only polynomially in the number of digits of `N`, so doubling the modulus from 2048 to 4096 bits multiplies the quantum work by a small constant, not by the astronomical factor that same change imposes on classical factoring [@shor-siam-1997]. Key size defends only against the slow lane. Against the quantum threat, the answer is a different primitive, not a longer RSA key [@gidney-2025]. With correct OAEP padding, the low-exponent attacks lose their precondition, so $e = 3$ is not automatically fatal [@cfpr-1996; @rfc8017]. But $e = 65537$ is the safer default: it defeats the low-exponent family outright while staying cheap to compute, so a single padding mistake with $e = 3$ does not immediately reopen Hastad's broadcast or the stereotyped-message attack [@hastad-1988]. Choose the exponent that fails safe. Those are out of scope for this article by design, because they are not breaks of RSA's mathematics. ROCA is a key-generation library defect, Bleichenbacher and Manger are padding oracles, FREAK is a protocol downgrade, and timing and fault attacks are physical side channels. Every one of them breaks the implementation or protocol around RSA, not the algorithm itself. They are the subject of the companion article, *How RSA Breaks in Real Life*. Yes, but only for data with a long confidentiality lifetime. An attacker can record RSA-encrypted traffic now and decrypt it once a quantum computer exists [@gidney-2025]. If your secrets must stay protected for a decade or more, begin planning migration to post-quantum key-establishment even though no such machine exists today and no credible timeline can be given. For short-lived data, the classical picture in this article still governs.

The question this article opened with was not whether RSA is broken, but how it would break if it ever did. The evidence has drawn the map: a bolted front door that opens at a crawl, side windows a good key never leaves ajar, and a single quantum road to a machine still on the horizon.

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.