Parag Mali - tag: quantum-computing

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.

Q-Day Has Not Happened. The Incident Already Has: Harvest Now, Decrypt Later

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

No quantum computer can break RSA or ECC in 2026 -- and yet a long-lived secret you encrypt today may already be lost. The reason is **harvest now, decrypt later**: an adversary who records your encrypted traffic now has done the decisive, irreversible part, and a future quantum computer only finishes the job [@apple-pq3]. That makes the casualty a *deployment* choice -- protecting must-outlive-Q-Day data with a deprecated-but-still-live algorithm -- not a math break that has happened, and the fix (hybrid X25519 + ML-KEM key establishment) is executable today [@ietf-mlkem]. You cannot un-capture ciphertext, so the only defense is to change the deployment before the recording is made.

1. Q-Day Has Not Happened. The Incident Already Has

In 2026, no quantum computer on Earth can factor a 2048-bit RSA key. Not one. The cryptographers who design these systems will tell you so plainly, and they are right: RSA-2048 is unbroken, and the machine that would break it does not exist -- the most recent published analysis still describes hardware that has not been built [@gidney-2025]. And yet a secret you encrypt this morning, if it must stay secret for a decade, may already be lost.

That is not a contradiction. It is the whole story.

The adversary's decisive act is not decryption. It is capture. Someone who records your encrypted traffic today -- the key-exchange handshake and the ciphertext that follows -- has already done the irreversible part. The decryption can wait for a machine that arrives in five years, or fifteen, or thirty. This is the attack the security community calls harvest now, decrypt later, and the United States government now states its rationale in an executive order, warning of "adversaries collecting United States information now, and decrypting it later once large-scale quantum computers are operational" [@eo-14412]. Apple's engineers put the mechanics even more plainly.

Attackers "can collect large amounts of today's encrypted data and file it all away for future reference ... retain it until they acquire a quantum computer that can decrypt it in the future, an attack scenario known as Harvest Now, Decrypt Later." -- Apple Security Engineering and Architecture [@apple-pq3] An attack in which an adversary records encrypted traffic today -- the key-establishment handshake plus the ciphertext -- and stores it indefinitely, planning to decrypt it once a capable quantum computer exists. The decisive act is the capture, not the decryption, so the loss is decided at the moment of recording [@apple-pq3]. A quantum computer large enough and error-corrected enough to run Shor's algorithm against deployed public-key sizes such as RSA-2048 or Curve25519. No CRQC exists in 2026; the published figures for the qubits one would require are estimates on hardware that has not been built [@gidney-2025]. flowchart LR A[Today: adversary records handshake and ciphertext] --> B[Indefinite storage] B --> C[Q-Day: a CRQC runs Shor's algorithm] C --> D[Ciphertext decrypted] A -. the decisive, irreversible act .-> D

So the clock that matters is not "when does Q-Day arrive?" but "how long must this secret survive, and was it captured before I protected it?" The cryptographer Michele Mosca turned that question into an inequality years ago, and we will spend a whole section on it, because it is the spine of everything here: if the lifetime of your secret plus the time you need to migrate exceeds the time until a capable quantum computer exists, you are already exposed [@mosca-2018].

This is why this article belongs in a series about how cryptography breaks in real life -- and why it is the strangest entry in it. Every other casualty here is a break you can point to after the fact: a reused nonce, a padding oracle, a downgrade. This one is different in time. The mathematical weapon does not exist yet, and still the loss is being booked. That is the reconciliation this whole piece defends: the break is not a mathematical event that has happened. It is a deployment choice -- protecting data that must outlive Q-Day with a quantum-vulnerable, deprecated-but-still-live algorithm while someone records the ciphertext. The math finishes the job later. The deployment decides the outcome now.

Key idea: The loss is booked at capture time. Because an adversary who records your ciphertext today has already done the irreversible part, the casualty is decided by the deployment you shipped -- a quantum-vulnerable algorithm protecting data that must outlive Q-Day -- not by a mathematical break that has occurred.

One boundary before we begin. This is a story about confidentiality: recorded ciphertext, decrypted after capture. It is not the story of quantum forgery of digital signatures, which is a different problem on a different clock, and which we will keep scrupulously separate throughout. The mechanism of the eventual break -- how one machine running Shor's algorithm flattens RSA, Diffie-Hellman, and ECC at once -- is the subject of this article's structural sibling, "How Q-Day Breaks Everything: Shor's Algorithm and the Simultaneous Fall of RSA, Diffie-Hellman, and ECC." Here we need only its conclusion.

If the loss is booked the moment the ciphertext is captured, then the only question that matters is what you were doing at capture time. To answer it, we have to see that this idea is older than quantum computing.

2. "Store Now, Decrypt Later" Is Older Than Quantum

Long before anyone wired a lattice into TLS, intelligence agencies were already doing the first half of harvest now, decrypt later -- the harvesting. The behavior the quantum threat depends on is not speculative; it is documented, and it predates the quantum motive by years.

In March 2012, James Bamford reported in Wired that the National Security Agency was building a data center in Bluffdale, Utah -- roughly one million square feet built to intercept and store communications at a scale discussed in exabytes and beyond [@bamford]. The next year, the documents Edward Snowden supplied to journalists revealed Bullrun, a program to defeat and circumvent internet encryption alongside bulk interception and indefinite retention [@bullrun]. The through-line of both is the same: collect broadly, store indefinitely, and revisit the ciphertext later as your ability to read it improves.

The length of time a piece of data must remain secret to avoid harm. A session cookie has a confidentiality lifetime of minutes; a diplomatic cable, an intelligence source's identity, or a person's genome may need to stay secret for decades. It is the single most load-bearing quantity in the harvest-now-decrypt-later argument, because it decides whether a future decryption still matters.

Quantum computing did not invent this behavior. What it changed is the horizon. It introduced a specific future event -- a machine that can run Shor's algorithm -- that would retroactively unlock everything already collected under a quantum-vulnerable algorithm.

In 2015, and again in a 2018 journal version, Michele Mosca gave that horizon a decision rule. If $X$ is how long your data must stay secret, $Y$ how long your migration takes, and $Z$ the time until a capable quantum computer exists, then whenever $X + Y > Z$ you are already too late for that data [@mosca-2015]. He stated the corollary this article turns on in the same breath: "for systems that aim to provide long-term confidentiality, this migration should happen even sooner" [@mosca-2015]. The formal statement followed in IEEE Security & Privacy [@mosca-2018].

Here is where honesty matters more than rhetoric. It is tempting to collapse all of this into one dramatic claim -- "adversaries are harvesting your traffic right now for quantum decryption" -- that the public evidence does not support at that strength. The responsible version is layered.

flowchart TD A[Documented threat model: NSA, CISA, NIST, EO 14412] --> D[HNDL risk to long-lived data] B[Documented general collect-and-store precedent: Utah Data Center 2012, Bullrun 2013] --> D C[Rational-actor inference for the specifically quantum motive: no public smoking gun] --> D The "adversary is recording now" premise is three separate claims, and they do not carry equal weight.

(a) A documented threat model. The agencies that set cryptographic policy -- NSA, CISA, and NIST jointly, and now an executive order -- name harvest now, decrypt later explicitly and build the entire migration around it [@cisa-qr] [@eo-14412] [@nsa-press].

(b) A documented general precedent. Bulk interception and indefinite retention of encrypted traffic are established, documented practices, independent of quantum computing [@bamford] [@bullrun].

(c) A rational-actor inference. That some adversary is specifically recording ciphertext today in order to await a quantum computer is a reasonable inference from (a) and (b) -- it is exactly what a well-resourced intelligence agency would do -- but it remains an inference. There is no public smoking gun: no attributed, confirmed nation-state quantum-harvest program on the record. The argument does not need one. It needs only that the behavior is cheap, documented in general form, and officially treated as the reason to migrate.

Recent events keep the general precedent current without proving the quantum-specific one. The Salt Typhoon campaign, detailed in a 2025 joint advisory, compromised the lawful-intercept infrastructure of U.S. telecommunications carriers [@cisa-salt].Salt Typhoon is espionage against wiretap systems -- interception of communications for conventional intelligence. It is not a quantum-harvest operation, and nothing in the advisory characterizes it as one. It belongs here only as evidence that broad, nation-state interception is ongoing.

Note: Every claim in this article about "harvesting now" means the documented threat model, plus the documented general precedent, plus a rational-actor inference. It never means a proven, attributed, ongoing quantum-harvest operation, because none is public. The strength of the argument does not depend on one existing.

Mosca turned "someday" into an inequality you can run against your own data. But to run it, you first have to know exactly what a future quantum computer can and cannot touch -- because it is far less, and far more specific, than the word "encryption" suggests.

3. Why the Whole Public-Key Stack Is on the Clock -- and Symmetric Mostly Is Not

A single machine running Shor's algorithm would break RSA, finite-field Diffie-Hellman, DSA, and elliptic-curve cryptography -- all of them, together. The same machine would barely inconvenience AES-256. To see why the harvest targets one and not the other, and why that distinction is the difference between a five-minute fix and a decade-long migration, you have to separate two kinds of quantum speedup.

A quantum algorithm, published by Peter Shor in 1994, that factors integers and computes discrete logarithms in polynomial time [@shor-1994]. Because RSA rests on the hardness of factoring, and Diffie-Hellman and ECC rest on the hardness of discrete logarithms, one sufficiently large quantum computer running Shor breaks all of them at once. The full mechanism -- reducing both problems to quantum period-finding -- is developed in this article's structural sibling; here we use only the result [@shor-1997].

The reason RSA, DH, DSA, and ECC fall as a group is that they are variations on the same mathematical trick: a one-way function built from a hidden period or a hidden subgroup. Shor's algorithm is, at its core, a period-finder. Break that abstraction once and every primitive built on it goes down with it -- which is why "quantum-safe" cannot mean "a bigger RSA key." A 4096-bit RSA modulus falls to the same algorithm as a 2048-bit one; only the running time changes, and not by enough to matter [@shor-1997].

Symmetric cryptography is a different story, and the difference is a theorem, not an accident. Against a symmetric cipher or a hash, the best known quantum attack is Grover's algorithm, which delivers only a quadratic speedup -- it effectively halves the security level. A 256-bit key offers roughly 128 bits of security against a quantum search, which is still far out of reach.Grover's quadratic speedup is neutralized by doubling the key or lengthening the digest, and symmetric crypto scales cheaply: doubling the key size typically costs far less than half again the performance [@cf-pq2024]. This is why AES-256 and SHA-384/512 need no replacement [@cnsa-2]. That is exactly why the NSA's post-quantum suite keeps AES-256 and SHA-384/512 unchanged while replacing every public-key algorithm [@cnsa-2], and why NIST pins its post-quantum security categories to symmetric strengths Grover cannot reach [@cf-pq2024].

So the casualty is specific. It is not "encryption" in general. It is public-key key establishment: the handshake step where two parties agree on the symmetric key that will actually encrypt the data.

The step in a secure protocol where two parties agree on a fresh shared secret -- the symmetric session key -- that encrypts the rest of the conversation. In TLS this is the key-exchange portion of the handshake. It travels in the clear, which is exactly why an adversary can record it, and it is the specific thing harvest now, decrypt later targets.

Why key establishment and not the bulk-encrypted payload directly? Because the payload is protected by a symmetric key that Grover cannot recover -- but that key was itself agreed using a public-key exchange that Shor can break. Record the handshake and the ciphertext together, wait for a CRQC, run Shor against the recorded public values, recover the session key, and the whole conversation decrypts. The symmetric layer never had to fall; the key that unlocks it was handed over in a form the future machine can read.The same RSA or ECC key pair can serve key establishment (confidentiality) or signatures (authenticity). Only the confidentiality use is harvestable in advance. Signatures are a separate casualty, on a separate clock.

This sets the contract for the rest of the article, and it is a contract with two clocks.

Note: Confidentiality (harvest now, decrypt later). An adversary records ciphertext today and decrypts it after a future CRQC exists. The decisive act is now; the fix is post-quantum key establishment, deployable today. Authenticity (signature forgery). An adversary forges a signature. This requires a quantum computer at the moment of the attack -- you cannot forge tomorrow's signature by recording today's traffic. It is a real problem, but a later one, on a different clock. The two never share a single verdict.

The confidentiality casualty, then, is narrow and precise: public-key key establishment, recorded today, decrypted after Q-Day. The next question is what defenders did once they understood that -- and it turns out they have been racing this particular recording for the better part of a decade.

4. The Defense, Generation by Generation, Racing the Harvest

Here the usual shape of a "how it breaks" story inverts. There is no lineage of attacks to catalog, because the attack is future and singular -- one machine, not yet built. What has a lineage is the defense. And the first entry in that lineage is not a defense at all. It is the status quo, and its weakness is this article's entire thesis.

Generation 0: the harvestable baseline

Classical public-key key establishment -- RSA key transport, and in modern TLS 1.3 the elliptic-curve exchange X25519 -- is where the loss is booked. Two parties derive a shared secret from public values whose security rests on factoring or the discrete logarithm; the handshake, including those public values, crosses the wire in the clear.

Modern TLS already improved on the worst version of this. Ephemeral elliptic-curve Diffie-Hellman gives forward secrecy.

A property of ephemeral key exchange: because each session's secret is generated fresh and never transmitted, compromising a server's long-term private key later does not decrypt past recorded sessions. It defends against a future *key* compromise -- but not against a future break of the underlying *math*.

That last distinction is the whole game. Forward secrecy assumes the discrete-logarithm problem stays hard; Shor voids that assumption. As Cloudflare put it, encrypted traffic "can be harvested today, and decrypted with a quantum computer in the future" -- and against that recording, even forward secrecy does not help [@cf-pq2024]. An adversary who records the X25519 handshake plus the ciphertext has everything needed to recover the session key once a CRQC exists: Mosca's inequality booking a loss the moment $X + Y > Z$ [@mosca-2018]. Gen 0 is not broken today -- RSA-2048 is unbroken in 2026 -- but protecting must-outlive-Q-Day data with it while the recording runs is the deployment choice that decides the casualty.

If the loss is booked at capture time, the defense cannot wait for Q-Day. It has to put a quantum-resistant secret into the handshake before the recording is made.

Generation 1: the first hybrids

In 2016, Google ran the first real experiment: CECPQ1, a combination of X25519 with NewHope, a lattice key exchange, deployed live in Chrome and TLS by Matt Braithwaite and Adam Langley [@google-cecpq1] [@newhope].CECPQ stands for Combined Elliptic-Curve and Post-Quantum. The design principle is right there in the name: run both, and be no worse off than before even if the post-quantum half turns out to be worthless. Two years later came CECPQ2, pairing X25519 with an NTRU-based lattice scheme, HRSS [@langley-cecpq2].

The idea both shared is the one the entire lineage inherits: run a classical and a post-quantum exchange side by side and combine both secrets, so the session is no worse than before even if the post-quantum part is later found useless. Langley's rationale for shipping years ahead of any standard was itself a harvest-now-decrypt-later argument, and he drew the confidentiality-versus-authenticity line this article insists on, noting that the work "only addresses confidentiality, not authenticity," and that "confidentiality is more pressing since it can be broken retrospectively" [@langley-cecpq2].

NewHope, CECPQ1's post-quantum half, was only CPA-secure -- a weaker guarantee than usual. That was acceptable in TLS precisely because confidentiality keys there are ephemeral, used once and discarded [@newhope].

These were experiments, built to be thrown away. They used pre-standard primitives chosen before NIST had settled the field -- "destined to be replaced," in Langley's words [@langley-cecpq2]. What they proved is that a hybrid can ride real TLS at scale, surfacing the practical problems (larger handshakes, middlebox tolerance) that would dominate deployment. The field now needed a single, vetted primitive to put inside the hybrid.

Generation 2: the standardized primitive

On 13 August 2024, NIST published FIPS 203, standardizing ML-KEM -- the primitive every later deployment instantiates [@fips-203].

The Module-Lattice-Based Key-Encapsulation Mechanism, standardized as NIST FIPS 203 on 13 August 2024, based on the Module Learning-With-Errors problem. It comes in three parameter sets -- ML-KEM-512, ML-KEM-768, and ML-KEM-1024 -- and it is a key-encapsulation mechanism, explicitly not a Diffie-Hellman-style non-interactive key agreement [@fips-203].

"ML-KEM is the new name for Kyber" [@cf-pq2024]. The scheme was called CRYSTALS-Kyber during the NIST competition; in a 2026 voice the standardized name is ML-KEM, and that is the name used throughout here.

The structural point that shapes everything downstream: ML-KEM is a KEM, not a NIKE. Rather than two parties deriving a key from public values with no message in between (which is what Diffie-Hellman does), one party encapsulates a fresh secret to the other's public key and sends back a ciphertext. That single fact is why the deployed answer is a hybrid handshake and not a drop-in "post-quantum Diffie-Hellman." But a primitive sitting in a PDF protects no packet, and ML-KEM deployed alone is a single-primitive bet on a young standard -- a bet the next section shows can go badly. The prudent way to ship it is inside a hybrid.

Generation 3: protocol integration

This is where the standard becomes protection booked at capture time. For TLS 1.3, the IETF defined the hybrid group X25519MLKEM768: a client share of 1216 bytes -- a 1184-byte ML-KEM-768 encapsulation key concatenated with a 32-byte X25519 share -- combined into a 64-byte shared secret, at codepoint 0x11EC [@ietf-mlkem].

Secure messaging moved even earlier. Signal shipped PQXDH, "an upgrade to the X3DH specification," to all users on 19 September 2023 -- the first at-scale messenger to put post-quantum protection into initial key establishment [@signal-pqxdh]. Apple followed on 21 February 2024 with iMessage PQ3 [@apple-pq3]. And remote administration was not far behind: OpenSSH 9.9, released 2024-09-19, made the hybrid mlkem768x25519-sha256 exchange available by default [@openssh-99].

Every one of these derives the session key from both an X25519 secret and an ML-KEM secret, so it stays secure if either component holds. Each session negotiated this way is one the harvest can no longer bank on. What integration did not yet deliver was ubiquity: in 2024 these were defaults on some clients and servers, not all, and the surfaces most likely to hold long-lived secrets lagged furthest behind.

Generation 4: scale

Then the defaults arrived. OpenSSL 3.5, released 8 April 2025, changed its default TLS groups to include and prefer hybrid post-quantum KEM groups [@openssl-35]. With Chrome and Firefox defaulting to the hybrid on the client side and Cloudflare terminating it at the edge, adoption climbed from "nearly two percent" of Cloudflare's TLS 1.3 connections in early 2024, toward double-digit adoption by the end of that year [@cf-pq2024], to a majority of human web traffic by late 2025 [@cf-pq2025]. The exact figure, around 52 percent, is best read as a dated snapshot from live telemetry rather than a steady state [@cf-radar] [@heise] [@postquantum-com].

flowchart LR G0[Gen 0: classical-only X25519 and RSA, harvestable] --> G1[Gen 1: hybrid experiments CECPQ1 2016, CECPQ2 2018] G1 --> G2[Gen 2: standardized primitive ML-KEM / FIPS 203, 2024] G2 --> G3[Gen 3: protocol integration PQXDH, PQ3, OpenSSH 9.9, X25519MLKEM768] G3 --> G4[Gen 4: hybrid default across a majority of web traffic, 2025]

Generation	Year	Key idea	Representative	Status
Gen 0 -- harvestable baseline	1990s-present	Classical-only key establishment; forward secrecy only	RSA key transport, X25519 ECDHE	Still-live baseline [@cf-pq2024]
Gen 1 -- first hybrids	2016, 2018	Classical + pre-standard PQ, safe if either half holds	CECPQ1, CECPQ2	Historical [@langley-cecpq2]
Gen 2 -- the primitive	2024	A single vetted, standardized KEM (not a NIKE)	ML-KEM / FIPS 203	Active component [@fips-203]
Gen 3 -- integration	2023-2024	Wire the KEM into real handshakes as a hybrid	X25519MLKEM768, PQXDH, PQ3, OpenSSH 9.9	Active [@ietf-mlkem] [@signal-pqxdh] [@apple-pq3] [@openssh-99]
Gen 4 -- scale	2025	Hybrid on by default at internet scale	OpenSSL 3.5; majority of web traffic	Active frontier [@openssl-35] [@cf-pq2025]

Each generation closed one gap the last had left open: no vetted primitive, then no deployment, then no ubiquity. None closed the one gap that no later fix can close -- the ciphertext an adversary already captured. And one question still hangs over the whole catalog: why wrap a standardized post-quantum algorithm in a hybrid at all? Why not simply ship the newest, strongest post-quantum scheme on its own? A dead end from 2022 answers that better than any argument.

5. The Ten-Minute Break That Vindicated Hybrids

In July 2022, a post-quantum key-encapsulation mechanism named SIKE was broken. Not weakened -- broken, completely, its private key recovered from public data. The remarkable part was how. SIKE was not a fringe proposal; it was a NIST Round-4 candidate, a scheme that had survived years of public analysis in the world's most scrutinized cryptography competition. And it fell not to a quantum computer but to a mathematician with a laptop.

The attack "breaks SIKEp434, which aims at security level 1, in about ten minutes on a single core." -- Wouter Castryck and Thomas Decru [@sike-break]

Castryck and Decru found that the extra data SIKE's underlying protocol exchanged -- torsion-point images -- leaked enough structure to recover the secret key in heuristic polynomial time. Their implementation broke the security-level-1 parameter set in about ten minutes on one CPU core [@sike-break]. No error correction, no millions of qubits. Just mathematics that had been missed.

Now hold that against the problem this article has been building toward. You are deploying cryptography to protect data whose confidentiality must outlast a recording you cannot see and cannot un-make. If you bet everything on a single post-quantum scheme, and that scheme turns out to have a SIKE-shaped flaw discovered five years from now, every session you protected with it becomes retroactively readable -- and the ciphertext is already in someone's archive. Against a recording you cannot un-make, a single-primitive bet on a young standard is the one bet you cannot afford.

That is the whole argument for hybrids, and it fits in a sentence.

Key idea: Migration is a race against a recording you cannot see. Because you can never un-capture ciphertext, the only defense is to change the deployment before capture -- and the only change safe against both a future quantum computer and an undiscovered flaw in young post-quantum math is a hybrid that survives if either component holds.

Deriving one session key from two independent key exchanges -- a classical one such as X25519 and a post-quantum one such as ML-KEM-768 -- combined through a key-derivation function so the result stays secure as long as at least one of the two remains unbroken. It is a deliberate hedge in both directions: against a future quantum break of the classical half, and against an undiscovered flaw in the young post-quantum half.

Here is the part that turns the argument from plausible to proven. When Google and Cloudflare trialed the isogeny family, they did it as a hybrid too -- CECPQ2b, X25519 combined with SIKE. So when SIKE collapsed in 2022, the question was not academic: what happened to the sessions that had negotiated the SIKE hybrid? The answer is that they were fine. Every X25519 plus SIKE session stayed confidential, because X25519 held when SIKE fell. The "safe if either half holds" design did exactly its job -- in the field, against a real and total break of one half.

SIKE is a dead end, not a step in the defense lineage -- but it is the load-bearing dead end, because it is the empirical proof of the hybrid thesis. A NIST Round-4 candidate KEM fell to a laptop in minutes, and the deployments that had wrapped it in a hybrid lost nothing, because their classical half was untouched. This is the concrete answer to the tempting question "why not just ship the newest pure post-quantum algorithm?" Because young primitives can die suddenly, without warning, from a piece of mathematics nobody had noticed -- and when the thing you are protecting is a recording that cannot be un-made, you diversify the bet. The isogeny *idea* is not entirely dead, but SIKE as a key-establishment path is finished, and it took CECPQ2b with it [@sike-break].

The design principle is now settled, and the deployment is largely built. So what does correct, quantum-safe confidentiality actually look like on the wire in 2026?

6. What Quantum-Safe Confidentiality Looks Like in 2026

By 2026 the state of the art has converged on a single shape: a standardized post-quantum KEM (ML-KEM), wrapped in a hybrid with a classical elliptic-curve exchange, wired into the real key-establishment step of TLS, SSH, and secure messaging, and turned on by default. Everything deployed today is a variation on that one sentence.

Start with the flagship. The TLS 1.3 hybrid group X25519MLKEM768 sends a client share of 1216 bytes -- the 1184-byte ML-KEM-768 encapsulation key followed by the 32-byte X25519 share -- and receives a 1120-byte server share, a 1088-byte ML-KEM ciphertext plus the server's 32-byte X25519 share, from which both sides derive a 64-byte combined secret. Its IANA codepoint is 0x11EC [@ietf-mlkem].The group name lists its components in the reverse of their wire order: the client share carries the 1184-byte ML-KEM-768 key first, then the 32-byte X25519 share, yet the name puts X25519 first, "for historical reasons" [@ietf-mlkem]. Naming is hard, even in cryptography.

A three-algorithm scheme -- key generation, encapsulation, and decapsulation -- in which one party encapsulates a fresh random secret to the other's public key and transmits the resulting ciphertext, and the key holder decapsulates it to recover the same secret. This is structurally unlike a non-interactive key agreement (a NIKE) such as Diffie-Hellman, where both sides derive the key from public values with no ciphertext exchanged. ML-KEM is a KEM, which is why the post-quantum answer is a hybrid handshake and not a "post-quantum Diffie-Hellman" [@fips-203]. sequenceDiagram participant C as Client participant S as Server C->>S: X25519 share and ML-KEM-768 encapsulation key (1216-byte client share) S->>C: X25519 share and ML-KEM-768 ciphertext (1120-byte server share) Note over C,S: Each side computes an X25519 secret AND an ML-KEM secret Note over C,S: A KDF combines both into the session key, safe if either half holds

The same hybrid shape shows up everywhere else. OpenSSH exposes it as mlkem768x25519-sha256, available by default since 9.9 [@openssh-99]. Signal's PQXDH puts a lattice KEM alongside the classical exchange in initial key establishment; Apple's PQ3 does the same and extends post-quantum protection to ongoing rekeying as well [@signal-pqxdh] [@apple-pq3]. Apple ranks these on a coarse scale of its own -- Signal's initial-key-establishment protection at "Level 2," PQ3's establishment-plus-rekey at "Level 3" -- though those levels are Apple's own taxonomy, not an industry standard [@apple-pq3].

Method	Layer protected	Break requires	Extra wire cost	Default on?
X25519MLKEM768 (TLS)	TLS key establishment	X25519 and ML-KEM-768	~1.2 KB client share	Yes: browsers, OpenSSL 3.5 [@openssl-35]
mlkem768x25519-sha256 (SSH)	SSH key establishment	X25519 and ML-KEM-768	~1.2 KB	Yes: OpenSSH 9.9 and later [@openssh-99]
PQXDH (Signal, "Level 2")	Messaging initial key est.	X25519 and lattice KEM	~1 KB per establishment	Yes: all users [@signal-pqxdh]
PQ3 (Apple, "Level 3")	Messaging key est. and rekey	ECC and lattice KEM	~1 KB per est. and rekey	Yes: iOS 17.4 and later [@apple-pq3]
Pure ML-KEM-1024 (CNSA 2.0)	Key establishment	ML-KEM-1024 alone	~1.5 KB, no ECC	Federal direction [@cnsa-2]
Classical X25519 (baseline)	Key establishment	X25519 alone, so a CRQC	none (32-byte baseline)	Yes: legacy [@cf-pq2024]

Notice what the KEM structure forces. Because ML-KEM encapsulates a secret and returns a ciphertext, rather than agreeing a key from two public values the way Diffie-Hellman does, the deployed construction is a hybrid handshake, not a "post-quantum Diffie-Hellman" [@fips-203]. That is the single most common misconception about post-quantum key exchange, and the shape of the wire is why it is wrong.

A key-agreement scheme in which two parties compute a shared secret purely from each other's published public values, with no ciphertext or extra protocol message passing between them -- which is exactly what classical Diffie-Hellman is. A KEM is not a NIKE: it requires one side to encapsulate a secret and send a ciphertext back. That structural gap is why a genuine "post-quantum Diffie-Hellman" would need a post-quantum NIKE, and why the absence of one forces the deployed answer into a hybrid handshake instead [@fips-203]. If a true post-quantum Diffie-Hellman existed -- a non-interactive key exchange as clean as the classical one -- it would be the perfect drop-in, and none of the hybrid-handshake plumbing would be necessary. One candidate does exist in the literature: CSIDH, an isogeny-based group action its authors proposed as "suitable for non-interactive key exchange in a post-quantum setting," with public keys of only 64 bytes [@csidh]. But its concrete quantum security is disputed -- Peikert's C-sieve cryptanalysis "strongly invalidates its claimed NIST level 1 quantum security" for the CSIDH-512 parameters [@peikert-csieve] -- and it belongs to the same isogeny family whose SIKE cousin fell classically in ten minutes. The information-theoretic alternatives, the one-time pad and quantum key distribution, do not scale to open-internet key establishment. So a standardized KEM wrapped in a hybrid, switched on before capture, is not a compromise forced by expedience. It is the realizable ideal: the best construction actually available, given that the cleaner primitive is either undeployable or untrusted.

The cost of all this is worth stating precisely, because it lands where people do not expect. Lattice operations are cheap; the CPU overhead of an ML-KEM key generation, encapsulation, and decapsulation is negligible. The cost is bytes.

{` const X25519_SHARE = 32; // classical elliptic-curve share const MLKEM768_EK = 1184; // ML-KEM-768 encapsulation key (FIPS 203) const hybridShare = MLKEM768_EK + X25519_SHARE; // 1216 bytes, codepoint 0x11EC

console.log('Classical X25519 client share :', X25519_SHARE, 'bytes'); console.log('Hybrid X25519MLKEM768 share :', hybridShare, 'bytes'); console.log('Extra on the wire : ~' + ((hybridShare - X25519_SHARE) / 1024).toFixed(2) + ' KB'); // ~1.2 KB extra is why a post-quantum ClientHello can span more than one TCP segment (tldr.fail). // CPU cost is negligible: lattice KEM operations are cheap. `}

About 1.2 kilobytes of extra ClientHello: that is the price of quantum-safe confidentiality on the wire, and it is why the hard problems in this migration are network problems -- does the larger handshake fit through every middlebox? -- rather than compute problems.

Now the honest part, the part a launch post tends to skip.

Note: Turning on X25519MLKEM768 protects new key establishment. It does nothing for four things: ciphertext an adversary already captured (irreversible); digital signatures and the Web PKI (a different threat model, on a different clock); data encrypted at rest under a quantum-vulnerable scheme; and the long tail of non-browser protocols that have not enabled a hybrid group. A "majority of web traffic" statistic is a browser statistic.

That last point deserves weight before we move on. The adoption curve is real, but it measures browser-terminated TLS. It says nothing about the VPN concentrator, the mail server, the database connection, or the backup pipeline -- and those are exactly the surfaces most likely to be carrying secrets with long confidentiality lifetimes.

This shape -- ML-KEM in a hybrid, on by default -- is the consensus of browsers, Signal, Apple, OpenSSH, and the CDNs. But it is not the consensus of everyone. The U.S. government is quietly betting on a different design, and the disagreement is real.

7. The Migration's Open Fault Lines

The commercial internet ships hybrids. The NSA does not want to. Its Commercial National Security Algorithm Suite 2.0 leans toward pure ML-KEM-1024, with no classical curve alongside it [@cnsa-2]. This is not a mistake to correct in either direction. It is a real disagreement between reasonable parties, worth understanding rather than resolving.

Hybrid versus pure

The case for the hybrid is the one this article has already earned: provably secure if either component holds, and vindicated in the field when SIKE fell. The formal guarantee is not a slogan. For the exact pairing of X25519 with ML-KEM-768, the X-Wing construction proves the combined KEM is secure as long as either component is -- classically if X25519 holds, post-quantum if ML-KEM-768 holds [@xwing]. To recover a hybrid session key, an adversary must break both the elliptic-curve discrete logarithm (which needs a quantum computer) and Module-LWE (which needs a cryptanalytic break) -- strictly harder than breaking either one alone.

There is a deeper reason the hybrid is more than belt-and-suspenders, and it is epistemic rather than mechanical. ML-KEM's security rests on the presumed hardness of a lattice problem -- and "presumed" is the load-bearing word.

The lattice problem underneath ML-KEM: recovering a secret from many linear equations over a polynomial module that have been deliberately perturbed with small random errors. FIPS 203 claims only that ML-KEM "is believed to be secure, even against adversaries who possess a quantum computer" -- there is no proof that Module-LWE is hard for a classical or a quantum machine, any more than there is a proof that integer factoring or the discrete logarithm is hard [@fips-203].

This is the honest core of the hybrid argument. The security of RSA, of elliptic curves, and of ML-KEM alike rests on unproven conjectures -- problems the world has failed to solve, not problems anyone has shown are unsolvable. A hybrid does not escape that condition; it diversifies the wager across two independent unproven conjectures, so that a break of either one alone is survivable. It buys resilience, not a proof. Nothing deployed at internet scale offers a proof.

The case for pure ML-KEM-1024 is not irrational either. A vetted standard at its highest parameter set, the argument goes, should stand on its own; a hybrid adds a second code path, a combiner to get right, and larger messages, and complexity is itself attack surface. The preference is old and consistent: at CRYPTO 2018 the NSA already stated its intent to publish pure post-quantum standards "not combined with an elliptic-curve operation as a safeguard," as Langley recorded at the time [@langley-cecpq2].

Question	Hybrid (X25519 + ML-KEM-768)	Pure ML-KEM-1024
If ML-KEM is later broken	Still safe -- X25519 holds	Broken: single-primitive bet
If X25519 is later broken (CRQC)	Still safe -- ML-KEM holds	Safe: ML-KEM is designed for this
Formal guarantee	Secure if either component is secure (X-Wing) [@xwing]	Rests entirely on Module-LWE
Empirical precedent	SIKE hybrid survived the 2022 break [@sike-break]	A pure SIKE deployment would have been harvestable
Complexity	Two code paths plus a combiner	One primitive, one path
Who ships it	IETF, browsers, OpenSSL, OpenSSH, Signal, Apple	NSA CNSA 2.0 for national-security systems [@cnsa-2]

The honest verdict is that this is unresolved. For migration today, against a recording you cannot un-make, the hybrid is the defensible default: it costs one extra primitive and about 1.2 kilobytes to convert "we bet everything on a five-year-old lattice assumption" into "we lose only if both a classical curve and a lattice scheme fall." But the pure-PQC position -- that ML-KEM-1024 will hold, and that simplicity is a security property -- is a coherent bet on a leaner steady state. The SIKE episode is a live counterexample to single-primitive confidence during migration, not a proof that pure PQC is wrong forever.

It is worth remembering why the field landed on lattices at all, because that too was a measured choice rather than a foregone one.

Metric (production TLS experiment, 2019)	HRSS lattice (CECPQ2)	SIKE isogeny (CECPQ2b)
Public-key size	~1100 bytes	~330 bytes
Relative compute cost	Low (orders of magnitude faster)	High
Typical client	Matches or beats the isogeny scheme	Slower for most clients
Where the isogeny scheme wins	--	Only the slowest tail of clients

Before ML-KEM was the standard, Cloudflare and Google ran a production experiment pitting a lattice hybrid against the tiny-keyed isogeny hybrid, whose public keys were roughly 330 bytes against the lattice scheme's ~1100 [@cf-towards]. Nick Sullivan framed it as an ostrich against a turkey: the lattice scheme big but fast, the isogeny scheme small but slow. The ostrich won -- the lattice hybrid matched or beat the isogeny one for the overwhelming majority of clients, and the small keys did not offset the computational cost [@cf-experiment]. The later SIKE break removed isogeny KEMs from contention on security too. Both results point at the same 2026 answer: a lattice KEM, in a hybrid.

Two migrations, two clocks

The second fault line is not really a contest, and treating it as one is a category error the whole article has worked to prevent. Key-establishment migration closes the harvest-now-decrypt-later window and can be deployed today. Signature migration answers a different threat model -- forgery by a quantum adversary at attack time -- and is years behind, entangled with the certificate infrastructure and slowed by larger, heavier post-quantum signatures. The standardized signature primitives already exist, ML-DSA and SLH-DSA [@fips-204] [@fips-205], with more arriving through NIST's signatures onramp [@pqc-dig-sig], but deployment across the Web PKI has barely begun.

Federal policy keeps the two explicitly separate, and always in the same order.

Three dated policies shape the U.S. migration, and they keep the two clocks apart. CNSA 2.0 sets the direction for national-security systems toward pure ML-KEM-1024 [@cnsa-2]. Executive Order 14412 sets federal deadlines: post-quantum key establishment by 31 December 2030, digital signatures by 31 December 2031 [@eo-14412]. And NIST IR 8547 -- still an initial public draft, so its dates may shift -- would deprecate quantum-vulnerable public-key algorithms after 2030 and disallow them after 2035 [@ir-8547]. Key establishment always leads signatures, because the confidentiality clock is the urgent one.

Note: Neither debate here has a settled answer. Hybrid-versus-pure is a genuine trade-off between diversifying a bet and minimizing complexity. Key-establishment-versus-signature migration is not a contest at all -- they are different problems on different clocks. Anyone who tells you one option simply wins is smoothing over a real disagreement.

Both debates, though, quietly assume you at least know when you must be finished. But the deadline term in Mosca's inequality -- the time until Q-Day -- is the one number nobody can honestly give you.

8. Mosca's Inequality, and What It Can and Cannot Promise

The load-bearing "bound" in this field is a strange one. It is not a complexity bound on an algorithm, nor a lower bound on an adversary's work. It is a decision rule about a race between clocks, and it is the tool that turns a fuzzy future into a concrete, present-tense choice you can make one dataset at a time.

Michele Mosca's decision rule for quantum risk. Let $X$ be the number of years your data must remain secret, $Y$ the number of years your migration to quantum-safe cryptography will take, and $Z$ the number of years until a cryptographically-relevant quantum computer exists. If $X + Y > Z$, your data is already exposed: it will still demand secrecy at a time when the machine that breaks it exists [@mosca-2018].

Read it slowly, because the ordering of the terms is the whole insight. $Y$ and $Z$ are the usual suspects -- how long migration takes, how long until the machine. But $X$, the secrecy lifetime, is what makes the loss present-tense. The adversary's decisive act, capturing the ciphertext, happens now. So for a given dataset you are not really racing $Z$; you are racing $Z$ minus however long the recording has already been running, against $Y$. If your data must stay secret for thirty years, you do not have "until Q-Day" to migrate. You had until the moment someone started recording [@mosca-2015].

flowchart TD A[X: required secrecy lifetime] --> D{"X + Y > Z ?"} B[Y: time to migrate] --> D C[Z: time to a CRQC, uncertain but tightening] --> D D -->|Yes| E[Already exposed: migrate this data class first] D -->|No| F[Lower priority, re-check as Z tightens]

The practical payoff is that you can run this yourself, today, against your own data. The numbers below are illustrative -- pick your own $Z$ and re-run -- but the structure is exactly Mosca's.

{` // X = required secrecy lifetime (years); Y = migration time (years); // Z = years until a cryptographically-relevant quantum computer (UNCERTAIN). const mosca = (X, Y, Z) => (X + Y) > Z;

const Z = 12; // a deliberately uncertain estimate -- change it and re-run const data = [ { name: 'Genomic records', X: 50, Y: 3 }, { name: 'State secrets', X: 30, Y: 3 }, { name: 'Long-term IP', X: 20, Y: 3 }, { name: 'Session cookie', X: 0.1, Y: 3 }, ];

for (const d of data) { const exposed = mosca(d.X, d.Y, Z); console.log(d.name.padEnd(18) + (exposed ? 'ALREADY EXPOSED -- migrate first' : 'lower priority')); } `}

Change $Z$ to anything you like. The genome stays exposed under almost every value you would plausibly choose; the session cookie almost never does. That is the inequality doing its real work -- not predicting Q-Day, but sorting your data by whether the decision has already been lost.

Now the limits, stated as plainly as the thesis.

No cryptographically-relevant quantum computer exists in 2026. RSA-2048 is unbroken. Every qubit figure in circulation is an estimate of what an unbuilt machine would require, and those estimates are falling. In 2019, Gidney and Ekera estimated that factoring RSA-2048 would take on the order of twenty million noisy qubits over about eight hours [@gidney-ekera-2019]. In 2025, Gidney revised the figure to fewer than one million noisy qubits in under a week [@gidney-2025]. That is a roughly twentyfold drop in six years -- and still not a demonstration. The honest description of the timeline is uncertain but tightening.Mosca himself once put "a 1/2 chance of breaking RSA-2048 by 2031" -- but that is his estimate, not a consensus, and this article endorses no Q-Day date [@mosca-2015].

This uncertainty is exactly why some cryptographers who once shrugged at the quantum threat no longer do. The falling estimates do not name a date; they make the risk action-forcing without one.

"I need you to recognize how immediately dispositive that is." -- Filippo Valsorda, on why an uncertain timeline is still action-forcing [@valsorda]

There is a common objection worth meeting head-on: most TLS traffic is short-lived, so who cares if it is harvested? The objection is correct, and it does not weaken the thesis -- it sharpens it. Because ephemeral session traffic has almost no value years from now, the genuine harvest-now-decrypt-later risk concentrates precisely on the data with long confidentiality lifetimes: state secrets, health and genomic records, source identities, long-term intellectual property. The short-lived-traffic point does not universalize the casualty; it focuses it.

All of this rests on conjectural hardness. No one has proved that a quantum computer -- or even a classical one -- cannot break ML-KEM, RSA, or elliptic curves. Their security rests on the presumed hardness of Module-LWE, factoring, and the discrete logarithm; FIPS 203 itself claims only that ML-KEM "is believed to be secure" [@fips-203]. A hybrid does not dissolve that uncertainty. It spreads the wager across two independent unproven conjectures, so a break of one alone is survivable, but it proves nothing -- which is why this migration is risk management performed before capture, not a certificate of safety [@xwing].

And then the one limit no engineering reverses.

Key idea: Harvested ciphertext is the one loss no future fix reverses. Migration can protect every session from this moment forward, but it cannot reach back and protect a recording already sitting in an archive. For data whose secrecy must span the gap, the decision was made at capture -- which is why the deployment choice, not the future math, is where the casualty is booked.

The inequality tells you how to decide under uncertainty. But it silently assumes one thing: that you can still migrate before capture. For a great deal of data already on the wire, that assumption is false. Which raises the question the deployment curve tends to obscure: where does the harvest still win?

9. Where the Harvest Still Wins

A majority of web traffic riding hybrid key agreement is a real milestone, and also a misleading one, because "majority of web traffic" is not "done." Six frontiers remain, and the first is permanent.

Ciphertext already captured. This is the irreversible frontier. Any long-lived secret already sent under classical-only key establishment and recorded by an adversary is beyond rescue; no hybrid, no key rotation, no future standard can reach into an archive and un-capture it. The only levers left are operational -- re-key and re-encrypt long-lived secrets under a hybrid now, so you stop adding to the harvested set, and rotate credentials that may already be exposed. You can stop the set from growing. You cannot make it smaller.

The long tail of unmigrated surfaces. Browser TLS is migrating fast; almost nothing else is. VPNs, email transport over SMTP and IMAP, database connections, internal service meshes, backups, machine-to-machine APIs, and the vast installed base of IoT devices still negotiate classical-only key establishment in 2026. These surfaces are not a random sample -- they disproportionately carry exactly the long-confidentiality-lifetime data where the sharpened risk concentrates.

Note: The adoption number that gets quoted -- a majority of human web traffic -- is a browser number. The mail server holding a decade of correspondence, the database of health records, the backup vault, and the site-to-site VPN carrying internal traffic are usually still classical-only. The surfaces least migrated are the ones whose secrets have the longest lifetimes.

The bug that makes turning it on look like breaking the internet. There is a mundane, maddening obstacle to flipping the switch.

A post-quantum ClientHello is about 1.2 kilobytes larger than a classical one, which pushes it past a single packet. A single call to TCP `read()` may then return only part of the ClientHello. Servers and middleboxes that quietly assumed a one-packet ClientHello -- calling `read()` exactly once, or refusing a split message -- reject the connection outright instead of falling back to a classical handshake. Enabling post-quantum key exchange can therefore look, from the outside, like it "breaks the internet," when it merely exposes a pre-existing bug in how those servers read from a socket. The failure is documented and named at tldr.fail, which also makes the boundary point this article keeps insisting on: the store-then-decrypt threat does not apply to authentication, because connections are authenticated in real time, so signatures are not harvestable the way key establishment is [@tldrfail].

Timeline uncertainty. Z is unknowable from public information. The estimates fall, but they describe unbuilt hardware, and no one can honestly hand you a date. Over-confidence in a late Z under-protects long-lived data; a false "imminent" claim wastes scarce migration effort. The discipline is to treat Z as uncertain but tightening, and decide by data lifetime rather than prediction.

Crypto-agility and inventory. Most organizations cannot say, with confidence, where and which cryptography they run. You cannot prioritize -- or even find -- the long-lived-secret surfaces that harvest now, decrypt later targets, if they are invisible to you.The blunt version: you cannot rotate what you cannot see. An un-inventoried quantum-vulnerable endpoint protecting decade-lifetime data is a silent casualty. Building and maintaining that inventory is the subject of this article's crypto-agility and cryptographic-bill-of-materials sibling. The official guidance already centers this: the joint CISA, NSA, and NIST quantum-readiness factsheet urges a cryptographic inventory that prioritizes long-term-confidentiality data [@cisa-qr], and NIST IR 8547 sets the deprecation clock that inventory has to race [@ir-8547].

The signature and PKI migration. Authentication is also quantum-vulnerable, but -- and this is the boundary the whole article has policed -- it is not the harvest-now-decrypt-later problem. Forging a signature needs a quantum computer at attack time, so it cannot be harvested in advance. Its migration is the separate, later track the fault-lines section already mapped. It is important, it is on a separate clock, and it is not the confidentiality remedy.

None of this is hopeless. Most of it is a to-do list. So here is the to-do list, in priority order.

10. What to Do Before Q-Day, Prioritized by Data Lifetime

You cannot un-capture the past. But you can stop feeding the harvest today, and the order in which you do it is not arbitrary -- it is set by the confidentiality lifetime of each data class. Run Mosca's inequality in your head as you read: the longer the secrecy lifetime, the more urgent the migration.

1. Inventory the longest-lived secrets first. Before turning any knob, find the data whose secrecy must span decades: genomic and health records, state secrets, source identities, long-validity keys, long-term intellectual property. For each class, the secrecy lifetime alone may already exceed any plausible time-to-Q-Day, which puts it at the front of the queue. You cannot protect what you have not located.

Data class	Typical secrecy lifetime	Priority	Action
Genomic and health records	Decades	Highest	Hybrid now; re-encrypt stored data
State secrets, source identities	25+ years	Highest	Hybrid now; audit what may already be captured
Long-term IP, legal, financial	10-20 years	High	Hybrid on all TLS and SSH termination
Business correspondence, email	Years	Medium	Post-quantum-capable transport and messaging
Session tokens, ephemeral traffic	Minutes to hours	Low	Migrate with the default; no rush

2. Turn on hybrid key establishment wherever you terminate TLS or SSH. This is the single most effective action, and modern tooling makes it nearly free: OpenSSL 3.5 ships the hybrid group as a default, and OpenSSH 9.9 and later offer mlkem768x25519-sha256 by default [@openssl-35] [@openssh-99]. It is downgrade-safe -- a peer that does not support the group simply negotiates a classical one -- so enabling it is never worse than the status quo.

On a recent OpenSSH build, list the key-exchange algorithms and look for the hybrid:

ssh -Q kex | grep mlkem

If mlkem768x25519-sha256 appears, your client can already negotiate post-quantum key exchange (OpenSSH 9.9 and later). For TLS, a current OpenSSL can attempt the hybrid group directly:

openssl s_client -groups X25519MLKEM768 -connect example.com:443

A completed handshake means both ends agreed on the hybrid group.

3. Prefer post-quantum-capable messaging for confidential conversations. Signal's PQXDH protects initial key establishment for all users; Apple's PQ3 adds ongoing rekeying on top of it [@signal-pqxdh] [@apple-pq3]. Messaging is a canonical long-lived-secret surface, and both are already deployed.

4. Do not wait for pure post-quantum cryptography.

Note: During migration, the hybrid is the move to make now. It is provably secure if either component holds [@xwing], it was vindicated when SIKE fell, and it is downgrade-safe: against a peer that does not support it, TLS simply negotiates a classical group, so a hybrid is never worse than what you already run. Pure ML-KEM is a defensible steady-state target, not a reason to delay hybrid deployment today.

5. Treat signatures and PKI as a separate, later track. Migrating your key exchange does not touch quantum forgery of signatures, and it does not need to -- that is a different threat model on a different clock. Track it separately, and do not let a signature-migration timeline slow your confidentiality migration, or the reverse.

6. Expect the large-ClientHello bug, and test before flag-day. When you enable the hybrid, some servers or middleboxes may reject the larger handshake because of the one-read() bug rather than fall back gracefully [@tldrfail]. Test your endpoints, fix the socket handling, and rely on browser-side ClientHello splitting where you can.

Key idea: You cannot un-capture the past, but you can stop feeding the harvest today. Every session you move to a hybrid before it is recorded is one loss that never gets booked. That is the entire discipline: change the deployment before capture, prioritized by how long each secret must live.

That is the whole discipline: decide by lifetime, deploy the hybrid before capture, and keep the two clocks separate. What is left are the questions people ask next -- and most of them are misconceptions worth correcting precisely.

11. Misconceptions, Precisely Corrected

No. No cryptographically-relevant quantum computer exists in 2026, and RSA-2048 is unbroken [@gidney-2025]. The risk is not present-day decryption; it is present-day *capture*. An adversary who records your ciphertext today can decrypt it only once such a machine exists, which is exactly why the loss is decided at capture time rather than at decryption time [@mosca-2018]. The threat model is documented -- NSA, CISA, NIST, and an executive order all name it explicitly [@cisa-qr] [@eo-14412] -- and the general practice of bulk interception and indefinite retention is documented independently of quantum computing [@bamford] [@bullrun]. What is *not* publicly established is a specific, attributed, ongoing nation-state program that harvests ciphertext in order to await a quantum computer. That is a rational-actor inference, not a public smoking gun, and the case for migrating does not depend on one existing. Yes -- and that sharpens the argument rather than weakening it. Because ephemeral session traffic has little value years from now, the genuine harvest-now-decrypt-later risk concentrates on data with long confidentiality lifetimes: state secrets, health and genomic records, source identities, long-term intellectual property. The nuance focuses the casualty; it does not dissolve it. No. Key-establishment migration closes the confidentiality (harvest-now-decrypt-later) window. Signature forgery is a different threat model that needs a quantum computer at attack time, so it cannot be harvested in advance; its migration runs on a separate, later clock [@eo-14412]. The two never share a single verdict. Yes. ML-KEM is the standardized name for the scheme formerly called CRYSTALS-Kyber, published as NIST FIPS 203 [@fips-203]. "ML-KEM is the new name for Kyber" [@cf-pq2024]; in a 2026 voice, use ML-KEM. The internals of the primitive -- Module-LWE, lattice sampling, decapsulation -- are the subject of this article's post-quantum-toolkit sibling. No. ML-KEM is a key-encapsulation mechanism, not a non-interactive key agreement; one side encapsulates a secret and sends a ciphertext, rather than both sides deriving a key from public values the way Diffie-Hellman does [@fips-203]. The deployed answer is therefore a hybrid *handshake*, not a drop-in "post-quantum Diffie-Hellman." During migration, prefer a hybrid. It is provably secure if either component holds [@xwing], and the SIKE break is the empirical proof: a NIST Round-4 candidate KEM fell classically in about ten minutes, and every deployment that had wrapped it in a hybrid stayed safe [@sike-break]. Pure ML-KEM-1024 is a defensible steady-state target -- the direction of U.S. national-security systems [@cnsa-2] -- but not a reason to delay hybrid deployment today.

The paradox we opened with dissolves once you see where the casualty is booked. No quantum computer can factor RSA-2048 in 2026, and yet the loss is real, present, and ongoing -- because the adversary's decisive act is capture, not decryption. Every long-lived secret sent today under a quantum-vulnerable algorithm, while a recording runs, is a casualty already entered in the ledger: collected now, read later, and past the reach of any future fix the moment it is stored.

That is the reconciliation with this series' running thesis, and it holds without an exception. The primitive's mathematics did not cause this break -- RSA-2048 is unbroken, and no cryptographically-relevant quantum computer exists. The deployment did: continuing to protect must-outlive-Q-Day data with a deprecated-but-still-live quantum-vulnerable algorithm while someone records the ciphertext. The remedy is a deployment change you can make today -- hybrid X25519 plus ML-KEM key establishment -- and its urgency is set entirely by how long your data must stay secret.

So the only question that ever mattered is the one we started with: what were you doing at capture time? If the answer is "shipping a hybrid before the recording was made," the loss was never booked. If it was "waiting for Q-Day," you were already too late. The mechanism that finishes the job -- one machine running Shor's algorithm against RSA, Diffie-Hellman, and ECC at once -- is the subject of the sibling article "How Q-Day Breaks Everything: Shor's Algorithm and the Simultaneous Fall of RSA, Diffie-Hellman, and ECC." Knowing where your own quantum-vulnerable cryptography lives, so you can change it before capture, is the subject of the crypto-agility and cryptographic-bill-of-materials sibling. Both matter. Neither un-captures a recording. Only the deployment you ship before capture ever could.

The Log Was Never the Weak Part: How Discrete-Log Cryptography Actually Breaks

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

For a well-chosen group the discrete logarithm is essentially as hard as it can be: the best generic attack is Pollard's rho at about $0.886\sqrt{\ell}$ steps, and Shoup proved no *generic* algorithm does better. So every faster classical break -- anomalous curves, MOV and Frey-Ruck pairing transfers, weak twists, invalid-curve shadow groups, Weil descent, the Number Field Sieve, Logjam's shared-prime precomputation, and small-characteristic quasi-polynomial descent -- is never a cleverer logarithm; it is a receipt for a structural property of the *group that was chosen*. Strip every such property away and only one known break remains, and it changes the machine: Shor's quantum algorithm -- "as far as is known," since the elliptic-curve discrete-log problem is still unproven to be hard.

1. The 256-Bit Paradox

Four cryptographic groups walk onto the internet. NIST P-256 and Curve25519 -- both 256 bits wide -- each advertise roughly $2^{128}$ security, and after two decades of public scrutiny neither has been broken [@safecurves]. A third 256-bit curve, differing from the first two only in a hidden arithmetic property, can be broken on a laptop in polynomial time [@smart-1999]. And a 1024-bit finite-field group -- four times the bit length of the curves -- is a realistic target for a well-funded adversary [@logjam-adrian-2015]. The operation an attacker has to invert is the same discrete logarithm in all four groups.

The variable that decided their fates was never the logarithm. It was the group.

That sentence runs against the way most of us first meet the subject. We are taught that a one-way function is hard, that a bigger key makes it harder, and that "solving the discrete log" is a single monolithic feat an attacker either can or cannot perform. This article argues the opposite, and it argues it as a claim you should not yet believe: the discrete logarithm is essentially never the weak part. The weak part is always the group -- some extra structure it carries, or the wrong group quietly substituted for the right one.

Two settings recur throughout. The first is the multiplicative group of a prime field, written $\mathbb{F}_p^*$, the home of classic finite-field Diffie-Hellman, DSA, and ElGamal. The second is the group of points on an elliptic curve over a finite field, the home of ECDH, ECDSA, and EdDSA. The plan is a guided tour of every known way the discrete log "breaks." Each stop will turn out to exploit a structural property of a chosen group rather than compute a faster logarithm, and the tour ends at the one break that survives even a flawless group: Shor's quantum algorithm.

Note: This is a structural cryptanalysis -- an argument about the mathematics of the group itself. Side-channel leaks, fault and power attacks, implementation bugs, weak random-number generators, and protocol misuse are out of scope, named only to mark the boundary. Those failures are real and often more common in practice, but they belong to the empirical sibling of this piece, "How Elliptic Curves and Diffie-Hellman Break in Real Life: PS3, CurveBall, Logjam, and Biased Nonces." When a break here has an implementation trigger, this article hands that trigger to the sibling and keeps only the group mathematics.

By the end you will be able to look at any of the ten attacks in the literature and name, in one phrase, the structural property of the group it needs -- and see that a well-chosen group simply does not have it. To understand why the group is the variable, we have to go back to the moment the discrete log became something worth attacking at all.

2. What the Discrete Log Actually Is, and Where It Lives

In November 1976, Whitfield Diffie and Martin Hellman published "New Directions in Cryptography" and handed two strangers a way to agree on a shared secret over a wiretapped line without ever having met [@diffie-hellman-1976]. Their construction is simple enough to state in a sentence, and in stating it they turned an obscure number-theoretic puzzle into the thing standing between an eavesdropper and your traffic.

Fix a cyclic group with a public generator $g$. Alice picks a secret $a$ and publishes $g^a$; Bob picks a secret $b$ and publishes $g^b$. Each raises the other's value to their own secret, so both compute $g^{ab}$ -- the shared key. An eavesdropper sees $g$, $g^a$, and $g^b$, and must find $g^{ab}$. The obvious route is to recover $a$ from $g^a$, which is exactly the discrete logarithm. Given a cyclic group generated by $g$ and an element $h = g^x$, find the exponent $x$. In the integers this is easy -- it is just division on a logarithmic scale. Inside a finite group the exponent "wraps around" unpredictably, and no efficient general method to recover $x$ is known. The security of Diffie-Hellman, DSA, ElGamal, ECDH, ECDSA, and EdDSA all rest on this one problem being hard in the group they use.

The instant the DLP became a security assumption, a very old question acquired stakes: how hard is it, actually? And the first answer was unsettling, because it showed that the difficulty had nothing to do with the size of the numbers involved.

Priority is disputed. At GCHQ, James Ellis, Clifford Cocks, and Malcolm Williamson developed classified "non-secret encryption" and a key-exchange analogue between 1969 and 1974, work declassified only in 1997 [@ellis-1997]. The public invention, and the framing of the discrete log as a security assumption, are Diffie and Hellman's.

timeline title Fifty years of attacking the discrete logarithm section The problem and its floor 1976 : Diffie-Hellman make the discrete log a security assumption 1978 : Pohlig-Hellman shatters smooth-order groups : Pollard rho sets the sqrt-time floor section The escape to curves 1985 : Miller and Koblitz move the log onto elliptic curves 1993 : MOV pairing transfer : Gordon adapts the Number Field Sieve to prime fields 1994 : Shor reduces the discrete log to quantum period-finding section Structure strikes back 1998 : Anomalous trace-one curves fall in polynomial time 2002 : Weil descent breaks special binary curves section Records and frontiers 2015 : Logjam weaponizes shared-prime precomputation 2019 : A 795-bit prime-field record : quasi-polynomial small-characteristic descent proven

The first structural lesson: Pohlig-Hellman

In January 1978, Stephen Pohlig and Martin Hellman proved something that should have set the tone for the entire field [@pohlig-hellman-1978]. Suppose the order of the group -- the number of elements -- factors into small primes, $n = p_1^{e_1} p_2^{e_2} \cdots p_r^{e_r}$. Then the discrete log does not have to be solved in the big group at all. It can be solved separately in each prime-power piece, where the numbers are tiny, and the answers glued back together with the Chinese Remainder Theorem.

The total work is on the order of $\sum_i e_i(\log n + \sqrt{p_i})$ -- dominated by the largest prime factor, not by the size of $n$.

Read that again with the thesis in mind. A group can be astronomically large and still offer no security, if its order happens to be a product of small primes. A 4096-bit group whose order is smooth falls instantly.

Security was never a property of "the log" or of the key length. It was a property of the group's order -- specifically, whether that order contains a large prime factor. The first thing anyone proved about the discrete log moved the weakness off the logarithm and onto a structural feature of the chosen group. Everything that follows is a variation on that move.

The escape that defines the rest of the article

By the mid-1980s, the multiplicative group $\mathbb{F}_p^*$ had a second problem beyond smooth orders: it admitted index calculus, a family of sub-exponential attacks we will meet in Section 6. The response, arriving independently from two directions, was not a better logarithm algorithm. It was a change of group.

In 1985, Victor Miller [@miller-1986] and, independently, Neal Koblitz [@koblitz-1987] proposed replacing $\mathbb{F}_p^*$ with the group of points on an elliptic curve over a finite field. Their motivation was explicit and structural: the multiplicative group hands index calculus something to grip, and a general elliptic curve does not, so the same security should be reachable with far smaller keys.

This is the thesis in its constructive form -- when a group is weak, do not sharpen the attack, choose a group with less structure -- and it introduces the lens we will look through for the rest of the article: the distinction between a generic group, whose elements are opaque handles you can only combine with the group operation, and a structured group, whose elements leak extra arithmetic an attacker can exploit.

Miller and Koblitz had escaped one kind of structure. The question their move raised -- and the one the next section answers -- is what an attacker can do against a group that has nothing wrong with it. If Pohlig-Hellman is defeated by a large prime order, how hard is the log then?

3. The Generic Floor: Why Square-Root Time Is the Best You Can Do

Here is a number that has barely moved in fifty years. Against a well-chosen group, the best known generic attack on the discrete log runs in about $0.886\sqrt{\ell}$ steps, where $\ell$ is the largest prime factor of the group's order. Not only is that the best anyone has found -- there is a proof you cannot do fundamentally better generically. To see why that floor exists, and why it is a floor and not a ceiling waiting to be lowered, start with the simplest attack that hits it.

Baby-step giant-step: sorting your way to the log

In 1971 Daniel Shanks described a deterministic method that trades memory for time [@shanks-1971]. To solve $h = g^x$ with $x$ below some bound $N$, precompute and store the "baby steps" $g^0, g^1, \ldots, g^{m-1}$ for $m \approx \sqrt{N}$, then take "giant steps" $h \cdot g^{-jm}$ for $j = 0, 1, 2, \ldots$ until one lands in the stored table. A match pins down $x = i + jm$. The running time is $O(\sqrt{N})$ and so is the memory -- and remarkably, this square-root cost is essentially the same one that still bounds the state of the art.

The clean "given $g$ and $h$, find $x$" statement of the DLP that every textbook now opens with is partly a later reconstruction; Shanks's 1971 paper framed the computation in the language of class numbers and genera, and the crisp cryptographic phrasing was settled in references like the Handbook of Applied Cryptography [@hac-1996].

The memory is the problem. Storing $\sqrt{\ell}$ group elements is fine for a 40-bit group and impossible for a 256-bit one. The breakthrough was getting the same square-root time with almost no memory at all.

A *generic* algorithm treats group elements as opaque tokens: it can multiply them, invert them, and test equality, but it cannot read anything from their representation -- no bits, no size, no factorization. A group is effectively *generic* for an attacker when no such extra structure is exposed. The whole thesis of this article lives in this word: the square-root floor is proven only for *generic* algorithms, and every faster attack works precisely by treating the group as *non*-generic.

Pollard's rho: a random walk that traps itself

Walk pseudo-randomly through the group with a function $f$ that also tracks how each point is built from the generator $g$ and the target $Q$, as $g^a Q^b$. Because the group is finite, the walk must eventually revisit a point, and the birthday bound makes that first self-collision appear after only about $\sqrt{\ell}$ steps. When it does, two different expressions $g^{a_1}Q^{b_1}$ and $g^{a_2}Q^{b_2}$ name the same element, which rearranges into $(a_1 - a_2) \equiv x\,(b_2 - b_1) \pmod{\ell}$ -- and the log $x$ drops out.

John Pollard published this in 1978 [@pollard-rho-1978]. Its beauty is the memory: using Floyd's or Brent's cycle-finding, you need to remember only a couple of points, so the cost is about $0.886\sqrt{\ell} = \sqrt{\pi/4},\sqrt{\ell}$ group operations at $O(1)$ space. The name comes from the shape the walk traces -- a tail that runs into a loop, like the Greek letter rho.

Two effects stack. A pseudo-random walk through a set of $\ell$ elements is expected to run into its own past after on the order of $\sqrt{\ell}$ steps, and working that expected value through the birthday integral gives $\sqrt{\pi/2}\,\sqrt{\ell} \approx 1.2533\sqrt{\ell}$ -- the pure birthday constant. On an elliptic curve a second, curve-specific discount then applies: because $P$ and $-P$ share an $x$-coordinate, the walk can run on equivalence classes under point negation, a $\sqrt{2}$ speedup that pulls the constant down to $\sqrt{\pi/4}\,\sqrt{\ell} \approx 0.886\sqrt{\ell}$ -- the figure SafeCurves quotes for the elliptic-curve discrete log [@safecurves]. Half a century of refinement -- distinguished points, that negation map, better step functions -- has improved the constant but never the exponent. The square root is the wall. flowchart TD A[Start at a known element, tracking exponents a and b] --> B[Apply the pseudo-random step f] B --> C[Land on the next element of the walk] C --> D{"Element seen before?"} D -->|No, keep walking| B D -->|Yes, collision| E[Two products in g and Q name the same element] E --> F[The collision becomes a linear equation in the unknown x] F --> G[Read off the discrete log x]

You can watch the birthday collision happen on a toy group. The subgroup below has prime order $\ell = 509$, so $\sqrt{\ell} \approx 23$; the walk finds its self-collision in a few dozen steps and reads off the secret exponent.

Group: the order-509 subgroup of the integers mod 1019. Q = g^x; recover x.

p, l, g = 1019, 509, 4 # p = 2*l + 1 (safe prime); g has prime order l x_secret = 137 # the exponent the attacker does not know Q = pow(g, x_secret, p)

def step(X, a, b): # A three-way pseudo-random walk that also tracks X = g^a * Q^b (mod p). r = X % 3 if r == 0: return (X * Q) % p, a, (b + 1) % l elif r == 1: return (X * X) % p, (2 * a) % l, (2 * b) % l else: return (X * g) % p, (a + 1) % l, b

seen = {} # a table only to make the collision visible X, a, b = g, 1, 0 # start at X = g^1 * Q^0 for i in range(1, l + 5): if X in seen: a2, b2 = seen[X] den = (b - b2) % l x = ((a2 - a) * pow(den, -1, l)) % l # solve the collision for x print("collision at step", i, " (sqrt(l) is about", round(l ** 0.5), ")") print("recovered x =", x, " true x =", x_secret, " match:", x == x_secret) break seen[X] = (a, b) X, a, b = step(X, a, b) `}

A production attacker drops the table and uses constant memory, restarting on the rare degenerate collision where the bookkeeping cancels. What matters is the exponent: the cost scales as the square root of the subgroup order, and nothing about the group's size changes that scaling.

A close cousin, Pollard's kangaroo (or lambda) method, solves the DLP when $x$ is known to lie in a short interval, at cost proportional to the square root of the interval width rather than of $\ell$.

Parallelism does not change the exponent

In 1999, Paul van Oorschot and Michael Wiener turned rho into a production weapon [@vanoorschot-wiener-1999]. Many machines walk independently and report only distinguished points -- points with a rare, easy-to-test property such as a run of leading zero bits. A collision between any two chains is caught by a central server, and the speedup is near-linear: $m$ machines finish in about $\sqrt{\ell}/m$ wall-clock time. Parallelism buys you a smaller constant and a division by your budget. It does not touch the square root.

The floor is a theorem, not a lack of imagination

Why be sure no cleverer generic walk exists? Because in 1997 Victor Shoup proved a matching lower bound: any algorithm that uses only the group operation must make $\Omega(\sqrt{\ell})$ queries to solve the discrete log, where $\ell$ is the largest prime factor of the order [@shoup-1997]. Pollard's upper bound and Shoup's lower bound close on the same exponent.

Key idea: On a group with no exploitable structure, the best attack anyone knows -- Pollard rho at about $0.886\sqrt{\ell}$ steps -- is provably the best attack anyone generically can know, because Shoup's $\Omega(\sqrt{\ell})$ lower bound meets it. The two bounds coincide at $\Theta(\sqrt{\ell})$. The hardness is not a property of "the logarithm." It is fixed entirely by one number: the largest prime factor of the group's order. The variable has moved from the operation to the group.

That is why "security level" is defined as the rho cost. A 256-bit curve is a $2^{128}$ target, not a $2^{256}$ one, because rho gets a square-root discount that no key-size increase can revoke.

Curve (256-bit unless noted)	Pollard rho cost	What it means
Curve25519	$2^{125.8}$	about 128-bit security, unbroken [@safecurves]
NIST P-256, secp256k1	$2^{127.8}$	about 128-bit security, unbroken [@safecurves]
brainpoolP256	$2^{127.5}$	about 128-bit security, unbroken [@safecurves]
NIST P-384 (384-bit)	$2^{191.8}$	about 192-bit security [@safecurves]
SafeCurves "anomalous" curve (about 204-bit)	$2^{101.6}$ by size alone	a red herring -- its real break is polynomial-time SSSA (Section 4), off the rho scale entirely [@safecurves]

State-of-the-art attacks on the elliptic-curve discrete log are still within a factor of two of Shanks's 1971 method. Half a century of cryptanalysis against a clean curve has bought a factor of two.

The records bear this out. The largest discrete log ever solved on a generic, randomly chosen prime-field elliptic curve is a 112-bit curve, secp112r1, cracked in 2009 by a parallel rho computation [@bos-112bit-2009]. The only solves that have reached higher leaned on exploitable curve structure rather than a stronger generic attack, which is the thesis in miniature. Set that against the finite-field records we are about to meet, where the numbers run past 795 bits, and the gap tells the whole story: against a clean curve there is no better attack than the square-root walk, so records crawl.

This is the wall every attacker hits -- unless the group hands them a crack. So where are the cracks? They start with the curve you choose.

4. The Curve as the Weak Part, I: Special Curves That Transfer the Log Away

The move to elliptic curves was supposed to strip out structure. But the first generation of curve choices smuggled it back in, and the way each weakness works is the quiet engine of this whole article. None of them computes a faster logarithm. Each one moves the logarithm out of the curve and into a different group where the log was never hard to begin with.

flowchart TD A[ECDLP on the chosen curve E] --> B{"What structure did the curve leak?"} B -->|Trace equals 1, so the point count equals p| C[Additive transfer, the SSSA map] B -->|Small embedding degree k| D[Pairing transfer, MOV and Frey-Ruck] C --> E[Log now lives in the additive group of F_p, which has no hardness] D --> F[Log now lives in a finite field where index calculus finishes it] E --> G[Recovered in polynomial time] F --> H[Recovered in sub-exponential time]

Anomalous curves: a trapdoor hiding in the point count

Every elliptic curve over a prime field $\mathbb{F}_p$ has a point count governed by a single integer. Hasse's theorem says $#E(\mathbb{F}_p) = p + 1 - t$, where $t$ is the trace of Frobenius and $|t| \le 2\sqrt{p}$. That one number, $t$, decides whether the curve is world-class or worthless.

The trace of Frobenius $t$ measures how the number of points on $E$ over $\mathbb{F}_p$ deviates from $p + 1$, via $\#E(\mathbb{F}_p) = p + 1 - t$. A curve is *anomalous* when $t = 1$, so that $\#E(\mathbb{F}_p) = p$ exactly -- the group of points has the same order as the additive group of the field it sits over. That coincidence is fatal.

When the group order equals $p$, a map exists -- built from the $p$-adic (formal) logarithm and expressible through Fermat quotients -- that sends the elliptic-curve discrete log straight into $(\mathbb{F}_p, +)$, the additive group of the field. And addition has no discrete-log hardness at all: recovering $x$ from $x \cdot a$ in $(\mathbb{F}_p, +)$ is one modular division. The transfer runs in polynomial time.

This was worked out in 1998 and 1999 by Nigel Smart [@smart-1999], and independently by Igor Semaev [@semaev-1998] and by Takakazu Satoh and Kiyomichi Araki [@satoh-araki-1998]; the attack is often abbreviated SSSA after the four names.

Note: Size buys nothing here. A 256-bit anomalous curve -- indistinguishable at a glance from a strong one, same field size, same key length -- falls in polynomial time, essentially instantly, while its 256-bit clean neighbor stands at about $2^{125.8}$ operations [@safecurves]. The only thing that changed is the trace. The defense is one check: confirm that $#E(\mathbb{F}_p) \neq p$.

There is a subtlety worth flagging so you can spot a common mis-citation: this 1998-99 break is the additive, formal-logarithm transfer. It is not Semaev's later 2004 work on summation polynomials [@semaev-2004], which is a different line of attack we will meet in Section 10. Trace one is a coincidence in the point count; summation polynomials are an index-calculus program. Conflating them is the classic error in retellings of this attack.

Low embedding degree: a bridge into a weaker field

The second transfer needs a different structural flaw. Every prime-order subgroup of a curve has an embedding degree, and if it is small, a bridge opens into a finite field where the log is soft.

For a subgroup of prime order $\ell$ on a curve over $\mathbb{F}_q$, the embedding degree $k$ is the least positive integer such that $\ell \mid q^k - 1$. Equivalently, $k$ is the smallest extension field $\mathbb{F}_{q^k}$ whose multiplicative group contains a copy of the subgroup. When $k$ is small, that copy is reachable, and the finite-field discrete log there is sub-exponential rather than square-root.

The bridge itself is a bilinear pairing.

A pairing is a map $e$ that takes two curve points to an element of $\mathbb{F}_{q^k}^*$ and is *bilinear*: $e(aP, bQ) = e(P, Q)^{ab}$. Bilinearity is what turns a curve log into a field log, but there is a subtlety most retellings get wrong. The *Weil* pairing that MOV uses is *alternating*: $e(P, P) = 1$ for every $P$, so a naive $e(P, P)^x$ is just $1$ and carries no information. MOV instead pairs $Q = xP$ with a *second, linearly independent* order-$\ell$ point $R \notin \langle P \rangle$, giving $e(Q, R) = e(P, R)^x$ in $\mathbb{F}_{q^k}^*$ -- an ordinary finite-field discrete log in the nontrivial root of unity $e(P, R)$. On the classic supersingular victims that independent $R$ arrives for free from a *distortion map* $\psi$, an endomorphism that moves $P$ off its own subgroup so that $R = \psi(P)$ works [@verheul-2004] [@galbraith-2012]. Frey and Ruck use the *Tate* pairing, which is not alternating and does admit a nontrivial self-pairing, so there the bare $e(P, P)^x$ form is the legitimate one.

Menezes, Okamoto, and Vanstone published the Weil-pairing reduction in 1993 [@mov-1993]; Frey and Ruck gave the companion Tate-pairing version in 1994 [@frey-ruck-1994]. The classic victims are supersingular curves, which have embedding degree $k \le 6$. Once transferred into $\mathbb{F}_{q^k}^*$ with small $k$, the log falls to the sub-exponential Number Field Sieve of Section 6.

The escape to a curve is undone by a curve that quietly kept a low-degree door into a field. The defense, again, is a property of the curve you choose: demand a large embedding degree, which the pairing textbook literature treats as a standard selection criterion [@hankerson-mv-2004].

There is a twist worth savoring. The very property MOV and Frey-Ruck exploit -- a workable pairing into a small field -- became the foundation of an entire branch of cryptography. Identity-based encryption, BLS signatures, and much of what makes modern threshold and aggregate signatures possible are *built on* pairing-friendly curves with deliberately small embedding degree. The supersingular curves that MOV destroyed for plain ECDLP found a second career as the substrate of constructive pairing-based cryptography. The same distortion maps that hand MOV its independent second point are what make Antoine Joux's one-round tripartite Diffie-Hellman work -- a three-party key agreement in a single round, and the first purpose-built pairing protocol [@joux-tripartite-2000]. A structural feature is only a weakness relative to what you are trying to do with it.

Step back and notice what both attacks have in common with each other and with Pohlig-Hellman before them.

Note: Neither the anomalous break nor the pairing break computes a faster logarithm. Each one transfers the log: the anomalous curve's log is mapped into $(\mathbb{F}p, +)$, where addition is trivial; the low-embedding-degree curve's log is mapped into $\mathbb{F}{q^k}^*$, where index calculus finishes it. The attacker never out-computes the logarithm on the curve. They relocate it to a group that was never hard. Structure, not speed, is the entire game.

Trace one and small embedding degree are properties an attacker can only hope the designer chose badly. The next family of breaks is nastier, because they can be triggered by the attacker's own inputs, or by a field chosen one level up from the curve.

5. The Curve as the Weak Part, II: Twists, Shadow Groups, and Descent

The cleanest structural weakness of all does not live in the curve you publish. It lives in the curve's twin.

Twist attacks: falling off the curve onto its shadow

Fast elliptic-curve implementations often work with $x$-coordinates only -- the Montgomery ladder, used by X25519, never computes a $y$-coordinate at all. That is a real speed and safety win, but it introduces a subtlety: an $x$ value the attacker sends might not correspond to any point on $E$.

Over $\mathbb{F}_p$, a curve $E$ has a *quadratic twist* $E'$ -- a sibling curve that becomes isomorphic to $E$ only over the larger field $\mathbb{F}_{p^2}$. The key fact for $x$-only arithmetic is that every $x$ in $\mathbb{F}_p$ is the $x$-coordinate of a point on *either* $E$ *or* $E'$. So an attacker-supplied $x$ that is not on $E$ is silently processed as a point on the twist. A curve is *twist-secure* when both $E$ and $E'$ have near-prime order.

Here is the attack. If the twist $E'$ has a smooth order -- a product of small primes -- then a scalar multiplication the victim performs on that twist leaks the secret modulo each small prime, exactly the Pohlig-Hellman shattering from Section 2, now triggered by an attacker's chosen input rather than by the designer's bad luck. Collect enough small residues and the Chinese Remainder Theorem reassembles the key.

The weakness is real, and again it is a property of the group the designer chose: it is defeated by requiring the twist's order, not just the curve's, to be near-prime. Curve25519 was designed to be twist-secure from the start [@bernstein-curve25519-2006], and SafeCurves treats twist security as a first-class criterion [@safecurves].

Invalid-curve shadow groups: arithmetic that forgets its own curve

The next mechanism is sharper still, and it exposes something almost philosophical about how curve arithmetic works.

For a short-Weierstrass curve $y^2 = x^3 + ax + b$, the standard point-addition formulas use $a$ but never use $b$. So if you feed the arithmetic a point that satisfies $y^2 = x^3 + ax + c$ for the *wrong* constant $c$, every formula still returns a well-defined answer -- computed as if on a different, weaker "shadow" curve. If that shadow curve has smooth order, the secret is confined to small subgroups, just as in a twist attack.

Biehl, Meyer, and Muller analyzed this in 2000 [@biehl-meyer-muller-2000], and SafeCurves states the load-bearing fact plainly: the standard formulas do not involve the constant coefficient $b$ [@safecurves]. What makes this a "shadow group" rather than a single weak curve is that the attacker gets to choose $c$, and so gets a whole family of weaker curves to hunt through for one with a smooth order.

Do not confuse invalid-curve attacks with small-subgroup confinement in the Lim-Lee sense. The former uses many different off-curve shadow curves reached by varying $c$; the latter feeds a single low-order element inside one group. Both end in Pohlig-Hellman, but the structural handle is different.

Now, the honest boundary. The mechanism above is pure group arithmetic -- a genuine structural property of the short-Weierstrass addition law -- and that is what belongs here. What makes it fire in a real system is a missing check: the software accepted a point without verifying it was on the intended curve. That trigger is an implementation gap, not curve mathematics, and this article deliberately stops at the mathematics.

This piece keeps a strict contract: it analyzes only the mathematics of the group. The moment a break depends on a missing input validation, a leaked nonce, a fault injected into a signature, a downgrade negotiated on the wire, or a manipulated parameter, it crosses into implementation and protocol territory. Those are the domain of the empirical sibling, "How Elliptic Curves and Diffie-Hellman Break in Real Life: PS3, CurveBall, Logjam, and Biased Nonces," which covers the PlayStation 3 repeated-nonce disaster, the CurveBall certificate-validation flaw, the Logjam downgrade handshake, and the biased-nonce lattice attacks. When you finish here knowing *which group properties* are dangerous, that article shows *how deployments trip over them*. The invalid-curve trigger -- "the code forgot to validate the point" -- is handed there in full.

Weil descent: a weakness chosen one level up, in the field

The last structural break in this pair does not need a bad curve so much as a badly chosen field. Some curves live over binary extension fields $\mathbb{F}_{2^n}$. When the extension degree $n$ is composite, a technique called Weil restriction can re-express the curve's group as points on a higher-genus curve over a smaller subfield -- and on that higher-genus object, index calculus applies and beats the generic square-root floor.

Gaudry, Hess, and Smart formalized this in 2002 [@ghs-2002], and the title of their paper is itself a summary of this whole section: "Constructive and destructive facets of Weil descent on elliptic curves." The precondition is structural and specific: a composite-degree binary extension field. The defense is equally specific: use prime fields, or at worst prime-degree extensions, so there is no subfield to descend into.

Every curve break in these two sections has needed a particular structural precondition -- trace one, small embedding degree, a smooth twist, $b$-independent arithmetic, a composite extension field. Not one has been a faster logarithm. Now cross the aisle to the group the whole field was fleeing in 1985. There, the structure is not an accident of a bad curve. It is built into the group itself.

6. The Finite-Field Side: When the Group Itself Has Structure

An anomalous curve is a bad choice -- pick a different curve and the weakness is gone. The multiplicative group $\mathbb{F}_p^*$ is different. It is not a bad choice; it is inherently structured. Its elements are ordinary integers, and integers can be multiplied and factored. That single property -- the one thing an elliptic-curve group pointedly does not have -- is exactly what the fastest classical attack needs.

Index calculus: turning multiplication into linear algebra

Fix a *factor base* of small primes. An element is *smooth* if it factors completely over that base. Index calculus hunts for powers $g^k$ that are smooth; each one factors as a product of factor-base primes, and taking logs turns that product into a *linear equation* relating the unknown logs of the base primes. Collect more smooth relations than there are base primes, solve the linear system once, and you know the log of every prime in the base. To finish a specific target $h$, nudge it by random powers of $g$ until $h \cdot g^k$ is smooth, and read the answer off the precomputed base logs.

Notice what index calculus consumes: the ability to factor group elements into small pieces. In $\mathbb{F}_p^*$ that ability is free, because the elements are integers. On an elliptic curve there is no such thing as a "small" point, no factor base, no notion of a smooth point at all. The attack has nothing to grip. That absence is not a minor detail -- it is the entire reason elliptic-curve cryptography exists.

The Number Field Sieve, pointed at the logarithm

The mature form of this idea is the Number Field Sieve. Built for factoring by Lenstra, Lenstra, Manasse, and Pollard in 1990 [@nfs-llmp-1990], it was adapted to the discrete log in a prime field by Daniel Gordon in 1993 [@gordon-1993].

Its pipeline has four stages: choose number fields tuned to $p$ (polynomial selection), sieve for smooth relations (relation collection), solve the resulting sparse linear system modulo the group order (linear algebra), and then peel off each individual target log (descent). The first three stages depend only on the prime $p$ -- a fact that looks academic here and becomes a weapon in the next section.

Cryptographers measure these costs with $L_p[\alpha, c] = \exp\!\big((c + o(1))(\ln p)^{\alpha}(\ln\ln p)^{1-\alpha}\big)$. The exponent $\alpha$ interpolates between two worlds: $\alpha = 1$ is fully exponential (Pollard rho on a $b$-bit group costs about $2^{b/2}$, an $L_p[1, 1/2]$ cost), and $\alpha = 0$ is polynomial. The Number Field Sieve sits at $\alpha = 1/3$, deep in *sub-exponential* territory -- vastly faster than the generic square root, and the same complexity class as integer factoring.

Gordon's 1993 algorithm put the finite-field discrete log in the sub-exponential $L_p[1/3]$ class, with heuristic constant $3^{2/3} \approx 2.08$ [@gordon-1993]; later refinements sharpened that constant to the modern $(64/9)^{1/3} \approx 1.923$. To feel what the difference between $\alpha = 1/2$ and $\alpha = 1/3$ does to real key sizes, run the estimator: the finite-field cost grows like a cube root of the bit length in the exponent, while the elliptic-curve cost grows linearly. That is why the two settings need such different key sizes for the same security.

{` import math

def nfs_bits(bits): # Leading-term model of the NFS-DL cost L_p[1/3, (64/9)^(1/3)] for a 'bits'-bit prime. lnp = bits * math.log(2) c = (64 / 9) ** (1 / 3) # about 1.923 return c * lnp ** (1/3) * math.log(lnp) ** (2/3) / math.log(2)

def rho_bits(order_bits): return order_bits / 2 # Pollard rho: half the bit length

print("Finite-field DH (cost grows like a cube root in the exponent):") for b in [512, 1024, 2048, 3072]: print(f" {b:>4}-bit prime ~ 2^{nfs_bits(b):5.1f}") print("Elliptic curve (cost grows linearly):") for m in [160, 224, 256]: print(f" {m:>4}-bit curve ~ 2^{rho_bits(m):5.1f}")

The leading term runs a little high; calibrated against real records, standard practice reads 1024-bit as roughly 80-bit and 3072-bit as roughly 128-bit security.

The scaling is the point. A clean 256-bit curve and a 3072-bit prime deliver comparable security -- the curve does it with an eighth of the key length -- precisely because the curve denies the sieve its factor base. This is the thesis at its sharpest: the same discrete logarithm, but a group whose structure leaks drops the attack from square-root time all the way to $L_p[1/3]$.

Same discrete log. On a generic curve, the largest ever solved is 112 bits and the records crawl. In a prime field, the record is 795 bits and climbing. The logarithm did not change -- the group did.

The records make the gap concrete. The current prime-field discrete-log record is 795 bits (240 decimal digits), set in 2019 by Boudot, Gaudry, Guillevic, Heninger, Thome, and Zimmermann, with the discrete-log computation costing roughly 3,100 core-years [@boudot-795bit-2020]; the previous record was 768 bits [@kleinjung-768bit-2017]. Against the 112-bit generic-curve ceiling of Section 3, the sieve's structural advantage is not subtle. The multiplicative group hands the attacker a factor base; the curve hands them nothing. The results corroborate the standard textbook accounting of index calculus and its consequences for finite-field sizing [@hac-1996].

A sub-exponential attack still sounds expensive -- years of computation for a single prime. So why is a 1024-bit Diffie-Hellman group a practical target rather than a merely theoretical one? Because the expensive part only has to be done once.

7. Logjam: Precomputation as a Structural Property

The most misunderstood word in forward secrecy is "fresh." A new ephemeral key on every connection feels like it should defeat any precomputed attack -- surely a one-time secret cannot be broken by work done in advance. Against a shared prime, that intuition is simply wrong, and seeing why is the sharpest lesson the finite-field side has to teach.

Recall the four stages of the Number Field Sieve. Three of them -- polynomial selection, relation collection, and the enormous linear-algebra solve -- depend only on the prime $p$. They produce the discrete logs of the entire factor base, and that output is reusable for every discrete log computed in that same prime field. Only the final descent step depends on the particular target. The Logjam researchers put it in one line on the project page: the first step of the number field sieve is dependent only on this prime [@logjam-adrian-2015].

flowchart TD subgraph PC["Precomputation, depends only on the prime p"] A[Polynomial selection] --> B[Relation collection by sieving] B --> C[Linear algebra, logs of the whole factor base] end C --> D[Per-target descent, one quick step per connection] D --> E[Discrete log of this specific ephemeral key] F[Every connection that shares p reuses the same precomputation] -.-> D

So a fresh ephemeral does not help if the prime behind it is shared and undersized. The attacker pays the sieve cost once, for the prime, and then every "fresh" handshake using that prime falls in the cheap descent step. Freshness protects the key; it does nothing for a shared group.

Note: Precomputation is not a shortcut around the math -- it is the structure being exploited. The weakness Logjam turns into a live threat is the amortized cost of a shared, undersized prime, spread across millions of connections. It is not a faster logarithm and not a smaller key in isolation. It is the fact that everyone reused the same group.

The blast radius came from exactly that reuse. A handful of 1024-bit primes were hard-coded into standards and shipped in software everywhere. Adrian and colleagues measured the exposure [@logjam-adrian-2015]. The immediate Logjam downgrade, forcing connections to 512-bit export-grade Diffie-Hellman, initially left 8.4% of the Top 1 Million HTTPS domains vulnerable.

Looking forward, a single precomputation against one common 1024-bit prime would let a passive eavesdropper read roughly 18% of the Top 1 Million HTTPS domains; precomputing a second common 1024-bit prime would reach about 66% of VPNs and 26% of SSH servers. A nation-state budget for one very large computation buys passive decryption of a striking fraction of the internet, all because the primes were shared.

Note: The lesson people take away from Logjam is usually "use bigger primes," and that is half right. The deeper point is that a 1024-bit prime is dangerous mainly because it is shared and precomputed, not merely because it is 1024 bits. A unique, per-organization 2048-bit or larger prime denies the attacker the amortization that makes the sieve economical at internet scale. Shared-and-precomputed versus unique is the real axis; size is secondary [@logjam-adrian-2015].

There is a further twist this article names only to hand off: a prime can be maliciously constructed so that a hidden special-number-field-sieve structure makes it far weaker than it looks, a trapdoor invisible to anyone who did not build it. That, along with the wire-level mechanics of how a downgrade is actually negotiated, is deployment and protocol territory -- the empirical sibling's ground, not this article's.

Logjam attacks a field whose prime was too small and, above all, shared. But there is a family of fields where the sieve does not merely amortize -- it changes complexity class entirely, from sub-exponential to almost polynomial. The only question is which fields, and the answer is, once again, a structural property someone chose.

8. Small Characteristic: The Quasi-Polynomial Frontier

For one specific family of fields, the discrete log came close to collapsing -- and the story teaches the same lesson one more time, in its most dramatic form: the characteristic you choose is a structural gift to the attacker.

Finite fields come in two flavors that matter here. Prime fields $\mathbb{F}p$ have large characteristic $p$. Extension fields like $\mathbb{F}{2^n}$ and $\mathbb{F}_{3^n}$ have small, fixed characteristic (2 or 3) and a large extension degree $n$. For decades both were treated as roughly comparable homes for the discrete log. Then, in the span of a few years, the small-characteristic case fell apart.

In 2013, Antoine Joux broke the long-standing $L[1/3]$ barrier for small-characteristic fields with a new index-calculus algorithm of complexity $L[1/4 + o(1)]$, published at Selected Areas in Cryptography [@joux-2013-l14]. That was the crack in the dam. In 2014, Barbulescu, Gaudry, Joux, and Thome went much further, giving a heuristic quasi-polynomial algorithm -- cost $n^{O(\log n)}$ -- for the discrete log in finite fields of small characteristic [@bgjt-2014]. Quasi-polynomial is not merely faster than sub-exponential; it is a different universe of growth, far below $L[1/3]$.

Then in 2019, Kleinjung and Wesolowski removed the heuristics, proving that the discrete log in a fixed-characteristic field can be solved in expected time $(pn)^{2\log_2(n) + O(1)}$ -- a genuine theorem, not a conjecture backed by experiments [@kleinjung-wesolowski-2019].

Why does small characteristic collapse when a prime field does not? The whole descent turns on one structural gift. In a field like $\mathbb{F}_{2^n}$ every element is a low-degree polynomial over a tiny base field, and the Frobenius map $x \mapsto x^p$ acts linearly on that representation, because $(a + b)^p = a^p + b^p$ in characteristic $p$. Those two facts hand the attacker a cheap, self-replenishing supply of low-degree relations: the algorithm presents the field through a low-degree identity linking an element to its Frobenius image, so a single relation spawns a whole orbit of them essentially for free.

The attack then descends on degree. It rewrites the logarithm of a degree-$d$ target as a combination of logarithms of strictly lower-degree elements, recurses ($d \to d/2 \to \cdots$), and bottoms out at degree-one elements whose logs are read off directly. Because each step roughly halves the degree while spawning only quasi-polynomially many sub-problems, the descent tree has depth about $\log d$ and terminates in $n^{O(\log n)}$ time -- that logarithmic recursion depth is exactly why the exponent is "quasi-," not fully, polynomial.

A prime field $\mathbb{F}_p^*$ offers none of this. Its elements are integers modulo $p$, with no subfield tower, no element degree to shrink, and no small-characteristic Frobenius to make relations cheap. The descent has nothing to grip, which is precisely why the Number Field Sieve at $L_p[1/3]$ stays the best attack there.

The practical consequence was immediate: this line of work retired small-characteristic pairing choices, including the supersingular binary curves once proposed for pairing-based cryptography, whose security rested on a small-characteristic field discrete log. The field that was supposed to be the hard part evaporated.

Note: The quasi-polynomial result applies to small, fixed characteristic only: $\mathbb{F}{2^n}$, $\mathbb{F}{3^n}$, and their relatives. It does not extend to prime fields $\mathbb{F}_p$, where the Number Field Sieve at $L_p[1/3]$ remains the best known attack. Dropping the words "small characteristic" would produce a dangerous falsehood -- that prime-field Diffie-Hellman is quasi-polynomially broken. It is not. Finite-field DH over a properly sized, unique prime is still standing; only the small-characteristic cousins collapsed [@kleinjung-wesolowski-2019].

The calibration is almost comical in scale. The record discrete log in a fixed-characteristic field now stands at $\mathrm{GF}(2^{30750})$, computed in 2019 [@disclog-records-wiki]. That field is roughly thirty-nine times larger in bit length than the 795-bit prime-field record from the same era. Same "discrete logarithm"; the characteristic of the chosen field decides whether the records sit near 800 bits or sail past 30,000.

This reinforced a standards trend already under way. NIST SP 800-186 deprecates the binary and Koblitz curves defined over small-characteristic fields, and FIPS 186-5 removes them from the approved list entirely [@nist-sp800-186]. The precision matters: deprecation and removal are two distinct regulatory steps, and the small-characteristic results are part of why both happened.

Eight sections, eight breaks, and one relentless pattern: every classical break so far -- Pohlig-Hellman, the anomalous transfer, MOV and Frey-Ruck, twists, invalid-curve shadows, Weil descent, the Number Field Sieve, and now small-characteristic descent -- needs a specific structural property of the chosen group. But a pattern is only convincing if you can see all of it at once. Lay every attack on a single table, and the thesis stops being a claim you have to trust and becomes something you can read straight off a column.

9. A Map of Where the Weakness Lives

One table, read down one column, is the whole argument. Here is every attack in this article, each with the structural property it requires, the easy group it reduces the log to, its cost, and the one question that matters -- does a well-chosen group have that property?

Attack	Group property it needs	Reduces the log to	Complexity	Clean group has it?
Pollard rho [@pollard-rho-1978]	none (generic)	nothing; it is the floor	$\approx 0.886\sqrt{\ell}$	the baseline
Pohlig-Hellman [@pohlig-hellman-1978]	smooth group order	small subgroups plus CRT	$\sum_i e_i(\log n + \sqrt{p_i})$	No: large prime order
Anomalous / SSSA [@smart-1999]	trace $t = 1$, so $#E = p$	addition in $(\mathbb{F}_p, +)$	polynomial	No: require $#E \neq p$
MOV / Frey-Ruck [@mov-1993]	small embedding degree $k$	DLP in $\mathbb{F}_{q^k}^*$	sub-exponential	No: large $k$
Twist confinement [@safecurves]	smooth twist plus x-only ladder	small subgroups on the twist	small-subgroup cost	No: twist-secure
Invalid-curve shadow [@biehl-meyer-muller-2000]	$b$-independent arithmetic plus weak shadow	small subgroups on a shadow curve	small-subgroup cost	No: twist-secure and validated
Weil descent / GHS [@ghs-2002]	composite-degree binary field	index calculus on a higher-genus curve	sub-exponential	No: prime field
NFS-DL [@gordon-1993]	a factor base (multiplicative smoothness)	linear algebra on smooth relations	$L_p[1/3,, 1.923]$	No: a curve has no factor base
Small-char quasi-poly [@kleinjung-wesolowski-2019]	small, fixed characteristic	function-field descent	quasi-polynomial	No: prime field
Shor [@shor-1997]	none (changes the machine)	quantum period-finding	polynomial in $\log \ell$	Yes, but needs a quantum computer

Key idea: Read the "group property it needs" column from top to bottom. Every classical attack that beats square-root time names a specific structural precondition -- a smooth order, trace one, low embedding degree, a smooth twist, $b$-independent arithmetic, a composite extension field, a factor base, small characteristic. The only two rows needing no structure are Pollard rho, which is the square-root floor, and Shor, which leaves the classical world entirely. Not one classical row is a faster generic logarithm. That is the thesis, rendered as a table.

The same pattern shows up in what a working engineer actually chooses between. Line up the deployed groups and the story is not "big keys versus small keys" -- it is "which structural weakness is present."

Group	Advertised security	Public-key size	Best known classical attack	Status
FFDH-1024 (shared prime)	about 80-bit, broken in practice	1024-bit	NFS-DL plus shared-prime precomputation [@logjam-adrian-2015]	Deprecated, nation-state target
FFDH-2048 / 3072 (shared or unique)	about 112 / 128-bit	2048 / 3072-bit	NFS-DL, but precomputation is infeasible at this size	Acceptable if unavoidable
NIST P-256	about 128-bit ($2^{127.8}$ rho)	256-bit	Pollard rho, generic [@safecurves]	Active, FIPS
Curve25519 / X25519	about 128-bit ($2^{125.8}$ rho)	256-bit	Pollard rho, generic [@safecurves]	Active, twist-secure and rigid

The two 256-bit curves and the 3072-bit prime all deliver about 128-bit security -- the curves with an eighth of the key length -- because a clean curve denies the sieve its factor base. And the two finite-field rows differ not by size alone but by sharing: the 1024-bit row is a target because its prime is common and precomputed, not merely because it is 1024 bits.

The table has one uncomfortable empty space. Every row is a break that needs structure, and a clean group has none of those structures. But is there a proof that a structure-free group is actually safe -- or have we simply never found the crack? To answer honestly, we have to admit what the entire edifice rests on.

10. Theoretical Limits: Is the Log Itself Ever the Weak Part?

Here is the admission the whole subject rests on, and it is more unsettling than most textbooks let on: nobody has proved the discrete log is hard. Not for $\mathbb{F}_p^*$, not for a clean elliptic curve, not for any group that carries real traffic. The security of a large fraction of the internet rests on a problem no one can prove is difficult.

The only proven wall is Shoup's $\Omega(\sqrt{\ell})$ lower bound from Section 3 [@shoup-1997] -- and its scope is precisely the catch. It holds in the generic-group model, where the algorithm may not read anything from the encoding of group elements. It is a statement about structure-blind algorithms, not about the discrete log as such.

This is exactly why index calculus is not a paradox. The Number Field Sieve beats Shoup's $\sqrt{\ell}$ floor for $\mathbb{F}_p^$ not because the proof is wrong but because $\mathbb{F}_p^$ is not a generic group: its elements are integers, the algorithm reads their factorizations, and the generic model's central assumption simply does not apply. Every faster attack in this article is another group that leaves the generic model through some door of its own. The matching bound of Section 3 is real, and it is real only inside a model that structured groups escape.

The gap has two values, and keeping them straight is the difference between understanding this subject and sloganeering about it. *In the generic-group model* the question is CLOSED: Pollard rho's $O(\sqrt{\ell})$ upper bound meets Shoup's $\Omega(\sqrt{\ell})$ lower bound at $\Theta(\sqrt{\ell})$, a rare matching pair. *Unconditionally* it is WIDE OPEN: there is no proof the discrete log is hard at all. The space between the generic wall and reality is exactly what index calculus and the curve transfers exploit. And there is a structural reason a hardness proof is out of reach: the DLP lies in $\mathrm{NP} \cap \mathrm{coNP}$ -- given the factorization of the group order, both a claimed logarithm and its absence are efficiently checkable -- so it is *not expected* to be NP-complete, since an NP-complete problem in $\mathrm{NP} \cap \mathrm{coNP}$ would collapse $\mathrm{NP} = \mathrm{coNP}$ [@galbraith-2012] [@hac-1996]. Proving the discrete log hard would be a complexity-theory landmark far beyond anything currently in reach. That is why "only Shor breaks a clean group" must always be read "as far as is known."

The sharpest open question sits one level down, and it is the one that keeps elliptic-curve cryptographers honest: does a sub-exponential, index-calculus-style algorithm exist for the ECDLP over a prime field? If it did, it would do to elliptic curves what the Number Field Sieve did to finite-field Diffie-Hellman -- collapse the square-root advantage that justifies 256-bit keys.

This is the correct home for Semaev's summation polynomials and the related Gröbner-basis point-decomposition program, from 2004 onward [@semaev-2004] -- a genuine attempt to build an ECDLP index calculus. It must not be confused with the 1998-99 anomalous-curve transfer of Section 4, which is a different mechanism entirely. Over prime fields the summation-polynomial approach remains exponential: it is the live frontier, not a solved attack.

So, classically and as far as anyone knows, a clean group leaves the square-root floor standing. There is no known sub-exponential attack on a well-chosen prime-field curve, and the conjecture that none exists is exactly that -- a conjecture, the working hypothesis behind every ECC key-size recommendation.

Even the improvements that do exist stay on their side of the line. The extended Tower Number Field Sieve of Kim and Barbulescu sharpens the constants for medium- and non-prime-characteristic fields, but it does not move the $1/3$ exponent for prime fields [@kim-barbulescu-2016]. Prime-field discrete logs have been stuck at $L_p[1/3]$ since Gordon in 1993.

If the log's classical hardness is unproven yet unbroken on a clean group, then the only known way to break such a group is not a cleverer algorithm in the same world. It is to change worlds -- to a machine that computes on a fundamentally different substrate.

11. The Third Road: Shor, and Why a Clean Group Leaves Only Quantum

Strip a group of every exploitable structure and the classical attacker is back at Pollard's 1978 random walk, hitting the square-root wall with no crack to exploit. The one thing left that beats that wall does not compute a cleverer logarithm. It runs on a different machine.

In 1994, Peter Shor showed that a quantum computer could solve both integer factoring and the discrete log in polynomial time [@shor-1997]. The discrete-log algorithm does not attack the group's structure the way index calculus does. It rewrites the problem into a shape a quantum computer is uniquely good at.Framed abstractly, Shor's discrete-log routine solves a hidden subgroup problem: the secret $x$ hides a subgroup of $\mathbb{Z}\ell \times \mathbb{Z}\ell$ generated by $(x, 1)$, and the quantum Fourier transform is the tool that exposes it [@childs-vandam-2010]. The abelian hidden-subgroup problem is the common engine behind Shor's factoring and discrete-log algorithms alike.

Shor's move is to recast the discrete log as *period-finding*. From the target one builds a function whose period encodes the secret exponent $x$. A classical machine cannot see that period without effectively searching for it, but a quantum machine can evaluate the function over a superposition of inputs and apply the quantum Fourier transform, which concentrates measurement probability on the period. Each measurement then returns a pair $(\alpha, \beta)$ obeying a linear relation $\alpha x + \beta \equiv 0 \pmod{\ell}$, and a few such relations pin down $x$ by classical linear algebra mod $\ell$ -- not the continued-fractions step that finishes Shor's *factoring* routine. flowchart TD A[Target: Q equals x times P on a clean curve] --> B[Build a function periodic in the unknown x] B --> C[Evaluate it over a superposition on the quantum register] C --> D[Quantum Fourier transform makes the period observable] D --> E[Measure: each shot yields a linear relation in x, mod l] E --> F[Solve the linear congruences for the discrete log x, polynomial in log of the order]

The consequence is the one classical cryptanalysis can never deliver: the cost is polynomial in $\log \ell$, so key size is no defense. Doubling the curve size barely moves Shor's cost. And it needs none of the structural preconditions from the table in Section 9 -- no trace one, no small embedding degree, no smooth twist, no factor base. It breaks a correct key on a flawless group. Shor is the empty cell filled in: the only known attack that does not require the group to be badly chosen.

Crucially, the progress since 1994 has been algorithmic, not hardware. The first ECDLP-specific quantum circuit came from Proos and Zalka in 2003, who made a structural observation that still holds: elliptic curves are an easier quantum target than equal-security RSA [@proos-zalka-2003].

The modern resource estimate, from Roetteler, Naehrig, Svore, and Lauter in 2017, is concrete: a 256-bit ECDLP needs about 2,330 logical qubits -- following their count of $9n + 2\lceil\log_2 n\rceil + 10$, which for $n = 256$ gives $2304 + 16 + 10 = 2330$ -- and on the order of $1.3 \times 10^{11}$ Toffoli gates, versus roughly 6,146 logical qubits for RSA-3072 [@roetteler-2017]. The curve's small keys, its great classical advantage, make it the cheaper thing to break once a quantum computer exists.

Note: Shor is structural mathematics against an asymmetric primitive: it breaks the discrete-log problem itself, in polynomial time, on a flawless group -- squarely the subject of this article. Grover's algorithm is a different animal: a generic square-root speedup for unstructured search that halves the effective key length of symmetric ciphers and hashes. It is not a structural break of the discrete log, and simply doubling a symmetric key neutralizes it. Grover is named here only to be set aside.

Two honest boundaries close this section. First, no cryptographically-relevant quantum computer exists today, and this article asserts no timeline for when, or whether, one will. The resource estimates set a migration clock, not a countdown. Second, the genuine successor to discrete-log cryptography is post-quantum cryptography -- schemes built on entirely different hard problems such as lattices, error-correcting codes, and hash functions. That is a separate research program, out of scope here, and its independence is the point: it is not a faster discrete log but a different foundation.

That post-quantum cryptography is a genuinely different problem, not a continuation of the discrete-log genealogy, is underscored by how young and unsettled it still is: several proposed post-quantum schemes have themselves been broken during standardization -- the SIDH/SIKE isogeny key-exchange scheme fell to an efficient classical key-recovery attack [@castryck-decru-2022], and the Rainbow signature finalist was broken on a laptop in a single weekend [@beullens-2022] -- which would be impossible if they were merely the discrete log in disguise. Different problems fail in different ways.

So the mathematics is settled enough to act on. Choose a group with no weak part, and the classical attacker is stranded at the square-root floor; the only remaining break is one you cannot out-size, and the response to it is migration, not a bigger key. That leaves one practical question: how do you actually choose a group with no weak part? Every criterion is a scar from an attack in this article.

12. Choosing a Group With No Weak Part

Every line on a curve-selection checklist is a scar from a specific attack in this article. Read the checklist not as arbitrary hygiene but as a map of defeated enemies -- each criterion exists because someone, somewhere, lost a key to the attack it blocks.

Criterion	Attack it defeats
Large prime subgroup order	Pohlig-Hellman [@pohlig-hellman-1978]
Small cofactor	small-subgroup leakage
Trace not one, so $#E \neq p$	anomalous / SSSA transfer [@smart-1999]
Large embedding degree	MOV / Frey-Ruck [@mov-1993]
Twist-security (curve and twist near-prime order)	twist confinement; in a single-coordinate ladder it also confines an off-curve input to the secure twist. The full-coordinate invalid-curve shadow needs input-point validation instead, an implementation check handed to the sibling [@safecurves] [@biehl-meyer-muller-2000]
Prime field, no small characteristic, no composite extension	Weil descent / GHS [@ghs-2002], small-char quasi-poly [@kleinjung-wesolowski-2019]
Rigidity (fully explained, manipulation-resistant parameters)	hidden-structure and backdoor suspicion [@bernstein-curve25519-2006]

Two of these checks are easy enough to run on a toy example, which makes the abstract concrete: a curve is anomalous exactly when its point count equals the field prime, and it has a dangerous embedding degree exactly when the subgroup order divides $p^k - 1$ for some small $k$.

{` def embedding_degree(l, p, bound=200): # least k with l dividing p^k - 1; small k means a MOV / Frey-Ruck door r = p % l for k in range(1, bound + 1): if r == 1: return k r = (r * p) % l return None # beyond the search bound: safely large

def score(p, n, l): flags = [] if n == p: flags.append("ANOMALOUS: #E equals p, trace one -> polynomial-time SSSA transfer") if n % l == 0: k = embedding_degree(l, p) if k is not None and k <= 6: flags.append("LOW EMBEDDING DEGREE k=" + str(k) + " -> MOV / Frey-Ruck transfer") if n // l > 8: flags.append("LARGE COFACTOR " + str(n // l) + " -> small-subgroup leakage") else: flags.append("subgroup order does not divide the point count (bad parameters)") return flags or ["no structural red flag on these two checks"]

print("anomalous toy (p = n = 23):", score(23, 23, 23)) print("low-k toy (p=23, points=24, order=3):", score(23, 24, 3)) print("clean toy (p=101, points=order=83):", score(101, 83, 83)) `}

The decision, in one flow

flowchart TD A{"What are you building?"} -->|New system, free choice| B[X25519 for key exchange, Ed25519 for signatures] A -->|FIPS-constrained| C[NIST P-256] A -->|Finite-field DH is forced| D[A standard RFC 7919 group of at least 2048 bits, never a shared 1024-bit prime] B --> E[Verify large prime order, small cofactor, trace not one, large embedding degree, twist-secure, rigid] C --> E D --> F[Plan a post-quantum or hybrid migration for the Shor horizon] E --> F

For a new system with a free hand, use X25519 for key exchange and Ed25519 for signatures [@rfc7748] [@rfc8032]: they are twist-secure and rigid by construction, and they close every classical door in the table above. Where a standard mandates the NIST curves, P-256 is a sound choice with the same generic-floor security [@nist-sp800-186]. If finite-field Diffie-Hellman is genuinely unavoidable, use a standard RFC 7919 group of at least 2048 bits -- its shared named groups are safe at this size because the sieve precomputation is infeasible -- or a dedicated unique prime; never a shared or legacy 1024-bit prime, whose danger was the entire lesson of Logjam [@rfc7919].

And across the board, avoid the families this article condemned: anomalous curves, low-embedding-degree curves, small-characteristic fields, and the binary and Koblitz curves that NIST now deprecates and FIPS 186-5 removes [@nist-sp800-186].

Note: For roughly 128-bit security you can carry a 256-bit elliptic-curve key or a 3072-bit finite-field prime -- an eighth of the size for the same strength, with the gap widening at higher security levels. That is not a small optimization; it is why elliptic curves dominate new deployments. Unless a specific standard forces finite-field Diffie-Hellman, prefer X25519 and Ed25519 for smaller keys and faster, twist-secure operations [@safecurves] [@rfc7748].

One caveat belongs to the sibling article, not this one: choosing a strong group is necessary but not sufficient. A flawless curve still fails if the software forgets to validate an input point, reuses a nonce, or leaks timing -- the implementation failures catalogued in "How Elliptic Curves and Diffie-Hellman Break in Real Life." This article guarantees only that the mathematics of a well-chosen group offers no purchase. The code still has to hold up its end.

That covers what to do. The questions careful engineers keep asking -- and the misconceptions that trip up even good ones -- deserve direct answers.

13. Frequently Asked Questions

No -- it gives about 128-bit security. Because Pollard rho solves the discrete log in roughly the square root of the group order, a 256-bit curve is a $2^{128}$ target, not a $2^{256}$ one. SafeCurves lists NIST P-256 at about $2^{127.8}$ and Curve25519 at about $2^{125.8}$ operations [@safecurves]. The bit length of the key is double the security level, not equal to it. Only for two of the problems. A bigger key raises the generic square-root floor, and a larger, unique prime defeats undersized or shared finite-field Diffie-Hellman. But a *structural* break ignores key size entirely: an anomalous curve falls in polynomial time regardless of its bit length [@smart-1999], a shared precomputed prime falls no matter how fresh the ephemeral [@logjam-adrian-2015], and Shor is polynomial in the log of the order, so doubling the curve barely moves its cost [@shor-1997]. Against structure, size is no defense. No. On a well-chosen group it is, as far as anyone knows, as hard as it can be -- the best generic attack is Pollard rho, and Shoup proved no generic algorithm does better [@shoup-1997]. Every real break in the literature exploited a structural property of a *chosen* group, not the logarithm itself. The honest caveat is that elliptic-curve discrete-log hardness is *unproven*: no one can prove it is hard, only observe that no one has broken a clean curve. Because $\mathbb{F}_p^*$ has a factor base and a clean curve does not. The multiplicative group's elements are integers you can factor, which is exactly what the sub-exponential Number Field Sieve needs [@gordon-1993]. A well-chosen elliptic curve has no notion of a "smooth" point, so the sieve has nothing to grip, and the best attack stays at the square-root floor. The Logjam exposure came from that structural difference meeting a shared, undersized prime [@logjam-adrian-2015]. No. The expensive first stage of the Number Field Sieve depends only on the *prime*, not on any individual key, so it amortizes across every connection that shares that prime [@logjam-adrian-2015]. Freshness protects the ephemeral key; it does nothing about a shared group. A unique prime, not a fresh ephemeral, is what denies the attacker the precomputation. Shor. It reduces the discrete log to quantum period-finding and solves it in polynomial time on a flawless group, which is a structural break and squarely in scope [@shor-1997]. Grover's algorithm is only a generic square-root speedup for unstructured search; it shortens *symmetric* keys and is neutralized by doubling them. Grover is not a structural break of the discrete log at all, and it is named here only to be set aside. No. The only proven wall is Shoup's $\Omega(\sqrt{\ell})$ lower bound, and it holds only in the *generic-group* model -- index calculus beats it for $\mathbb{F}_p^*$ precisely because that group is not generic [@shoup-1997]. There is no unconditional hardness proof, and one is not expected soon: the discrete log sits in $\mathrm{NP} \cap \mathrm{coNP}$, so it is believed not to be NP-complete, which puts a hardness proof far beyond current complexity theory [@galbraith-2012]. "Only Shor breaks a clean group" always carries the silent rider "as far as is known."

The Log Was Never the Weak Part

Return to the four groups from the opening. NIST P-256 and Curve25519 stand at about $2^{128}$ because they have large prime order, trace not one, large embedding degree, twist-security, and rigid parameters -- every structural door bolted shut, leaving only the square-root floor.

The third 256-bit curve dies in polynomial time for one reason: its trace is one, so its log transfers into simple addition. And the 1024-bit finite-field group is a nation-state target because its group is inherently factorable and its prime was shared and precomputed. Four groups, the same discrete logarithm, three different fates -- and in every case the deciding variable was the group.

Same discrete log, radically different fates. The variable was never the logarithm. It was the group.

That is the pattern under all ten attacks. Pohlig-Hellman needs a smooth order. The anomalous transfer needs trace one. MOV and Frey-Ruck need a small embedding degree. Twist attacks need a smooth twist. Invalid-curve shadows need $b$-independent arithmetic. Weil descent needs a composite extension field. The Number Field Sieve needs a factor base. Logjam needs a shared prime. Small-characteristic descent needs a small characteristic. Every classical break is a receipt for a structural property of a chosen group, and never once a faster generic logarithm.

Key idea: Strip a group of every exploitable structure -- give it a large prime order, a small cofactor, trace not one, a large embedding degree, twist-security, rigidity, a prime field, no small characteristic, and a unique well-sized prime -- and the classical attacker is thrown all the way back to Pollard's 1978 random walk. The only thing left that beats it does not compute a cleverer logarithm; it changes the machine. The logarithm was never the weak part. The group always was.

Which is why the rational response has two halves. Choose a clean group -- the checklist in Section 12 is really a list of defeated attacks -- and begin preparing for the one break you cannot out-size, by planning the migration to post-quantum primitives before a quantum computer forces the issue.

For the failures that live in code rather than mathematics -- unvalidated points, repeated nonces, timing leaks, negotiated downgrades -- turn to the empirical sibling, "How Elliptic Curves and Diffie-Hellman Break in Real Life." The mathematics here gives you a group with no weak part. The engineering there decides whether your system keeps it that way.