Parag Mali - tag: diffie-hellman

How Elliptic Curves and Diffie-Hellman Break in Real Life: The Discrete Log Never Fell

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

On a strong curve or a 2048-bit group, no one has ever solved the discrete logarithm in the field -- yet PlayStation 3 consoles, Android Bitcoin wallets, tamper-resistant TPMs, Windows certificate validation, and live TLS sessions all fell. Every one of those breaks attacked a layer the discrete-log math depends on but does not control: the per-signature nonce (PS3, Android, Minerva, TPM-Fail, LadderLeak), the curve and certificate parameters (CurveBall), or the negotiated strength (Logjam). A *reused* nonce surrenders the key from just two signatures; a *biased* nonce needs a statistical attack over many. The only discrete log ever computed here was Logjam's, against a downgrade-forced, export-crippled, shared 512-bit prime -- never a strong deployed curve. The fix is never a bigger curve. It is hedged, constant-time signing, validated parameters, and retiring export and shared groups.

1. Seven Breaks, One Unbroken Problem

On a well-chosen elliptic curve, the best attack anyone has ever fielded against the discrete logarithm is a square-root-time random walk that has barely moved since the 1970s [@hac-ch11][@teske-2001]. No deployed P-256, Curve25519, or secp256k1 key, and no standard 2048-bit Diffie-Hellman group, has ever had its discrete log solved in public. By every measurement we can make, the mathematics is holding.

And yet. PlayStation 3 consoles were jailbroken [@fail0verflow-ps3-2010]. Android Bitcoin wallets were emptied [@bitcoin-android-2013]. Tamper-resistant TPMs certified to government standards surrendered their signing keys [@tpmfail-2020]. Windows accepted forged certificates that chained to a counterfeit authority [@curveball-cve-2020-0601]. Live TLS sessions were downgraded and decrypted in transit [@logjam-weakdh-2015]. Every one of those systems ran the discrete-log math exactly as specified. The math was never where they broke.

That is the paradox this article resolves, and the resolution fits in one sentence: none of these attacks solved a discrete logarithm. Each attacked a layer the math depends on but does not control. There are exactly three such layers, and they organize everything that follows:

The per-signature nonce -- the throwaway secret ECDSA needs for every signature. PS3, Android, Minerva, TPM-Fail, and LadderLeak all landed here.
The curve and certificate parameters -- which curve, and whose generator, you are actually talking to. CurveBall landed here.
The negotiated strength -- how strong a key exchange two parties agree to use before they exchange anything. Logjam landed here.

Key idea: The discrete-logarithm assumption protects the private key against being directly computed -- and nothing else. "Nobody solved the discrete log" and "somebody recovered the private key" are not contradictory statements, because the discrete-log problem (genuinely hard) and a discrete-log deployment (a nonce, some parameters, a negotiation) are different things. Every real break in this article lives in the gap between them.

A note on scope. This piece treats the hardness of the elliptic-curve discrete logarithm as a black box: assume it holds, and watch everything around it fail. The structural mathematics of curve choice -- why one curve is weak and another is strong, how the number field sieve and Shor's algorithm actually work -- belongs to a companion article, "How the Discrete Log Would Break: Elliptic Curves, Finite Fields, and Why Curve Choice Is the Weak Part." Here, we assume the strongbox is uncrackable and ask how the key kept getting out anyway.

To see why a hard problem protects so little, you first have to see exactly what it promises -- and what it quietly leaves to the deployment.

2. What the Math Actually Promises

In 1976, Whitfield Diffie and Martin Hellman reduced the ancient problem of exchanging a secret over an open wire to a single piece of hard arithmetic: the discrete logarithm [@diffie-hellman-1976]. Two parties each pick a private exponent, exchange public powers of a shared generator, and combine them into a key that an eavesdropper cannot reconstruct without solving for one of those exponents.

Nine years later, Victor Miller and, independently, Neal Koblitz moved the same hard problem onto elliptic curves [@miller-1985][@koblitz-1987]. Koblitz argued the curve version was "likely to be harder than the classical discrete logarithm problem" [@koblitz-1987] -- which is why a 256-bit curve buys security that a finite field needs thousands of bits to match. A clean, triumphant origin. So where did the promise leak?

Given a generator `G` and a public point `Q = dG` on an elliptic curve (or a base `g` and `g^d` in a finite field), recovering the secret integer `d` is the discrete logarithm problem. The security of ECDSA, ECDH, and Diffie-Hellman rests on the assumption that this recovery is computationally infeasible for well-chosen parameters. It is the one thing the math promises -- and, as we will see, the only thing.

Signatures are where the story starts, because signatures introduce a second secret. The Elliptic Curve Digital Signature Algorithm (ECDSA) signs a message hash z under a long-term private key d by generating a fresh random value k, computing a point kG, taking its x-coordinate as r, and producing:

$$s = k^{-1},(z + r,d) \bmod n$$

where n is the order of the group. The verifier only ever sees (r, s). The private key d is buried inside, protected by the discrete-log assumption -- nobody can read d off the signature. But look at what else is in that equation.

The `k` in ECDSA is a *nonce*: a number used once. It must be secret, statistically uniform, and unique to each signature. It is not the private key, and it is thrown away the instant the signature is produced. It is also the single most load-bearing prerequisite in the whole scheme -- because `k` and `d` appear together in one linear equation, anything an attacker learns about `k` turns directly into knowledge of `d`.

The discrete-log assumption guards d against being computed from the public key. It says nothing whatsoever about three things the assumption quietly depends on but does not itself enforce:

The nonce k must be secret, uniform, and unique. The math assumes a perfect k and never checks that you supplied one.
The parameters must be the standard, named ones. The math assumes you are on the curve you think you are, with the generator you think you have.
The negotiated strength must not be crippled or shared. The math assumes the group you agreed to use is actually strong.

Each of those is the deployment's responsibility, not the primitive's. And each one became a pillar of failure.

flowchart TD DLP["(EC)DLP is hard: d cannot be computed from the public key dG"] DLP --> N["Depends on the per-signature nonce k"] DLP --> P["Depends on the curve and certificate parameters"] DLP --> G["Depends on the negotiated group strength"] N --> P1["Pillar 1 nonce: PS3, Android, Minerva, TPM-Fail, LadderLeak"] P --> P2["Pillar 2 validation: CurveBall"] G --> P3["Pillar 3 downgrade: Logjam"]

The curve migration itself is not our subject.Miller (1985) and Koblitz (1987) are mentioned here only to fix the primitive's birth. Whether a particular curve is structurally weak -- anomalous curves, small embedding degrees, the number field sieve, Shor's algorithm -- is the structural mathematics deferred to the companion article. This article assumes the curve is strong and attacks everything around it. The math guards the key against being computed. It says nothing about the key being handed over. Three contracts govern that handover, and each one broke.

3. Three Contracts the Deployment Signs and Never Reads

Every cryptographic deployment signs a contract it never reads. There are three clauses, one for each layer the math leans on, and the fine print on all three is where real products sank.

The nonce contract: k must be fresh

Take the ECDSA signing equation and ask the cruelest possible question: what if k is not unique? Suppose two different messages, with hashes z1 and z2, are signed under the same nonce k. Because r is the x-coordinate of kG, the same k produces the same r in both signatures. Now write them down side by side:

$$s_1 = k^{-1}(z_1 + r,d), \qquad s_2 = k^{-1}(z_2 + r,d) \pmod n$$

Subtract. The rd term is identical in both, so it cancels, and k falls straight out:

$$s_1 - s_2 = k^{-1}(z_1 - z_2), \qquad k = \frac{z_1 - z_2}{s_1 - s_2} \bmod n$$

Once you know k, the first equation has exactly one unknown left, and you solve for the private key by hand:

$$d = \frac{s_1,k - z_1}{r} \bmod n$$

No lattice. No side channel. No discrete log. Two signatures that share a nonce are two linear equations in two unknowns, and a middle-schooler with modular arithmetic can finish the job.

Note: The discrete-logarithm assumption protects d against direct computation from the public key -- and nothing else. It does not protect d against being algebraically extracted when the nonce misbehaves. The moment two signatures reuse k, the strongbox is irrelevant, because the deployment left a second door wide open.

The contract, then, is strict: k must be secret, statistically uniform, and never reused or partially leaked. Break any word of that clause and the algebra above (or its statistical cousin, later) takes your key.

The parameter contract: talk to the curve you think you are

The second clause is about identity. A named curve -- "P-256," "secp256k1" -- is an agreement to use one specific set of domain parameters, and in particular one specific generator, the base point G that every public key is measured against.

Every named elliptic curve fixes a single public point `G` from which all key material is derived: a private key `d` corresponds to the public point `dG`. The generator is not a secret -- it is a published constant. But it is load-bearing: "the public key is `dG`" is only meaningful if both sides agree on which `G`. A certificate can specify its curve two ways. A *named curve* is an object identifier pointing at standardized domain parameters (fixed `a`, `b`, `p`, `G`, `n`). *Explicit parameters* spell out all of those numbers inline, which lets the certificate carry a *custom* generator. Accepting explicit parameters without checking them against a known named curve means trusting an attacker to tell you what `G` is.

The contract: never trust attacker-supplied explicit parameters. A validator that checks a public point but not the generator it was measured against has, in effect, let the attacker choose the ruler and then declared the measurement correct. That is precisely the door CurveBall walked through [@curveball-cve-2020-0601].

The negotiation contract: agree to strength, not to a museum piece

The third clause governs what two parties agree to before they exchange anything. In ephemeral Diffie-Hellman, each side picks a fresh secret per connection, which is supposed to guarantee that compromising one session cannot retroactively expose others.

In ephemeral DH, the private exponents are generated fresh for each connection and discarded afterward, so a key recovered later cannot decrypt past sessions. This property is called forward secrecy. It is the reason "just use a fresh ephemeral key" feels like a complete defense -- and, as Logjam showed, the reason that feeling is dangerously incomplete. In the 1990s, US export regulations capped the strength of cryptography shipped abroad, producing deliberately weakened cipher suites such as 512-bit `DHE_EXPORT` Diffie-Hellman [@logjam-weakdh-2015]. The policy was abandoned, but the code was not: two decades later, servers and libraries still spoke these crippled suites on request.

The contract: the negotiated group must be strong, fresh, and unshared. The fine print that sank it: many servers ship the same standardized 512-bit prime, so breaking one group breaks all of them at once [@logjam-weakdh-2015]. A fresh ephemeral exponent does not save you when the prime itself is weak and shared.

Contract	What it requires	What violates it	Field break
Nonce	`k` secret, uniform, unique per signature	a constant, repeated, or biased `k`	PS3, Android, Minerva, TPM-Fail, LadderLeak
Parameter	named curve, standard generator `G`	trusting attacker-supplied explicit parameters	CurveBall
Negotiation	strong, fresh, unshared group	downgrade to a crippled, shared group	Logjam

Three contracts, three clauses of fine print. Over fifteen years, every clause was breached in the field -- and the breaches fall into exactly three piles.

4. The Failure Catalog: Seven Breaks, Three Layers, One Shape

None of the seven incidents below solved a discrete logarithm. Every one of them recovered a private key or forged a trusted one. Watch where each attack actually landed -- because the landing spot, not the marquee name, is the whole lesson.

timeline title EC and DH in the field, the assumption versus the breaks 1976 : Diffie-Hellman, the assumption is born 1985-1987 : Miller and Koblitz, the curve migration 2010 : PS3 constant nonce, reuse 2013 : Android SecureRandom, reuse 2015 : Logjam, downgrade plus shared-prime NFS 2019-2020 : Minerva and TPM-Fail, lattice bias 2020 : LadderLeak, Bleichenbacher-Fourier sub-bit : CurveBall, unvalidated generator

Here is the entire corpus on one page. The rightmost column is the thesis in a single word, repeated seven times.

Incident	Year	Pillar	Mechanism	Effort to break	What fell	Discrete log solved?
PS3	2010	Nonce (reuse)	a constant `k`	2 signatures	ECDSA firmware-signing key	No
Android wallets	2013	Nonce (reuse)	repeated `k` from a broken RNG	2 reused signatures	Bitcoin wallet keys	No
Logjam	2015	Downgrade	forced 512-bit shared prime	1 NFS precompute per prime	TLS session secrecy	Only a crippled, shared 512-bit export prime
TPM-Fail	2019-2020	Nonce (bias)	timing leak of nonce bit-length	many signatures + lattice	256-bit TPM keys	No
Minerva	2020	Nonce (bias)	timing leak of nonce bit-length	about 2100 signatures + lattice	ECDSA key	No
LadderLeak	2020	Nonce (bias)	sub-bit ladder leak	many signatures + Bleichenbacher/Fourier	ECDSA key	No
CurveBall	2020	Validation	an unchecked generator	1 forged certificate	certificate trust itself	No

Six "No"s and one heavily qualified "Yes." Let us walk the three pillars in turn.

Pillar 1a: the nonce, reused (certain, from two signatures)

In December 2010, at the 27th Chaos Communication Congress, the group fail0verflow presented "Console Hacking 2010" and revealed that Sony had signed PlayStation 3 firmware using ECDSA with a constant nonce [@fail0verflow-ps3-2010]. Not a weak random k. The same k, every time. Every signature Sony ever produced shared a nonce with every other, which means any two of them collapse to the algebra from Section 3.Keep two PS3 events distinct. fail0verflow's 27C3 talk exposed the constant-nonce mechanism. George Hotz released a separate PS3 root key weeks later, in January 2011 [@hotz-ps3-2011]. The teaching case -- a hardcoded constant nonce -- is fail0verflow's. The console's chain of trust, the thing Sony spent years engineering, came apart because a random number generator was told to always return the same number.

flowchart LR A["Sig 1: s1 = k^-1 (z1 + r d)"] --> C["Same k means same r"] B["Sig 2: s2 = k^-1 (z2 + r d)"] --> C C --> D["Subtract, k cancels: k = (z1 - z2) / (s1 - s2) mod n"] D --> E["Solve for d = (s1 k - z1) / r mod n"] E --> F["Private key recovered, no discrete log solved"]

This is not a metaphor. Here is the recovery, executable. Two signatures share a nonce, and a dozen lines of BigInt arithmetic reproduce the private key exactly:

{` // secp256k1 group order const n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141n; const mod = (a, m) => ((a % m) + m) % m;

// Modular inverse via the extended Euclidean algorithm function inv(a, m) { let [oldr, r] = [mod(a, m), m]; let [olds, s] = [1n, 0n]; while (r !== 0n) { const q = oldr / r; [oldr, r] = [r, oldr - q * r]; [olds, s] = [s, olds - q * s]; } return mod(olds, m); }

// A victim signs two different messages with the SAME nonce k const d = 0x00c0ffee1234567890abcdef00c0ffee1234567890abcdef00c0ffee12345678n; // secret const k = 0x0000deadbeef0000feed0000deadbeef0000feed0000deadbeef0000feed0001n; // reused nonce const r = mod(0x1122334455667788112233445566778811223344556677881122334455667788n, n); const z1 = 0x1111111111111111111111111111111111111111111111111111111111111111n; const z2 = 0x2222222222222222222222222222222222222222222222222222222222222222n; const s1 = mod(inv(k, n) * mod(z1 + mod(r * d, n), n), n); const s2 = mod(inv(k, n) * mod(z2 + mod(r * d, n), n), n);

// The attacker sees only (r, s1, z1) and (r, s2, z2). Recover k, then d. const kRec = mod((z1 - z2) * inv(mod(s1 - s2, n), n), n); const dRec = mod((mod(s1 * kRec, n) - z1) * inv(r, n), n); console.log('recovered nonce matches: ' + (kRec === k)); console.log('recovered private key: ' + (dRec === d)); console.log('d = 0x' + dRec.toString(16)); `}

Three years later, the same algebra emptied wallets. In August 2013, an advisory on bitcoin.org warned that "a component of Android responsible for generating secure random numbers contains critical weaknesses" that rendered "all Android wallets" vulnerable to theft [@bitcoin-android-2013]. The root cause, per Google's own postmortem, was that the platform's SecureRandom "may not receive cryptographically strong values" because the underlying PRNG was improperly initialized [@android-securerandom-2013].

The consequence was nonce repetition across transactions. And because every Bitcoin signature is broadcast to a public ledger, anyone could scan the chain for two signatures sharing an r and drain the wallet behind them.The bitcoin.org advisory names the flaw and the affected wallets but states no total loss figure [@bitcoin-android-2013]. Any "coins stolen" number you have seen is reported, not established -- treat it accordingly.

The detector that would have caught both PS3 and Android is embarrassingly short. Group public signatures by r; any collision is an exposed key:

{` const n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141n; const mod = (a, m) => ((a % m) + m) % m; function inv(a, m) { let [oldr, r] = [mod(a, m), m]; let [olds, s] = [1n, 0n]; while (r !== 0n) { const q = oldr / r; [oldr, r] = [r, oldr - q * r]; [olds, s] = [s, olds - q * s]; } return mod(olds, m); } // Build a public feed in which one signer reused a nonce, then forget the secret const dSecret = 777n, kReused = 424242n, rReused = 987654321n; const mk = (z) => ({ r: rReused, s: mod(inv(kReused, n) * mod(z + mod(rReused * dSecret, n), n), n), z }); const feed = [ { r: 111n, s: 22n, z: 5n }, mk(1001n), { r: 222n, s: 44n, z: 9n }, mk(2002n), { r: 333n, s: 66n, z: 12n } ];

Two incidents, two different root causes -- a hardcoded constant and a starved RNG -- and one identical, certain outcome. This is the crudest form of the whole thesis: the deployment lost the key while the discrete log stood untouched.

Note: A repeated nonce is certain key recovery from just two signatures, by elementary algebra. A biased nonce -- one that merely leans, statistically, toward certain values -- leaks only a partial statistic and requires a statistical attack over many signatures. "One biased signature leaks your key" is false. The distinction is the difference between the next two subsections, and blurring it is the single most common error in this area.

Dimension	Reused nonce	Biased nonce
What leaks	the whole nonce (it repeats)	a partial statistic about the nonce
Signatures needed	exactly 2	many (Minerva about 2100; PuTTY about 60 [@putty-cve-2024-31497])
Attack	elementary algebra	Hidden Number Problem (lattice or Fourier)
Certainty	certain	statistical
Examples	PS3, Android	Minerva, TPM-Fail, LadderLeak, PuTTY

Pillar 1b: the nonce, biased (statistical, over many signatures)

Reuse is loud. The subtler failure is a nonce that never repeats but is not quite uniform -- one whose top bit is a little too often zero, say. It turns out that even this surrenders the key, and the theory predicting it predates the exploits by two decades.

Given many samples that each leak a few of the most-significant bits of `k`, together with the public signature data, recover the fixed secret `d`. Boneh and Venkatesan defined this problem in 1996 and proved it tractable [@boneh-venkatesan-1996]. Every biased-nonce attack in this article -- Minerva, TPM-Fail, LadderLeak, PuTTY -- is an instance of it.

Nguyen and Shparlinski turned the abstract HNP into a concrete lattice attack on (EC)DSA with partially known nonces [@nguyen-shparlinski-2003], and Brumley and Tuveri showed in 2011 that the necessary bit-leak could be harvested remotely, over a network, from an OpenSSL implementation whose scalar multiplication was not constant-time [@brumley-tuveri-2011]. Then the field split into two solver regimes, and telling them apart is essential.

When the timing channel leaks a few bits of the nonce -- typically its exact bit-length -- the HNP is solved by lattice reduction. Minerva (CHES 2020) demonstrated this against smartcards and libraries whose scalar multiplication ran in time correlated with the nonce's length, reporting roughly "2100 signatures to recover the private key on the standard secp256r1 curve" [@minerva-2020].

TPM-Fail (USENIX Security 2020) carried the same idea into hardware roots of trust. A timing leak in Intel firmware TPMs (CVE-2019-11090 [@cve-2019-11090]) and STMicroelectronics ST33 chips (CVE-2019-16863 [@cve-2019-16863]) recovered a 256-bit ECDSA key from an Intel fTPM in 4 to 20 minutes, and a VPN authentication key remotely in about five hours [@tpmfail-2020].Two honesty notes. Minerva's project page retracted its original EdDSA claim; the confirmed result is ECDSA-only [@minerva-2020]. And the TPM-Fail targets were not toys -- they held Common Criteria EAL4+ and FIPS 140-2 certification, and the leak survived that scrutiny [@tpmfail-2020].

flowchart TD L["A timing channel leaks partial information about the nonce k"] --> Q{"How much leaks per signature?"} Q -->|"at least 2 bits"| LAT["Lattice reduction of the HNP: Minerva, TPM-Fail"] Q -->|"under 1 bit"| FFT["Bleichenbacher and Fourier HNP: LadderLeak"] LAT --> R["Private key d recovered over MANY signatures"] FFT --> R

The second regime is where people get it wrong. When the leak drops below a single bit -- LadderLeak revealed the most-significant bit of the nonce "but with probability less than one" -- lattices become intractable, and the attack instead revives a Fourier-analysis method the paper credits to Daniel Bleichenbacher [@ladderleak-2020].

The LadderLeak authors note that "most of the attacks so far have relied on at least two bits of nonce bias," precisely the lattice regime. Their contribution was to break below it, over curves sect163r1 and NIST P-192, using the Fourier solver rather than a lattice [@ladderleak-2020]. Calling LadderLeak a lattice attack is the field's classic mistake.

"Breaking ECDSA With Less Than One Bit Of Nonce Leakage" -- the title of the LadderLeak paper, and the most compact statement of how little a nonce must betray before the key is gone.

Notice what happened across this subsection. Every one of these attacks beat a signer that had already removed the reuse bug. The leak had moved from how the nonce was generated to how it was used -- a variable-time scalar multiplication -- and the cure had to move with it. Hold that thought; it is the pivot of the entire article. But reuse or bias, lattice or Fourier, two signatures or two thousand, the outcome is the same and the discrete logarithm is never touched: the deployment hands over d, and the strongbox stays locked.

Pillar 2: the parameters, unvalidated (CurveBall)

The nonce pillar is about a secret the deployment mishandles. The second pillar is about an identity the deployment fails to check. On 14 January 2020, Microsoft patched CVE-2020-0601, reported by the NSA: "a spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates" [@curveball-cve-2020-0601]. It became known as CurveBall, and it is the cleanest example in the whole corpus of a break that has nothing to do with the mathematics of ECC.

Recall the parameter contract. A public key is the point dG -- meaningful only if everyone agrees on G. CryptoAPI, when handed a certificate that specified its curve with explicit parameters, checked that the certificate's public point matched a trusted root's public key. What it did not check was the generator.

So an attacker could craft a curve with a custom generator G', pick any private key d' they liked, and compute G' such that d' * G' equals the exact public point of a trusted root certificate authority. The forged certificate then presents the right public point on the wrong curve. Windows, comparing only the point, accepts it -- while a library that pins named curves rejects it instantly, because G' is not the standard base point.

flowchart TD A["Attacker picks explicit curve parameters with a custom generator G-prime"] --> B["Chooses private key d-prime so that d-prime times G-prime equals a trusted root public point Q"] B --> C["Forged certificate presents point Q on the attacker curve"] C --> D{"Windows CryptoAPI validation"} D -->|"Public point matches a trusted root? YES"| E["Accepted, but the generator was never checked"] D -.->|"A named-curve-pinning library also checks G"| F["Rejected, G-prime is not the standard base point"] E --> G["Forged code-signing or TLS certificate chains to a trusted root"]

The ECDLP was never in play. The attacker chose their own private key; they never had to recover anyone's. The failure is a single missing comparison -- generator against named curve -- buried in a certificate validation stack that a billion machines trusted. CurveBall is a validation bug, not a curve break, and the fix is exactly what the missing check would have been: reject explicit parameters, or fully re-validate them against the claimed named curve.

Pillar 3: the negotiation, downgraded (Logjam)

The third pillar is the one honest exception, and handled carelessly it looks like a refutation of the whole thesis. In 2015, the Logjam team (CVE-2015-4000) showed that a man-in-the-middle could rewrite a TLS handshake -- "rewriting a ClientHello with DHE replaced by DHE_EXPORT" -- to force the connection onto a 512-bit export-grade Diffie-Hellman group [@cve-2015-4000]. And here, unlike everywhere else, the attacker really does compute a discrete logarithm.

The trick is that the expensive part of the number field sieve has to be done only once per prime, and servers share primes.

The fastest known classical algorithm for the finite-field discrete logarithm (and for integer factoring). Its decisive feature here: its costly first stage depends only on the *prime* being attacked, not on any particular exchanged key. Precompute once per prime, and every session under that prime becomes cheap to break. The internals belong to the companion article; what matters here is that one structural fact.

The Logjam researchers found that "8.4% of the Top 1 Million domains were initially vulnerable," and that because so many servers reused a handful of standardized 512-bit primes, "the first step in the number field sieve ... is dependent only on this prime" [@logjam-weakdh-2015]. One precomputation, amortized across every server that shipped that prime.

"The first step in the number field sieve ... is dependent only on this prime." One precomputation breaks every server that shares the group. sequenceDiagram participant C as Client participant M as MITM participant S as Server Note over M: One-time NFS precomputation per shared 512-bit prime C->>M: ClientHello offering DHE M->>S: ClientHello rewritten to DHE_EXPORT S->>M: 512-bit export DH parameters, a shared standardized prime M->>C: forwards the weak parameters Note over M: Precomputation done, so this connection solves fast M-->>C: session decrypted in near real time The 512-bit `DHE_EXPORT` groups existed because 1990s US export regulations forbade shipping strong cryptography abroad, mandating deliberately breakable key exchange for foreign markets [@logjam-weakdh-2015]. The policy was abandoned by the early 2000s, but the cipher suites were never removed from server software. Logjam, in 2015, exploited a legal compromise that had been dead for over a decade and a codebase that never got the memo. The math did not decay -- the deployment simply kept a museum piece plugged in.

Read carefully, Logjam is not a counterexample; it is the thesis in its most literal form. A discrete log was computed, but only against a 512-bit prime that a downgrade forced the connection onto and that policy had left crippled and shared. The deployment set the weak, shared group on the table; the number field sieve merely finished the job. No strong, standard-sized group ever fell. The fix is the same shape as the break: remove export ciphers, negotiate vetted named groups (RFC 7919 [@rfc7919]), and adopt TLS 1.3, which removes static Diffie-Hellman entirely [@rfc8446].

Three pillars, seven breaks, one shape: every attack hit a layer the discrete-log math depends on but does not control. Name the shape, and you have the whole discipline.

5. The Realization: Fix the Contracts, Not the Curve

There was no single eureka here. The insight accumulated across fifteen years of incidents and then snapped into one sentence: every field break attacked a layer the discrete-log math depends on but does not control -- the nonce, then the parameters, then the negotiated strength -- and every fix changed how the primitive is generated, used, validated, or negotiated, never the curve and never the log.

The sharpest crystallization hides inside the word "bias." For years it was treated as one problem with one fix: remove the random number generator, derive the nonce deterministically (RFC 6979 [@rfc6979], later blessed by FIPS 186-5 [@fips-186-5]), and the biased-nonce class is solved. But Minerva, TPM-Fail, and LadderLeak all recovered keys from signers that had already done that. The reason is that "bias" was concealing two distinct root causes with two distinct cures.

flowchart TD B["One word: nonce bias"] --> G["Generation defect: the RNG returns a constant, repeated, or predictable k"] B --> U["Usage defect: variable-time scalar multiplication leaks the bit-length of k"] G --> GC["Cure: deterministic and hedged nonces, RFC 6979 and FIPS 186-5"] U --> UC["Cure: constant-time, exception-free scalar multiplication"] GC --> BOTH["You need BOTH, they are orthogonal"] UC --> BOTH

A generation defect is a bad nonce coming out of the sampler -- a constant (PS3), a repeat (Android), a predictable value. Determinism and hedging cure it. A usage defect is a perfectly good nonce leaking through the timing of the scalar multiplication that consumes it -- the bit-length falling out through a side channel (Minerva, TPM-Fail) or a sub-bit correlation (LadderLeak). Only constant-time code cures that. The two cures are orthogonal, and you need both.

Key idea: Generalize the two-cures fork and you get the entire discipline of this field: four contracts, not one curve. Generate the nonce so it cannot be predicted or repeated; use it in constant time so it cannot leak; validate your parameters so no attacker chooses your generator; negotiate only strong, unshared groups so no downgrade can strand you. Every documented break is a breach of one of those four. No break in the corpus is a break of the discrete logarithm.

This also dissolves the apparent contradiction the article opened with. "Nobody solved the discrete log" and "somebody recovered the key" only sound incompatible if you conflate the discrete-log problem with a discrete-log deployment. The problem is a statement about computational hardness; the deployment is a nonce, a set of parameters, and a negotiation, wrapped around that hardness. The problem stayed hard. The wrapping tore.

If you remember one operational thing from this article, make it this: deterministic ECDSA and constant-time scalar multiplication are not two names for the same safeguard. A team can adopt RFC 6979, check the box marked "nonce," and still ship a signer that a co-located attacker times to death. Ask both questions separately -- how is the nonce generated, and how is it used -- because they have separate answers.

If the discipline is "honor the four contracts, not the curve," what does a deployment that honors all four actually look like in 2026?

6. What Correct EC/DH Deployment Looks Like in 2026

The state of the art in this field is not a better discrete-log solver -- no such thing exists. It is a deployment discipline at the three layers the math never controlled. Here it is, pillar by pillar.

Nonce: two orthogonal cures, and a primitive that folds in both

Derive the nonce `k` deterministically from the private key and the message hash via an HMAC-based construction, so the signer "do[es] not need access to a source of high-quality randomness" [@rfc6979]. Identical key-and-message pairs always yield the same `k`; distinct messages yield unrelated nonces. This closes the *generation* defect -- the PS3 and Android reuse classes cannot occur.

RFC 6979 also quietly records the deeper lesson. It insists on comparing each candidate nonce against the group order rather than reducing it modulo the order, warning that a "simple modular reduction would induce biases that would be detrimental to signature security" [@rfc6979]. That is a standards document, in 2013, acknowledging that bias, not just reuse, is fatal. You can watch the effect yourself:

{// A raw sampler emits values in [0, 256). We need a nonce in [0, q). const q = 200n, B = 256n, trials = 400000; const raw = () => BigInt(Math.floor(Number(B) * Math.random())); let biasedHigh = 0, fairHigh = 0; const half = q / 2n; for (let i = 0; i < trials; i++) { const reduced = raw() % q; // reduce mod q -> BIASED if (reduced >= half) biasedHigh++; let fair; do { fair = raw(); } while (fair >= q); // compare to q, retry -> FAIR if (fair >= half) fairHigh++; } console.log('reduce mod q -> P(nonce in top half): ' + (biasedHigh / trials).toFixed(4)); console.log('compare to q -> P(nonce in top half): ' + (fairHigh / trials).toFixed(4)); console.log('That gap from 0.5 is a free bit for a Hidden Number Problem attacker.');}

Determinism, though, fixes only generation. On hardware it also adds a risk.

Compute the nonce from the private key, the message hash, *and* a few bytes of fresh randomness. A dead RNG falls back to the safe deterministic core; a differential fault, which needs two identical signings to differ, is defeated by the fresh input. FIPS 186-5 recommends this for hardware because bare determinism is "of particular concern for ... deterministic signature schemes, as well as embedded or IoT devices and smartcards" [@fips-186-5]. Compute `kG` with a data-independent trace of instructions, branches, and memory accesses, so the runtime never depends on the bit-length or value of `k`. This is the *usage* cure -- the only defense against Minerva, TPM-Fail, and LadderLeak, whose leaks all live in the multiplication, not the sampler. Its precursor is Brumley and Tuveri's 2011 remote attack on a non-constant-time OpenSSL ladder [@brumley-tuveri-2011].

Note: Hedged signing and constant-time multiplication are the two cures of the fork, and they do not substitute for each other. A hardware signer needs both: hedge the generation, and make the usage constant-time. Checking one box leaves the other break wide open.

New designs can sidestep the whole fork by choosing a misuse-resistant primitive. Ed25519 (RFC 8032) derives its nonce as a hash of the secret and message -- deterministic by construction, no per-signature RNG -- and signs with a single complete, constant-time addition law that has no exceptional cases to mishandle [@rfc8032]. It folds both cures into the primitive and removes the dangerous choices from the caller's hands.Misuse-resistant is not misuse-proof. PuTTY derived P-521 ECDSA nonces such that "the first 9 bits of each ECDSA nonce are zero," allowing "full secret key recovery in roughly 60 signatures" (CVE-2024-31497) [@putty-cve-2024-31497]. Determinism implemented carelessly re-introduced exactly the bias it was meant to prevent.

Validation: reject what you cannot vouch for

The CurveBall cure is direct: bind a certificate's curve to the standard parameters of its named curve, and reject explicit parameters or fully re-validate them. The January 2020 patch made crypt32.dll check the generator, not merely the point [@curveball-cve-2020-0601].

For key exchange with static keys, the discipline is fuller. Before using a received point, confirm it is not the identity, lies on the curve, and sits in the correct prime-order subgroup -- the full public-key validation of NIST SP 800-56A, which blocks invalid-curve and small-subgroup attacks that would otherwise bleed a static key out one query at a time [@sp-800-56a-r3].

The most durable answer is to make invalid inputs unrepresentable. X25519 works on a Montgomery curve chosen so that every 32-byte string is an acceptable public key; the RFC even instructs implementations to "accept non-canonical values," and to run the conditional swap "in constant time" [@rfc7748]. There is no explicit-parameter path to abuse and no on-curve check to forget.This is the "make invalid states unrepresentable" principle applied to cryptography: the safest validation code is the code you deleted because the type system already guarantees the property. But note the boundary carefully.

Note: X25519's scalar "clamping" fixes the cofactor and twist problems for ephemeral key exchange. It does not replace named-curve pinning in the X.509 world, and some protocols still need a contributory-behavior check on the shared secret. Twist-secure curves solve the problems they were designed for -- not every parameter problem.

Negotiation: remove the weak option entirely

The downgrade pillar's fix is structural. RFC 7919 replaced ad-hoc, shared Diffie-Hellman primes with a menu of vetted named groups negotiated like curves [@rfc7919]. TLS 1.3 went further and deleted the weak options outright, so there is nothing to downgrade to.

"Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy." -- RFC 8446, the TLS 1.3 specification [@rfc8446].

Because TLS 1.3 permits only strong ephemeral groups and binds the negotiation into the handshake transcript, the Logjam rewrite is not merely discouraged -- it is structurally impossible [@rfc8446]. The end state of the negotiation pillar is a protocol in which the crippled, shared 512-bit group Logjam relied on simply cannot be selected.

Each of these is a choice, and where there is a choice, engineers argue. Which discipline actually wins in which threat model?

7. Competing Approaches: Which Defense Answers Which Adversary

These defenses are not rungs on one ladder. They are answers to different adversaries, and the honest way to compare them is one pillar at a time.

Note: A constant-time multiplier and a named-curve pin do not compete -- they defend different layers, and a real system needs one from each pillar. The comparisons below rank options within a pillar. Picking the best nonce discipline does nothing for your parameter validation.

Nonce: which signing discipline stops which adversary

The load-bearing insight is that no single column stops every row. Generation cures (deterministic [@rfc6979], hedged [@fips-186-5]) and the usage cure (constant-time) are orthogonal, which is why hedged-plus-constant-time became the practitioner default and why Ed25519 [@rfc8032] folds most of both into the primitive.

Adversary / failure	Randomized (bare RNG)	Deterministic (RFC 6979)	Hedged (FIPS 186-5)	Constant-time mult	Ed25519
RNG returns constant or repeat (PS3, Android)	fails	stops	stops	orthogonal	stops
Differential fault on a deterministic signer	randomness helps	fails	stops	orthogonal	inherits the caveat
Timing leak of nonce bit-length (Minerva, TPM-Fail)	fails	fails	fails	stops	stops (uniform ladder)
Sub-bit ladder leak (LadderLeak)	fails	fails	fails	stops	stops (uniform ladder)

Read the rows, not the columns: reuse fails only the first row and is certain from two signatures; the timing leaks fail three of the five columns and are cured on a different axis entirely. That is the two-cures fork, rendered as a matrix.

Validation: three philosophies of not trusting your input

Dimension	Named-curve pinning	Full validation (SP 800-56A)	All-inputs-valid (X25519)
Philosophy	reject non-standard parameters	validate every received input	make invalid inputs unrepresentable
Stops CurveBall (unvalidated generator)	yes, its exact fix	yes, re-derives the generator	yes, no explicit-parameter path
Stops invalid-curve / small-subgroup	partial	yes, on-curve plus subgroup	yes, twist-secure
Per-operation cost	O(1) table compare	O(1) up to one scalar mult	one constant-time ladder
Best suited for	X.509, code-signing, PKI	static-key ECDH, HSMs	ephemeral ECDH

Named-curve pinning is the precise CurveBall fix [@curveball-cve-2020-0601]; SP 800-56A validation is the belt-and-suspenders choice for static keys [@sp-800-56a-r3]; X25519 deletes the problem by construction [@rfc7748]. They converge on stopping CurveBall and diverge on everything else.

Downgrade: hardening, deletion, or hedging against tomorrow

Dimension	Config hardening + FFDHE	TLS 1.3	Hybrid post-quantum
Removes the 512-bit export rung	yes, within FFDHE	yes, structurally	yes, inherits 1.3
Removes shared or unknown primes	yes, named menu	yes, fixed groups	yes
Downgrade protection in the handshake	no, still in-band	yes, transcript-bound	yes
Defends against a future Shor adversary	no	no	yes, if ML-KEM holds
Residual weakness	the legacy long tail	non-TLS 1024-bit primes	a KEM is not a NIKE, young PQC

RFC 7919 named groups [@rfc7919] are the transitional hardening for TLS 1.2; TLS 1.3 is the structural end state [@rfc8446]; hybrid X25519 with ML-KEM (RFC 9954 [@rfc9954], ML-KEM standardized as FIPS 203 [@fips-203]) is the forward hedge against a quantum adversary. Only the last column defends against a break that would be genuine mathematics rather than a deployment slip.

Every column in every table changed the deployment, not the curve. So is the discrete log itself simply unbreakable? Almost -- and the "almost" is the most honest paragraph in this article.

8. Theoretical Limits: What Is Provably True on Both Sides

This is the honest concession the thesis has been earning the right to make. There are two provable sides here, and the argument needs both.

The hardness side: no room for a strong curve to fall

On a well-chosen group, the discrete logarithm is genuinely hard, and we can say so with unusual precision. The best classical attack is Pollard's rho, a square-root-time random walk that needs negligible memory [@teske-2001]. In the strict generic model its expected cost is about $\sqrt{\pi n/2}$, roughly 1.25 times $\sqrt{n}$ group operations; on an elliptic curve, the negation map (where $P$ and $-P$ share an x-coordinate) trims that to about 0.886 times $\sqrt{n}$. Either way the exponent is the same, matching baby-step giant-step's $O(\sqrt{n})$ time [@hac-ch11].

Against that upper bound, Shoup proved a generic lower bound of $\Omega(\sqrt{p})$: no algorithm restricted to the group operation can do better [@shoup-1997]. The two meet at $\Theta(\sqrt{n})$. The generic gap is essentially closed -- which is exactly why a 256-bit curve delivers around 128-bit security, and why no strong deployed curve's discrete log has fallen.

Quantity	Value	Note
Best classical DL attack	Pollard's rho, about 1.25 times sqrt(n) generic; 0.886 times sqrt(n) on curves	negligible space
Baby-step giant-step	O(sqrt(n)) time and O(sqrt(n)) space	the space-heavy twin
Generic lower bound	Omega(sqrt(p)), provably no faster generic algorithm	Shoup 1997
Finite-field DH (non-generic)	sub-exponential via the number field sieve	why DH needs about 3072-bit primes (2048-bit minimum)
Strong deployed curve or standard group ever solved	none, only Logjam's crippled shared 512-bit prime	the thesis in one row

The last two rows carry the concession. Finite-field Diffie-Hellman is not generic: the number field sieve solves it in sub-exponential time, which is why finite-field DH needs primes of about 3072 bits to match the security a 256-bit curve gives (2048 bits is the absolute minimum), and why Logjam's downgrade to 512 bits was finishable at all [@logjam-weakdh-2015]. The number-field-sieve mathematics belongs to the companion article.

Key idea: Logjam is the only break in this corpus that reached the mathematics, and the reason is structural, not accidental. A finite field carries extra arithmetic structure that a generic group lacks, which lets the number field sieve run in sub-exponential time, faster than the square-root barrier that protects a strong elliptic curve. That structural gap is the sole opening the discrete log ever offered, and even it was not enough alone: the computation became feasible only after the prime was cut to 512 export-grade bits. Raise the group back to a standard 2048-bit prime, or move to a curve where no such shortcut exists, and the opening closes.

The leakage side: no room to hide a little bias

The other provable side indicts the deployment just as sharply. The Hidden Number Problem makes partial leakage fatal by construction: Boneh and Venkatesan proved that recovering a secret from many small most-significant-bit leaks is tractable [@boneh-venkatesan-1996], and Nguyen and Shparlinski turned that into a working lattice attack on (EC)DSA with partial nonces [@nguyen-shparlinski-2003].

There is no "a little bias is tolerable" regime: any consistent partial leak of k, integrated over enough signatures, provably recovers d. Two or more leaked bits fall to a lattice; a sub-bit leak falls to Bleichenbacher's Fourier method [@ladderleak-2020]. "k is secret, uniform, and unique" is not a best practice -- it is a hard boundary.

Note: The math is safe at the sizes we deploy (the generic gap is closed), and leakage is fatal at any size (the HNP admits no safe margin). Both proofs point the same way: the primitive is not the weak part. The nonce, the parameters, and the negotiation are.

Two clouds sit on the horizon. First, the shared-prime structure Logjam exploited at 512 bits revives at 1024. The Logjam team estimated that precomputing the single most common 1024-bit prime would expose roughly 18% of the top HTTPS sites; a second common prime would reach about 66% of IPsec VPNs and around 26% of SSH servers [@logjam-weakdh-2015] -- the same trick, resized, and a resourced adversary's project. Second, a large fault-tolerant quantum computer running Shor's algorithm would break the discrete logarithm outright, curve and finite field alike. That is the one future break that *is* the mathematics, and it is the subject of the companion article, not this one. The deployment answer, already shipping, is hybrid key exchange.

So where, concretely, does EC and DH still break tomorrow?

9. Where EC and DH Still Break in the Field

The incidents are settled. The classes are not. Every open problem below is a documented pattern waiting for its next instance, and each one maps to a pillar you have already met.

The next SecureRandom (nonce generation, Pillar 1). A signer needs a unique, secret nonce at the exact moment its entropy is weakest: first boot, a headless IoT device with no entropy events, or a freshly cloned virtual machine carrying a duplicated seed. This is the mechanism behind Android 2013 [@android-securerandom-2013], and it recurs whenever hardware is provisioned faster than it can gather randomness.Cloned-VM state duplication is an especially nasty modern form: two hosts that never coordinated can emit the same "random" nonce because they booted from one snapshot. The signing path can be hedged [@fips-186-5], but key generation and ephemeral key exchange still need a live, well-seeded source.

The next Minerva or LadderLeak (nonce usage, Pillar 1). Constant-time scalar multiplication must be re-established against every new microarchitecture -- caches, execution ports, prefetchers, simultaneous multithreading -- and on every fragile incomplete-addition curve. The bit-length leak of Minerva [@minerva-2020] and the sub-bit leak of LadderLeak [@ladderleak-2020] both post-date deterministic nonces precisely because the leak had moved to usage. Formally verified primitives close the known channels on the chosen curve; FIPS-mandated P-curves and secp256k1 keep hand-written code in production.

The long tail of shared primes (downgrade, Pillar 3). TLS 1.3 closes the web protocol layer, but export-grade and shared standardized primes outlived their policy elsewhere. IKEv1 VPNs and older SSH still ship shared 1024-bit Diffie-Hellman groups, and a single precomputation per shared prime amortizes across every server using it [@logjam-weakdh-2015]. The consensus recommendation is blunt: retire 1024-bit DH now.

The next CurveBall (validation, Pillar 2). CurveBall was one unchecked generator in one library [@curveball-cve-2020-0601]; the class is "somewhere in a large validation stack, attacker-supplied parameters are trusted." Every new parser, certificate profile, or post-quantum key format reopens the class, and a single such bug in a widely embedded validator forges trust across everything that depends on it.

Post-quantum migration ahead of Shor (cross-pillar). Hybrid key exchange -- running X25519 alongside ML-KEM so the session stays secure if either component holds -- is standardized (RFC 9954 [@rfc9954]; concrete groups such as X25519MLKEM768 in the ongoing ECDHE-MLKEM work [@draft-ietf-tls-ecdhe-mlkem]; ML-KEM standardized as FIPS 203 [@fips-203]) and is already deployed at scale: it protected a majority of the human web traffic Cloudflare measured by late 2025 [@cloudflare-pq-radar]. But the migration carries a trap that has nothing to do with the discrete log.

Note: ML-KEM is a key-encapsulation mechanism, not a non-interactive key agreement. It does not reproduce X25519's static Diffie-Hellman semantics, where two long-term public keys combine without any live exchange. Systems that quietly assume "post-quantum DH" is a drop-in replacement for classical DH will find the shape of the primitive has changed underneath them. Migrate deliberately, not by search-and-replace.

None of these needs new mathematics to break you. Each needs exactly one deployment mistake. Here is how not to make it.

10. What to Do on Monday

Every item below maps to a specific incident in this article. Do these, and you do not ship the next one.

Never put a bare runtime RNG in the signing path. Use deterministic (RFC 6979 [@rfc6979]) or, on hardware, hedged (FIPS 186-5 [@fips-186-5]) nonces. Prevents: PS3, Android.
Demand constant-time, exception-free scalar multiplication. This is a separate control from the nonce discipline, not a duplicate of it. Prevents: Minerva, TPM-Fail, LadderLeak.
Prefer misuse-resistant primitives. Ed25519 for new signing [@rfc8032], X25519 for ephemeral key exchange [@rfc7748]; for static-key ECDH, run full public-key validation per SP 800-56A [@sp-800-56a-r3]. Prevents: whole classes of implementer error.
Reject explicit curve parameters; require named curves. Pin the curve, and the generator with it. Prevents: CurveBall [@curveball-cve-2020-0601].
Disable export ciphers and use vetted groups. RFC 7919 named groups [@rfc7919] for residual TLS 1.2 DHE, or move to TLS 1.3 [@rfc8446]. Prevents: Logjam.
Never assume a fresh ephemeral rescues a shared prime. The number-field-sieve precomputation is per-prime, not per-connection [@logjam-weakdh-2015]. Prevents: the subtle half of Logjam.
Plan the post-quantum migration as hybrid, not pure. Run a classical curve alongside ML-KEM (RFC 9954 [@rfc9954]); remember a KEM is not a NIKE. Prevents: harvest-now-decrypt-later exposure.

Note: New signing design, free to pick the curve: Ed25519. Must use ECDSA on a NIST or secp256k1 curve: hedged RFC 6979 and a vetted constant-time multiply. Hardware or embedded signer: hedged, never bare-deterministic. Ephemeral key exchange: X25519. Static-key ECDH: full SP 800-56A validation. Certificate or PKI validation: pin named curves. Any TLS: version 1.3, and if you are stuck on 1.2 DHE, RFC 7919 groups with export ciphers off. Long-lived confidentiality: hybrid X25519 with ML-KEM.

1. **Nonce:** For every signature, can you show the nonce is both unpredictable (hedged or deterministic) *and* consumed in constant time? If you can only answer one half, you are exposed to the other. 2. **Parameters:** Does your certificate and key-exchange path reject attacker-supplied explicit parameters and validate every received point against the named curve? 3. **Negotiation:** Can a man-in-the-middle force any weaker group or version than you intend? If you cannot prove "no," assume "yes."

Notice that not one item on this list is "use a bigger curve." For every break except Logjam's downgrade, key size is irrelevant -- a 384-bit curve reuses a nonce exactly as fatally as a 256-bit one. The controls are about generation, usage, validation, and negotiation, because those are the four contracts, and the contracts are where reality broke.

Two questions decide whether you got this right, and they happen to be the two most-repeated errors in the field.

11. FAQ: Misconceptions, Precisely Corrected

Once, and only against a deliberately crippled target. Logjam computed discrete logarithms against a 512-bit export-grade Diffie-Hellman prime -- one that a man-in-the-middle downgrade could select and that many servers had in common [@logjam-weakdh-2015][@cve-2015-4000]. No strong deployed curve -- P-256, Curve25519, secp256k1 -- and no standard-sized group of 2048 bits or more has ever had its discrete log solved in public. The ceiling of the entire corpus is a 512-bit prime that policy left broken. No, and this is the most common error. A *repeated* nonce recovers the key with certainty from exactly two signatures, by elementary algebra. A merely *biased* nonce emits only a faint statistical signal per signature, so recovery takes many of them plus a dedicated lattice or Fourier attack -- about 2100 for Minerva on secp256r1 [@minerva-2020], roughly 60 for PuTTY's nine-zero-bit bias [@putty-cve-2024-31497]. One biased signature leaks almost nothing. No. LadderLeak's leak is under a single bit per signature, which lattice methods cannot exploit; it revives Bleichenbacher's Fourier-analysis solver instead [@ladderleak-2020]. The lattice regime is Minerva and TPM-Fail, whose leaks are two bits or more [@minerva-2020][@tpmfail-2020]. Calling all three "lattice attacks" collapses a distinction the attacks themselves are built on. No. Padding oracles are an RSA and CBC-mode phenomenon; there is no elliptic-curve or Diffie-Hellman padding-oracle exemplar, and you should not go looking to manufacture one. The EC and DH attack surface is exactly the three pillars here -- the nonce, parameter validation, and downgrade. RSA's padding oracles, and the fact that RSA signing has no per-signature secret nonce to reuse, are covered in the companion piece "How RSA Breaks in Real Life." Only against half the problem. RFC 6979 removes the random number generator from the signing path and eliminates the reuse class [@rfc6979], but it does nothing about a timing leak during nonce *usage* -- which is exactly how Minerva, TPM-Fail, and LadderLeak recovered keys from deterministic signers. The complete answer is hedged signing plus constant-time scalar multiplication [@fips-186-5], the two orthogonal cures. Almost never. The nonce, validation, and downgrade defects are all indifferent to key size: a forged CurveBall certificate is accepted no matter how large the curve is, because the flaw is a skipped generator check rather than a hard curve [@curveball-cve-2020-0601], and a reused or leaked nonce surrenders the private key whether that key is 256 or 384 bits. The one place size mattered was the export-group downgrade, and there the fix was to stop negotiating the 512-bit group at all [@logjam-weakdh-2015], not to enlarge it. The primitive, no. The discrete logarithm on a strong group remains as hard as it was in the 1970s. What broke, repeatedly, was the deployment around it. Fix the nonce path, validate your parameters against named curves, and retire export and shared groups, and you have closed every break in this article. CurveBall was a validation bug, not a curve break [@curveball-cve-2020-0601] -- and that distinction is the whole point.

Half a century after Diffie and Hellman reduced key exchange to one hard problem, the scoreboard is unambiguous: seven documented field breaks across three deployment layers, and a discrete-log ceiling that only ever reached a deliberately crippled, shared 512-bit export group -- never a strong deployed curve, never a standard-sized group. The mathematics kept its promise. The deployments did not.

The discrete log never fell. The nonce did, the parameters did, and the negotiation did -- and every one of those is the deployment's job, not the curve's.

For the other half of the story -- how a curve itself could be structurally weak, how the number field sieve and Shor's algorithm actually break the math -- see the structural companion, "How the Discrete Log Would Break." For the primitive that has no per-signature nonce to reuse and its own padding-oracle history, see the series sibling, "How RSA Breaks in Real Life." This article was about the gap between a hard problem and a shipped product. That gap is where the keys keep getting out.

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.

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.

Nobody Broke the Discrete Log: A Field Guide to Diffie-Hellman and Forward Secrecy

noreply@paragmali.com (Parag Mali) — Mon, 13 Jul 2026 02:35:50 GMT

**Diffie-Hellman's hardness -- the discrete logarithm -- has held for fifty years and almost never breaks in the field.** What breaks is one of four conditions the caller must supply, plus one discipline beneath them all.

Forward secrecy needs a genuinely fresh ephemeral: reuse it and the property silently evaporates, which is why the paper that named the problem is titled Imperfect Forward Secrecy. The group must be strong and unshared: finite-field DH has a sub-exponential attack whose expensive step depends only on the prime, so millions of servers sharing one 1024-bit prime let a nation-state precompute once and read everyone, while a 256-bit curve escapes this -- which is why X25519 keys are 32 bytes. The peer's public value must be validated: an unvalidated point turns your reused key into a key-extraction oracle, and X25519 makes that check structural through twist security, so clamping is not validation. The exchange must be authenticated: raw DH stops a passive eavesdropper and not an active man-in-the-middle. Beneath all four, the raw shared secret is a group element, not a key: run it through a KDF.

The fifty-year evolution -- finite-field DH in 1976, then elliptic-curve DH, then X25519, then the TLS 1.3 ephemeral mandate, then today's X25519MLKEM768 hybrid -- is one sustained move to bake each condition into the primitive, the named group, and the protocol, so the simple thing to do is the safe thing to do. Every one of these still falls to Shor, which is why ECDH is now being wrapped, not replaced. The math held; the deployment handed the secret away.

1. They Precomputed the Prime Once, and Read Everyone

In 2015 a team of researchers pointed out something that should have been impossible: millions of HTTPS, SSH, and VPN servers were sharing the same handful of 1024-bit Diffie-Hellman primes. That sharing did not merely weaken those servers -- it changed the economics of breaking them. The most expensive step of the best known algorithm for computing discrete logarithms depends only on the prime, not on any particular connection, so an adversary who could afford the precomputation for one common prime could then decrypt, passively and forever, every connection that used it [@weakdh].

Breaking the single most common 1024-bit group would have exposed an estimated 18% of the top million HTTPS sites, and a second common prime an estimated 66% of VPNs [@weakdh]. Nobody had to break the math. They precomputed the prime once and read everyone.

Here is the part that should unsettle you. The people running those servers were not careless. They believed they were doing the one thing everyone agrees you must do: generate a brand-new key for every connection. The researchers put it plainly -- practitioners "believed this was safe as long as new key exchange messages were generated for every connection" -- and they were wrong, because a shared prime and a fresh per-connection secret are two different conditions, and only one of them was being met [@weakdh].

The attack, named Logjam, actually had a second half: an active attacker could force a browser and server to negotiate a deliberately breakable 512-bit "export-grade" group, so that even a modest adversary could solve the discrete log in real time [@weakdh]. Two coupled failures -- a downgrade and a precomputation -- and neither one touched the underlying hardness assumption. That active downgrade even had an exact RSA twin the same year, FREAK, which forced a browser down to breakable 512-bit "export" RSA instead of Diffie-Hellman [@freak]. The paper's title says the whole thing in two words: Imperfect Forward Secrecy.

The math held; the deployment handed the secret away.

This article is about that gap, and about closing it. The security a system actually gets from Diffie-Hellman is never simply "the discrete logarithm is hard." It is a stack of four conditions the caller must independently satisfy -- a genuinely fresh ephemeral secret, a strong and unshared group, a validated peer value, and an authenticated exchange -- plus one discipline underneath them: the raw output is a group element, not a key, so it must pass through a key derivation function.

Every world-scale Diffie-Hellman break you half-remember -- Logjam, small-subgroup key recovery, invalid-curve attacks on TLS, Raccoon, the anonymous man-in-the-middle -- is exactly one of those conditions quietly violated. The same unbroken math spawned a whole catalog of disasters, and the fifty-year history of the primitive is one sustained effort to pull those conditions back inside the primitive, the named group, and the protocol, so that a caller cannot forget them.

To see why a shared prime is a catastrophe -- and why "we generate a fresh key every connection" was true yet still left everyone exposed -- you first have to be precise about what a Diffie-Hellman exchange promises, and the four jobs it quietly delegates to you.

2. What Diffie-Hellman Actually Is, and the Four Things You Must Supply

Two strangers who have never met, standing on either side of a wire the whole world can read, end up sharing a secret that no eavesdropper can compute. That is one of the deepest ideas in computer science, and it hides four decisions the scheme refuses to make for you.

The mechanism, with just enough math

Fix a public group with a generator $g$. Alice picks a secret number $a$ and sends $g^a$; Bob picks a secret $b$ and sends $g^b$. Each raises what they received to their own secret, and because exponents commute, they land on the same value:

$$g^{ab} = (g^a)^b = (g^b)^a.$$

An eavesdropper sees $g$, $g^a$, and $g^b$, but never $a$ or $b$. A student can implement the whole thing in three lines of modular exponentiation.

A protocol in which two parties exchange the public values $g^a$ and $g^b$ over an open channel and each computes the shared secret $g^{ab}$, which an eavesdropper who sees only $g$, $g^a$, and $g^b$ cannot compute.

{// Toy Diffie-Hellman over a tiny prime field. Illustrative sizes, NOT secure. const p = 2147483647n; // a small 31-bit prime; a real DH prime is >= 3072 bits const g = 7n; // a public generator element function powmod(base, exp, m){ let r = 1n; base %= m; while (exp > 0n){ if (exp & 1n) r = (r * base) % m; base = (base * base) % m; exp >>= 1n; } return r; } const a = 1234567n; // Alice's fresh ephemeral secret (never sent) const b = 7654321n; // Bob's fresh ephemeral secret (never sent) const A = powmod(g, a, p); // Alice sends this over the open wire const B = powmod(g, b, p); // Bob sends this over the open wire const secretAlice = powmod(B, a, p); // Alice computes (g^b)^a const secretBob = powmod(A, b, p); // Bob computes (g^a)^b console.log('Alice g^ab =', secretAlice.toString()); console.log('Bob g^ab =', secretBob.toString()); console.log('do they agree? ->', secretAlice === secretBob); // The raw shared value is a group element, NOT a key. Real code never uses it // directly: it feeds g^ab into a KDF (HKDF-SHA256) to extract a uniform key. const toyKey = (secretAlice * 2654435761n) % (2n ** 32n); // stand-in for HKDF only console.log('derived key (toy stand-in) =', toyKey.toString());}

Why it is hard to break

The security rests on the discrete logarithm problem: given $g$ and $g^a$, recover the exponent $a$. In a well-chosen group this is believed intractable.

Given a generator $g$ and an element $g^a$ in a large group, the problem of recovering the exponent $a$. It is believed hard in carefully chosen groups, and it is the foundation Diffie-Hellman rests on.

But hardness of the discrete log is not quite the property we need. Recovering $a$ is the discrete-log problem; computing the shared secret $g^{ab}$ from $g^a$ and $g^b$ without recovering either exponent is the Computational Diffie-Hellman (CDH) assumption, a slightly weaker thing to assume hard. Sharper still: "the shared secret is indistinguishable from a random group element" is the Decisional Diffie-Hellman (DDH) assumption, and it is strictly stronger than CDH [@cryptobook]. The distance between "hard to compute" and "looks random" is exactly why the raw output of the exchange is not yet a key.

CDH is the assumption that computing $g^{ab}$ from $g^a$ and $g^b$ is hard. DDH is the stronger assumption that $g^{ab}$ cannot even be distinguished from a random group element. DDH can fail in groups where CDH still holds, which is why the raw shared value is not treated as a uniform key.

There are real groups -- pairing-friendly elliptic curves -- where DDH is easy even though CDH is plausibly hard, so $g^{ab}$ is computable-hard yet distinguishable from random.This is why "looks random" is the decisional assumption, not the computational one. The one-line consequence, paid off in the forward-secrecy and theory sections, is that you must extract a key from the shared value with a KDF rather than use it raw. Keep that fact in your pocket; it becomes a theorem later.

The thesis, stated as the primitive's interface

Now look at what the exchange quietly assumes but never enforces. Raw finite-field Diffie-Hellman outsources all of the following to the caller, at once:

Freshness. The secret $a$ must be genuinely fresh per session, then destroyed. This is what buys forward secrecy.
A strong, unshared group. The group must be large enough and not shared in a way that lets an attacker amortize work across everyone who uses it.
A validated peer value. The incoming $g^b$ must actually be a well-formed element of the right group, not a hostile input chosen to leak your secret.
Authentication. Something must bind $g^a$ and $g^b$ to identities, or an active attacker sits in the middle.

And beneath all four, a fifth discipline: the raw $g^{ab}$ is a structured group element, not a key, so it must go through a key derivation function before anyone calls it a key [@rfc5869]. The original 1976 construction supplies none of these; it hands you a shared secret and trusts you to remember the rest [@dh1976].

flowchart TD A["Alice: fresh secret a, send g^a"] --> S["Shared value g^(ab)"] B["Bob: fresh secret b, send g^b"] --> S S --> K["KDF turns g^(ab) into a real key"] F1["1. Freshness: is a truly ephemeral and destroyed"] -.-> A F2["2. Strong and unshared group"] -.-> S F3["3. Validate the peer value g^b"] -.-> B F4["4. Authenticate the exchange"] -.-> S

This table is the entire article compressed into a grid: each row a condition, each column showing who historically lifted that burden off the caller. It fills in from left (the caller does everything by hand) to right (the primitive, the named group, or the protocol does it).

Condition	What the caller must supply	Where it eventually gets pulled inside
1. Freshness	A per-session ephemeral secret, destroyed after use	The protocol: TLS 1.3 mandates ephemeral (EC)DHE
2. Strong, unshared group	A large prime or curve nobody can precompute against	The named group: RFC 7919 FFDHE safe primes; strong curves
3. Validated peer value	An on-curve, correct-subgroup public value	The primitive: X25519 twist security; or a hand-written check for classic ECDH
4. Authentication	A signature or MAC binding the transcript to identities	The protocol: STS/SIGMA, then TLS 1.3
5. KDF discipline	Extract a uniform key from the raw shared value	Every modern design: HKDF over the shared secret

Key idea: The security a system gets from Diffie-Hellman is never "the discrete log is hard." It is four conditions the caller must supply -- fresh, strong-and-unshared, validated, authenticated -- and then a KDF beneath them. Every named break in this article is exactly one of those quietly missing.

Note: The raw $g^{ab}$ (or, on a curve, the shared x-coordinate) is a group element, not a key. Run it through a KDF such as HKDF before you ever call it a key. This is the discipline beneath all four conditions, and later it turns out to be a theorem, not a style preference.

Three of those four conditions were not obvious in 1976. Each was discovered the hard way, by a named break. To understand why a fifty-year-old idea still hands them to you, go back to the moment key agreement was only an idea -- an idea that, it turns out, had already been discovered in secret.

3. Where This Came From: 1976, and the Secret That Came First

In 1976 two Stanford researchers opened a paper with a sentence that has aged remarkably well: "We stand today on the brink of a revolution in cryptography" [@dh1976]. Whitfield Diffie and Martin Hellman were right about the revolution. They were also, unknown to them, second.

The problem before the answer

Before public key agreement, two parties who wanted to talk securely had to already share a secret key, delivered out of band -- by a trusted courier, a locked briefcase, a prior meeting. That does not scale. A network of $n$ parties who each want to talk privately needs on the order of $n^2$ pairwise keys, every one of them distributed and stored in advance. The cost of moving keys, not the cost of encryption, is what throttled commercial cryptography for decades.

The public origin

Diffie and Hellman's "New Directions in Cryptography" broke the deadlock. Their key exchange let two parties agree on a shared secret over a channel an adversary could fully observe: fix a public generator $g$ over a finite field, keep the exponents private, exchange $g^a$ and $g^b$, and let both sides compute $g^{ab}$, with security resting on the discrete logarithm modulo a large prime [@dh1976]. The same paper credits Ralph Merkle's independent "puzzles" idea as a partial solution to the same problem, which is the seed of the argument -- pressed for years by Hellman -- that the scheme should be called Diffie-Hellman-Merkle [@dh1976], [@merkle]. Merkle's own framing was that his construction "forces any enemy to expend an amount of work which increases as the square of the work required of the two communicants" [@cacm-merkle].

Merkle conceived his puzzles around 1974 and saw a 1975 write-up rejected; the work was not published until 1978. Yet Diffie and Hellman's 1976 paper already cites it as "submitted to the CACM," which fixed the idea in the literature before its own publication -- part of why Hellman argued for the three-name credit [@merkle].

The classified precursor

Here is the part most textbooks skip. Inside the United Kingdom's signals-intelligence agency, GCHQ, and its information-security arm CESG, the same ideas had already arrived, and stayed locked in a safe. James Ellis conceived what he called "non-secret encryption" at the end of the 1960s -- the recipient, he realized, only needs to be in a different position from the interceptor, not a secret one [@ellis]. Clifford Cocks worked out the trapdoor that we would now recognize as RSA in 1973, and Malcolm Williamson derived the discrete-exponentiation key exchange -- Diffie-Hellman in substance -- in 1974 [@wikipedia-cocks]. All of it remained classified until December 1997 [@wikipedia-cocks].

The counterfactual sharpens the whole thesis of this article. The idea of public key agreement existed inside a government agency and changed nothing about how the world built systems, because it was never published, never standardized, never turned into a named group or a protocol anyone could deploy. An idea that no caller can reach protects no one.

The GCHQ dates are genuinely disputed. Ellis's own account traces the origin only to "the 60's"; the widely repeated "1970" is the date of his internal report. The primary CESG and gchq.gov.uk pages that once hosted this history are gone, so the record here rests on the archived Ellis document plus corroborating biography, not on any live government URL [@ellis], [@wikipedia-cocks].

timeline title From a secret idea to a mandated protocol 1969 : Ellis conceives non-secret encryption inside GCHQ 1974 : Williamson derives DH-style key exchange, kept classified 1976 : Diffie and Hellman publish New Directions, finite-field DH 1985 : Miller proposes elliptic-curve cryptography (Koblitz independently, published 1987) 1992 : Station-to-Station signs the DH values for authentication 2006 : Bernstein publishes Curve25519 and the X25519 function 2015 : Logjam shows shared 1024-bit primes are a mass liability 2018 : TLS 1.3 mandates ephemeral key exchange, removes static DH 2024 : X25519MLKEM768 hybrid ships by default in OpenSSH 9.9

Diffie and Hellman had shown that two strangers could agree on a secret against an eavesdropper who only listens. They said almost nothing about an adversary who acts. That omission is not a flaw in the paper; it is the second of the four conditions, and closing it took another two decades.

4. The Anonymous-DH Gap: Why Raw DH Is Only Half a Protocol

Raw ephemeral Diffie-Hellman defeats a passive eavesdropper completely, and an active attacker not at all. The whole difference is one adversary who can inject packets, and it is the entire reason "just do a DH exchange" is never the whole answer.

The man-in-the-middle, mechanically

Suppose an attacker sits on the wire and can not only read but rewrite. When Alice sends $g^a$ toward Bob, the attacker keeps it and sends its own $g^m$ onward. When Bob replies with $g^b$, the attacker keeps that too and sends $g^m$ back to Alice. Now the attacker shares one secret, $g^{am}$, with Alice, and a different secret, $g^{bm}$, with Bob. It decrypts whatever Alice sends, reads or modifies it, re-encrypts under the Bob-side secret, and forwards. Neither party sees anything wrong: both completed a textbook-perfect exchange. The primitive simply never promised anything about who is on the other end.

sequenceDiagram participant A as Alice participant M as Attacker participant B as Bob A->>M: sends g^a intended for Bob M->>B: substitutes g^m B->>M: sends g^b intended for Alice M->>A: substitutes g^m Note over A,M: Alice agrees on secret g^am with the attacker Note over M,B: Bob agrees on a different secret g^bm Note over M: Attacker decrypts, reads, re-encrypts both directions

This is a design gap, not an implementation bug. It falls to an active adversary specifically; a passive listener still learns nothing.

{// Toy anonymous-DH MITM. Illustrative sizes, NOT secure. const p = 2147483647n, g = 7n; function powmod(base, exp, m){ let r = 1n; base %= m; while (exp > 0n){ if (exp & 1n) r = (r*base) % m; base = (base*base) % m; exp >>= 1n; } return r; } const a = 111111n, b = 999999n; // honest ephemeral secrets const A = powmod(g, a, p); // Alice's message (intercepted) const B = powmod(g, b, p); // Bob's message (intercepted) const m = 424242n; // the attacker's own secret const M = powmod(g, m, p); // the attacker forwards THIS to both sides const aliceSide = powmod(M, a, p); // Alice computes (g^m)^a const attackerA = powmod(A, m, p); // attacker computes (g^a)^m -> equal const bobSide = powmod(M, b, p); // Bob computes (g^m)^b const attackerB = powmod(B, m, p); // attacker computes (g^b)^m -> equal console.log('Alice-attacker secret agrees?', aliceSide === attackerA); console.log('Bob-attacker secret agrees? ', bobSide === attackerB); console.log('Do Alice and Bob share a key?', aliceSide === bobSide); // false // The attacker now holds both session secrets and relays, reading everything.}

A key-agreement protocol that also binds the exchanged public values to identities, so that an active attacker cannot substitute its own values undetected. It is what raw Diffie-Hellman is missing.

The precision that carries the rest of the article

Authentication defeats the active adversary, and only the active adversary. It is orthogonal to the hardness of the group and to input validation. The sections ahead each violate a different condition, and it is tempting but wrong to think a signature would have saved them.

Note: Authentication closes the man-in-the-middle, and only that. It does not make a weak prime strong, an unvalidated point safe, or a reused ephemeral fresh. Those are three other conditions, each with its own catalog of breaks.

The fix, historically

Naming the goal came first. Christoph Guenther's 1989 identity-based key-exchange work is where the term perfect forward secrecy is generally said to first appear, attached to the goal that a compromised long-term key should not expose past sessions [@gunther1989]. Diffie, van Oorschot, and Wiener turned it into a concrete protocol in 1992 with Station-to-Station, which authenticates the exchange by having each side sign the Diffie-Hellman values, and which gave the standard, most-cited formal treatment of the property [@sts1992]. A decade later Hugo Krawczyk distilled the pattern into SIGMA, the "SIGn-and-MAc" template that underlies IKE and, in spirit, the TLS 1.3 handshake; the SIGMA protocols "provide perfect forward secrecy" via a Diffie-Hellman exchange authenticated with digital signatures [@sigma2003]. The authenticated-DH family is treated as standard material in the reference texts [@cryptobook], [@hac].

The coinage is disputed and worth stating carefully: the term "perfect forward secrecy" traces to Guenther (1989/1990), while Diffie, van Oorschot, and Wiener (1992) gave the standard, most-cited formal treatment via Station-to-Station. Present both and pick neither silently [@gunther1989], [@sts1992].

Signing the DH values closes the man-in-the-middle. It does nothing for the group the exchange runs in -- and the original group, the multiplicative integers modulo a prime, turned out to hand the caller two more conditions at once, plus a nation-state-scale way to violate them.

5. Generation 1: Finite-Field DH and the Tyranny of the Shared Prime

Here is the mechanism underneath Logjam, the small-subgroup CVEs, and those 3072-bit key sizes you have wondered about -- and here is why the original finite-field group hands the caller more traps than any generation since.

Finite-field DH, mechanically

Pick a large prime $p$, ideally a safe prime of the form $p = 2q + 1$ with $q$ also prime, and a generator $g$ of the large prime-order subgroup. Alice and Bob exchange $g^a \bmod p$ and $g^b \bmod p$ and compute $g^{ab} \bmod p$. The safe-prime shape is not cosmetic: it forces the cofactor down to 2, leaving only the trivial order-two subgroup (the values $1$ and $p-1$). So a small-subgroup attack can pin a key to at most one bit, which is exactly why an implementation must still reject $0$, $1$, and $p-1$ -- a point that becomes concrete below.

A prime of the form $p = 2q + 1$ where $q$ is also prime. The multiplicative group modulo a safe prime has one large prime-order subgroup of order $q$ and only the trivial order-two subgroup (the values $1$ and $p-1$), a cofactor of 2. That confines any small-subgroup attack to at most one bit, which is why implementations still reject $0$, $1$, and $p-1$.

The cost that shaped everything

Finite-field discrete logs have a sub-exponential attack. Index calculus, and its modern form the number field sieve (NFS), runs in heuristic complexity

$$L_p[1/3,\ (64/9)^{1/3}] = \exp!\left((1.923 + o(1)),(\ln p)^{1/3}(\ln\ln p)^{2/3}\right),$$

far faster than brute force. The practical consequence: to reach roughly 128-bit security you need a 3072-bit prime, an order of magnitude larger than the 256-bit curve that buys the same margin [@sp80057]. That size penalty is the whole reason finite-field DH lost.

The best known sub-exponential algorithm for factoring and for finite-field discrete logarithms. Its most expensive stage depends only on the modulus (the prime), not on any individual target, which is why a shared prime is a shared weakness.

Logjam, in full

That "depends only on the prime" clause is the entire disaster. The NFS's expensive first step "is dependent only on this prime," so if millions of hosts share a handful of 1024-bit primes -- and in 2015 they did -- an adversary precomputes once and then decrypts every connection on that prime cheaply, passively, and indefinitely [@weakdh]. The Logjam researchers estimated that breaking the single most common 1024-bit prime would expose about 18% of the top million HTTPS sites, and a second common prime about 66% of VPNs and 26% of SSH servers [@weakdh]. And there was an active half: an attacker could downgrade a TLS handshake to 512-bit DHE_EXPORT parameters, which were breakable in near-real time, with 8.4% of the top million initially vulnerable [@weakdh].

The paper priced that precomputation directly, and the numbers are the point. Breaking a 512-bit export prime was demonstrated, not merely estimated: about 89,000 core-hours of work -- "slightly over one week" of wall-clock time spread across a couple of thousand cores -- after which each individual discrete log took a median of 70 seconds [@weakdh]. A 768-bit prime was an academic reach at roughly 36,500 core-years. And a 1024-bit prime was a nation-state one at roughly 45 million core-years of one-time precomputation, a figure the authors judged "not necessarily out of reach for a nation state" [@weakdh]. Every number there is a fixed, per-prime cost that reading one more connection barely adds to.

flowchart TD P["One shared 1024-bit prime"] --> NFS["NFS first step: precompute per prime, about 45M core-years at 1024-bit, done once"] NFS --> DB["Reusable precomputation for that prime"] DB --> D["Per-connection descent: about 70 s at 512-bit"] D --> R["Passively decrypt every session on that prime"] P -.-> X["Active downgrade to 512-bit export group"] X --> R

Notice what never happens in that diagram: nobody solves a fresh discrete logarithm. The costly work is done once, against the prime, and amortized across everyone who shares it.

Practitioners "believed this was safe as long as new key exchange messages were generated for every connection" -- and were wrong.

They were wrong because a fresh per-connection secret satisfies the freshness condition while doing nothing about the unshared-group condition. Both had to hold; only one did [@weakdh].

Key idea: The attacker never computed a fresh discrete logarithm. They precomputed the shared prime once and read everyone on it. The math held; the deployment handed the secret away.

The RSA twin, in one breath

Logjam did not travel alone. The same year, and the same relic of 1990s U.S. export-crypto policy, produced its RSA counterpart: FREAK, for "Factoring RSA Export Keys," publicly disclosed on 3 March 2015 by Karthikeyan Bhargavan and the miTLS team, with the client-side flaw tracked as CVE-2015-0204 [@freak]. A man-in-the-middle downgrades a client to 512-bit export RSA, factors that small modulus cheaply on rented hardware, and reads the session. At disclosure 36.7% of HTTPS servers with browser-trusted certificates still accepted export RSA -- falling to 6.5% as patches landed -- along with 8.5% of the Alexa Top-1M [@freak].

FREAK downgrades RSA key transport and is fundamentally an implementation bug, a client-side state-machine slip that accepts a key it never asked for; Logjam downgrades Diffie-Hellman parameters and is, in the weakdh.org authors' own words, "due to a flaw in the TLS protocol rather than an implementation vulnerability" [@weakdh]. RSA key transport is the RSA installment's territory, so FREAK stays a mention -- but it is proof that the export-downgrade wound had two matching edges, one for each key-exchange family.

Two precisions to keep straight. First, Logjam is two coupled failures, not one: the 512-bit export downgrade and the shared-prime precomputation. Second, FREAK is its RSA sibling, not the same attack -- both weaponize leftover 512-bit export keys, but FREAK is an implementation bug in RSA key transport while Logjam is a protocol flaw in Diffie-Hellman parameter negotiation [@weakdh], [@freak].

Small-subgroup confinement

The safe-prime rule has teeth. If $p$ is not a safe prime, the group has small subgroups, and an attacker can weaponize them. The attacker sends a carefully chosen element of small order $r$ as its "public key." The victim raises it to its private exponent $x$, producing an element that depends only on $x \bmod r$, and the attacker -- watching whether the handshake succeeds, or reading the resulting ciphertext -- recovers $x \bmod r$ by trying the $r$ possibilities. Repeat across several small factors and combine with the Chinese Remainder Theorem, and the private exponent falls out.

This is the small-subgroup confinement attack of Lim and Lee (CRYPTO '97), and it works only when the victim reuses the private exponent long enough to be probed [@limlee1997], [@twist]. It went live as CVE-2016-0701, where OpenSSL failed to run the subgroup check on X9.42-style (RFC 5114) non-safe-prime parameters while reusing a DH key, letting an attacker "discover a private DH exponent" [@openssl-cve], [@nvd-0701].

An attack that sends a small-order group element as a public key so that the victim's response depends only on the private exponent reduced modulo a small number. Repeating across several small factors and applying the Chinese Remainder Theorem recovers a reused private exponent.

{// A NON-safe prime: p is prime but p-1 = 2^3 * 13 * 19 * 53. Insecure sizes. const p = 104729n; const g = 12n; // a generator of the full multiplicative group function powmod(b, e, m){ let r = 1n; b %= m; while (e > 0n){ if (e & 1n) r = (r*b)%m; b = (b*b)%m; e >>= 1n; } return r; } const x = 8675n; // Bob's REUSED private exponent -- the fatal choice const smalls = [13n, 19n, 53n]; // small prime factors of p-1 const residues = []; for (const r of smalls){ const h = powmod(g, (p - 1n) / r, p); // an element of small order r const target = powmod(h, x, p); // the victim returns h^x = h^(x mod r) let e = 0n; for (let k = 0n; k < r; k++){ if (powmod(h, k, p) === target){ e = k; break; } } // tiny search residues.push([r, e]); console.log('recovered x mod ' + r + ' = ' + e); } // Combine the residues with the Chinese Remainder Theorem: let Mtot = 1n; for (const r of smalls) Mtot *= r; let X = 0n; for (const [r, e] of residues){ const Mi = Mtot / r; let inv = 1n; for (let k = 1n; k < r; k++){ if ((Mi * k) % r === 1n){ inv = k; break; } } X = (X + e * Mi * inv) % Mtot; } console.log('reconstructed private exponent x = ' + X + ' (true value ' + x + ')');}

Keep this attack distinct from the one in the next section. This is small-subgroup confinement: one group, a low-order element, Lim-Lee 1997, on finite fields. The invalid-curve attack of Section 6 uses many curves and an off-curve point, Biehl-Meyer-Mueller 2000, on elliptic curves. They are routinely conflated and they are not the same [@twist].

The fix: take "which prime" away from the caller

The response was to stop letting callers choose primes. RFC 7919 defines a fixed menu of named FFDHE groups (ffdhe2048 through ffdhe8192), every one a safe prime, so a custom, shared, weak, or backdoored modulus is simply not expressible on the wire [@rfc7919]. That is condition #2 pulled inside a named group.

Why take the choice away so completely? Because a caller-chosen modulus can fail in a way no inspection reveals. In early 2016 the socat networking tool was found to have shipped a hard-coded 1024-bit Diffie-Hellman p parameter that was not prime at all, making a key exchange weaker than one over a genuine prime [@socat-secadv7]. The advisory (MSVR-1499) is worth quoting for its candor: because "there is no indication of how these parameters were chosen, the existence of a trapdoor ... cannot be ruled out" [@socat-secadv7].

The repair generated a fresh 2048-bit prime with OpenSSL's dhparam, and the flaw was reported by Santiago Zanella-Beguelin -- a Logjam co-author -- together with Microsoft Vulnerability Research [@socat-secadv7]. A bring-your-own modulus can be weak or backdoored, and you cannot tell which by looking at it. That single degree of freedom is exactly what named safe-prime groups take away.

Note: Do not generate or ship a custom finite-field DH prime, and never one below 2048 bits. A custom modulus can be weak or even backdoored and you cannot tell by looking -- in 2016 socat shipped a 1024-bit "prime" that was not prime at all. Use a named safe-prime group (ffdhe3072 or larger), or, better for most new work, move to a curve.

The number field sieve has an expensive precomputation stage whose cost "is dependent only on this prime," followed by a cheap per-target descent [@weakdh]. So the marginal cost of reading one more connection on a broken prime is tiny; the fixed cost is paid once. When a handful of 1024-bit primes cover a large fraction of the internet, that fixed cost buys mass surveillance: the single most common prime makes roughly 18% of top HTTPS sites readable, and a second prime roughly 66% of VPNs [@weakdh].

The Logjam paper put a concrete price on the 1024-bit precomputation, and it lands squarely in nation-state territory. Roughly 45 million core-years of one-time work is "a huge computational effort," the authors wrote, but "not necessarily out of reach for a nation state": about $8 million of custom ASIC hardware would buy enough capacity to finish the sieving stage in a year, and the linear-algebra hardware was estimated "plausibly on the order of hundreds of millions of dollars" -- on general-purpose machines, the Titan supercomputer's cores would need 117 years for that stage alone [@weakdh].

Set that against the roughly $10.5 billion the paper cites for the NSA's 2012 consolidated cryptologic-program budget, and the arithmetic is uncomfortable [@weakdh]. As a public, measured front-door datapoint for the same algorithm one size down, the RSA-250 factoring record fell to the number field sieve in February 2020 at a cost of about 2,700 core-years, so the 1024-bit discrete-log estimate extrapolates a demonstrated technique rather than a hypothetical one [@rsa250].

Two conditions leaked at once here: the group was neither strong-per-bit nor unshared, and a reused key turned the exchange into an oracle. The obvious escape is a group where the discrete log is harder per bit and there is no cheap shared-prime precomputation. That group is an elliptic curve -- and it introduced a sharper oracle of its own.

6. Generation 2: Elliptic-Curve DH, and the New Oracle

Move the same Diffie-Hellman protocol onto an elliptic curve and the number field sieve vanishes. A 256-bit key now buys what a 3072-bit prime bought. But the smaller, structure-free group sharpened one of the four conditions into a live, key-recovering oracle.

ECDH, mechanically

The curve internals belong to the elliptic-curves installment of this series; here we only need the shape. Replace "exponentiate $g$" with "scalar-multiply the base point $G$": a private key is a scalar $d$, the public key is the point $Q = dG$, and the shared secret is the point $d_A d_B G$, from which both sides take the x-coordinate [@sp80056a]. The payoff is in the attack cost. On a strong curve the best known attack is the generic Pollard rho algorithm, running in about $\sqrt{n}$ steps with no sub-exponential index calculus available, so a 256-bit curve delivers roughly 128-bit security -- concretely, rho against P-256 costs about $2^{127.8}$ operations [@rho]. Victor Miller and Neal Koblitz independently proposed elliptic-curve cryptography in the mid-1980s for exactly this reason [@miller1985], [@koblitz1987].

The new failure class

The smaller group came with a sharper edge. The peer's point is attacker-controlled, and the standard scalar-multiplication formulas "do not involve the constant coefficient $b$" of the curve equation [@twist]. So if an attacker submits a point that satisfies everything except lying on the intended curve, the victim's arithmetic processes it without complaint -- effectively doing the computation on a different, weaker curve whose group has small subgroups. Scalar-multiplying such a point by a reused private key turns the operation into a key-extraction oracle, one small residue at a time, combined with the Chinese Remainder Theorem across many curves. This is the invalid-curve attack of Biehl, Meyer, and Mueller (CRYPTO 2000) [@bmm2000], [@twist]. Jager, Schwenk, and Somorovsky made it practical against real TLS servers doing static or reused ECDH at ESORICS 2015, recovering the server's private key [@jss2015].

An attack that submits a point lying on a different, weaker curve than the intended one. Because scalar-multiplication formulas ignore the curve's constant term, the victim computes on the wrong curve and, if it reuses its private key, leaks that key one small residue at a time. flowchart TD A["Attacker sends a point not on the intended curve"] --> B["Scalar multiply ignores the curve constant b"] B --> C["Computation lands in a weak subgroup of another curve"] C --> D["Reused key leaks d modulo a small order"] D --> E["Repeat across many curves, then CRT to the full key d"]

This is the place readers most often blur two attacks, so once more, at the point of maximum confusion: Lim-Lee small-subgroup confinement (Section 5) is finite-field, one group, a low-order element; Biehl-Meyer-Mueller invalid-curve (here) is elliptic-curve, many curves, an off-curve point. And the practical TLS demonstration is Jager-Schwenk-Somorovsky's ESORICS 2015 paper, which is distinct from the same authors' separate USENIX 2015 work [@twist], [@jss2015].

The lesson, made mandatory

For classic cofactor ECDH the caller must validate every incoming point: it has to lie on the intended curve and in the correct prime-order subgroup. NIST SP 800-56A codifies this as full or partial public-key validation [@sp80056a]. It is an explicit, easy-to-forget check the smaller group pushed back onto the implementer -- exactly the caller-facing condition this article tracks.

Note: Reject any peer point that is not on the curve and not in the prime-order subgroup, every time. Miss the check once, on a server that reuses its key, and you have built a private-key-recovery oracle.

A related but separate ECC failure is worth one pointer so you do not file it under the wrong heading: Curveball (CVE-2020-0601) was a certificate-validation bug in Windows CryptoAPI, not an ECDH key-agreement break [@nvd-0601]. Same family of "validate the parameter you were handed," different layer.

So ECDH shrank the key but still demanded a hand-written on-curve check and constant-time code that an implementer could botch. The next move makes both of those unnecessary by construction -- a curve where every 32-byte string is a valid input and the arithmetic is constant-time by design.

7. Generation 3: X25519, or "Make the Simple Implementation the Safe One"

Everything classic ECDH asked the caller to remember -- validate the point, write the arithmetic in constant time -- one curve was designed to make impossible to get wrong. That is the whole point of X25519.

What X25519 is

X25519 is the Diffie-Hellman function over Curve25519, a Montgomery curve over the prime field $p = 2^{255} - 19$, computing x-coordinate-only DH with a uniform Montgomery ladder. Daniel Bernstein introduced it in 2006, and it was standardized as RFC 7748 in 2016 [@ecdh], [@rfc7748]. Two design decisions are the entire construction, and each one pulls a caller-facing condition inside the primitive.

A scalar-multiplication algorithm that processes the secret scalar in a fixed sequence of steps, performing the same field operations at every bit regardless of the secret's value. It computes only the x-coordinate of the result and has no secret-dependent branches.

Constant-time by construction

The ladder is a fixed sequence of roughly 255 iterations, each doing the same field operations no matter what the secret bits are: no secret-dependent branch, no secret-indexed table lookup [@rfc7748]. The timing side channel that a hand-written P-256 ladder can leak simply has no place to live. The primitive absorbed the constant-time requirement so the implementer cannot forget it.

Twist-security

The second decision is subtler and more beautiful. Curve25519 and its quadratic twist both have near-prime order, so an attacker who submits an off-curve x-coordinate does not land in a weak subgroup -- it lands in another strong group where there is nothing to confine a key into. The invalid-curve attack of Section 6 finds no purchase, and it needs no explicit on-curve check to stop it. That is why "the Curve25519 function was carefully designed to allow all 32-byte strings as Diffie-Hellman public keys," and why Bernstein's guidance on validating public keys is, bluntly, "Don't" [@ecdh], [@twist].

A property of a curve whose quadratic twist also has near-prime order. An attacker who supplies an off-curve x-coordinate is forced into another strong group instead of a weak subgroup, so invalid-curve attacks fail without any explicit point validation. flowchart TD In["Any 32-byte peer value, trusted or hostile"] --> L["Montgomery ladder: same steps for every secret bit"] L --> Tw["An off-curve input lands on the twist, another strong group"] Tw --> Out["No weak subgroup to confine a key: validation is structural"] L --> Ct["No secret-dependent branch or lookup: the timing channel is closed"]

Note: X25519 is not merely a faster curve. It takes two conditions that classic ECDH left on the implementer -- validate the input, run in constant time -- and makes them structural properties of the primitive. The safety is by construction, not by discipline. That is the shape of the entire history in miniature.

The two rules that trip people up

Two details cause most X25519 confusion.

First, clamping. Before use, the secret scalar is masked with k[0] &= 248; k[31] &= 127; k[31] |= 64 [@rfc7748]. Clamping constrains your own scalar so your side avoids cofactor and small-order pitfalls. It is emphatically not input validation, and it does nothing to a malicious peer value. X25519 is safe against hostile inputs because of twist security, not because of clamping.

The bit-masking applied to an X25519 secret scalar before use, which fixes certain high and low bits. It shapes your own scalar to sidestep cofactor issues, and it performs no check whatsoever on the peer's public value.

Second, the cofactor-8 all-zero check. Curve25519 has cofactor 8, so a low-order peer input can drive the shared output to the all-zero value. RFC 7748 says implementations "MAY check ... whether the resulting shared secret is the all-zero value and abort if so" -- a MAY, tied to the nuance of contributory behavior, not a MUST [@rfc7748]. Most protocols do not need it because they mix identities and transcripts into the KDF anyway.

Note: Clamping constrains your own scalar; it says nothing about the peer's value. If you find yourself reasoning that clamping makes an incoming point safe, stop -- the safety comes from twist security. Treat clamping and validation as different jobs.

A precision that catches even careful readers: X25519 and its larger sibling X448 are the Montgomery, x-coordinate-only variant of elliptic-curve DH, not the SP 800-56A cofactor ECDH of Section 6, even though "ECDH" is the umbrella term for both. X448 targets a more conservative security level near 224 bits and is defined in the same RFC 7748 [@rfc7748].

Even here the KDF discipline is stated in the primitive's own voice: "Both of you can then hash this shared secret and use the result as a key," never the raw x-coordinate [@ecdh].

X25519 makes the primitive misuse-resistant: validated by construction, constant-time by design. It says nothing about the other two conditions -- freshness and authentication -- which remain the protocol's to enforce. And the first of those, freshness, is the exact hinge on which the property everyone wants from Diffie-Hellman either holds or silently evaporates.

8. The Breakthrough: Ephemeral Exchange and (Imperfect) Forward Secrecy

This is the property that makes people say "use DHE, not static," and the one most often stated as if it were automatic. It is not. It is a conjunction, and the failure catalog is its list of unmet conjuncts.

Forward secrecy, stated conditionally

If the Diffie-Hellman secret is freshly generated per session, never reused, destroyed after use, and run over a strong unshared group, then later compromise of the long-term authentication key cannot recover past session keys -- because the ephemeral secret those keys were derived from no longer exists. The long-term key's only job is to authenticate the exchange; the session's confidentiality dies with the ephemeral. Every word of that conditional is load-bearing. Drop "never reused" and you get a static key in disguise; drop "strong unshared group" and Logjam reads you anyway.

The guarantee that compromising a long-term key does not expose past session keys. It holds only when the per-session ephemeral secret was freshly generated, never reused, destroyed after use, and run over a strong, unshared group. It is a conjunction of those conditions, not an automatic consequence of using DH. An ephemeral DH key is generated fresh for a single session and discarded immediately after. A static key is long-lived and reused across sessions, providing no forward secrecy. A cached or reused "ephemeral" is, for security purposes, a static key. flowchart TD E["Fresh ephemeral secret, used then destroyed"] --> H["Handshake, DH values signed by the long-term key"] LT["Long-term key authenticates only"] --> H H --> K["Session key derived from the ephemeral"] K --> D["Ephemeral destroyed when the session ends"] C["Attacker later steals the long-term key"] --> P["Past sessions stay secret: the ephemeral is gone"] ST["Static DH: one reused key does everything"] --> O["Its compromise opens every past session at once"]

Mode	Fresh per session?	Forward secrecy
Static DH	No -- one long-lived key	None; a single key compromise opens all past sessions
Reused or cached "ephemeral"	No -- shared across sessions	Collapses for every session that shares it; also enables Raccoon
True ephemeral	Yes -- destroyed after use	Yes, conditional on a strong unshared group

The honest other half: how the property fails

The conditional fails in three documented ways, and each is a row in the catalog.

Ephemeral-key reuse or caching. Sold as a performance optimization, reusing an ephemeral turns it into a static key and collapses forward secrecy for every session that shares it. Worse, reuse is the precondition for Raccoon (CVE-2020-1968): in TLS 1.2 and earlier, the premaster secret had its leading zero bytes stripped before the key derivation step, so the exact timing of the KDF leaked the most significant bits of the shared secret, recoverable as an instance of the Hidden Number Problem -- but only when the server reused its DH key long enough to gather timing samples [@raccoon].

Shared-prime precomputation. This is Logjam again, from the other direction: even a genuinely fresh per-connection ephemeral does not save you if the prime is shared and precomputed [@weakdh]. It is the reason the paper is titled Imperfect Forward Secrecy.

Static DH. No ephemeral at all, so no forward secrecy at all -- the baseline failure that TLS 1.3 later abolished [@rfc8446].

Note: Caching or reusing a DH "ephemeral" collapses forward secrecy for every session that shares it, and reuse is exactly the condition Raccoon needs to mount its timing oracle. If it is not fresh and destroyed, it is not ephemeral.

The Raccoon authors are blunt about the root condition: reusing a DH key "was already considered bad practice before the attack, as it does not provide forward secrecy" [@raccoon]. The timing oracle was a second penalty on top of the forward-secrecy loss.

The discipline beneath it all

Why must the raw shared value always be hashed? Because a Diffie-Hellman value "is NOT a uniformly random or pseudorandom string" -- it is a structured group element with detectable bias -- so it must be run through an extract-and-expand KDF before it becomes key material [@rfc5869]. This is the formal echo of the CDH-versus-DDH gap from Section 2, now stated as a standards requirement.

A Diffie-Hellman value "is NOT a uniformly random or pseudorandom string." -- RFC 5869, Section 3.3 It is easy to over-claim what forward secrecy buys. It bounds the reach of a *future* compromise: an attacker who steals your long-term key tomorrow cannot decrypt the sessions you completed and destroyed today.

It does nothing about the present. An attacker who owns your endpoint during a live session, or who grabs the ephemeral before you delete it, reads that session in full. Nor does it provide post-compromise security -- the guarantee that sessions after a compromise heal once the attacker loses access. That healing is a different property, achieved by ratcheting constructions such as the one in the Signal protocol, and it is out of scope for a single DH exchange. Forward secrecy is a statement about deleted secrets, and only about the past.

Freshness, a strong group, validated inputs, authentication, and a KDF -- five things, and the caller was trusted to remember all of them. The last move in this story stops trusting the caller: it bakes the conditions into named objects and a protocol that refuses to run without them.

9. State of the Art (2024-2026): X25519 Everywhere, and the Quantum Clock

Here is what a practitioner actually deploys today -- and the single overlay that reframes all of it: every discrete-log DH in this article has an expiration date, and a well-funded adversary can start the clock by simply recording your traffic now.

The deployed reality

X25519 is the dominant key agreement across TLS 1.3, OpenSSH, WireGuard, and Signal, and the word "dominant" now rests on measured deployment rather than defaults alone. Cloudflare, which terminates a large fraction of the world's HTTPS and can therefore see it, reports that X25519 "now secures the vast majority of all Internet connections" [@cloudflare-pq]; OpenSSH has shipped Curve25519 key exchange as "the default when both the client and server support it" since version 6.5, back in 2014 [@openssh65], [@ecdh]; and WireGuard and Signal are built on the same primitive [@wireguard], [@pqxdh]. Finite-field DH survives mainly as deprecated-but-present legacy in older TLS and IPsec [@weakdh], [@rfc8446].

TLS 1.3 turned this whole article's argument into a requirement: RFC 8446 removed static RSA and static Diffie-Hellman key transport, requires ephemeral (EC)DHE, and restricts negotiation to named groups. The specification states the result directly: "Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy" [@rfc8446]. That is conditions #1, #2, and #4 -- freshness, a vetted group, and authentication -- pulled inside the protocol as non-optional. The fifty-year move is complete: the four conditions now live in the primitive, the named group, and the protocol, not in the caller's memory.

The quantum overlay

There is one problem no key size solves. All discrete-log Diffie-Hellman, finite-field and elliptic-curve alike, falls in polynomial time to Shor's algorithm on a sufficiently large quantum computer, and "harvest-now, decrypt-later" means an adversary can record your ECDH traffic today and decrypt it once such a machine exists [@rfc9794]. So the field is wrapping ECDH rather than replacing it.

An attack strategy in which an adversary records encrypted traffic today and stores it, intending to decrypt it later once a cryptographically relevant quantum computer exists. It makes today's ECDH confidentiality a future liability.

The wrapper is X25519MLKEM768: it runs an X25519 exchange and an ML-KEM-768 key encapsulation in parallel and feeds both shared secrets into the KDF, so the session stays secure as long as either problem remains hard [@ecdhe-mlkem], [@fips203]. Concretely, the client key share is 1216 bytes (1184 for ML-KEM plus 32 for X25519), the server share is 1120 bytes, the negotiated combined secret is 64 bytes, and the TLS codepoint is 0x11EC [@ecdhe-mlkem].

A public-key primitive in which a sender encapsulates a fresh random key to a recipient's public key, producing a ciphertext the recipient decapsulates. Unlike Diffie-Hellman, a KEM is inherently interactive and has no non-interactive agreement between two static public keys.

The transition was fast. OpenSSH 9.9, released on 2024-09-19, enabled mlkem768x25519-sha256 by default [@openssh99]. OpenSSL 3.5, a long-term-support release from April 2025, ships a DEFAULT TLS group list that "selects X25519MLKEM768 as one of the predicted keyshares" [@openssl35-release], [@openssl-groups]. Chrome and Cloudflare deployed post-quantum key agreement across their edges [@cloudflare-pq].

The classical primitives do not vanish. FFDHE and P-256 persist wherever FIPS validation or vendor interop compels them, and FIPS-flavored hybrids such as `SecP256r1MLKEM768` exist for exactly that constraint [@sp80056a]. There is also a plumbing wrinkle: the roughly 1.2 KB hybrid ClientHello may no longer fit in a single TCP segment, which OpenSSL's documentation calls out along with guidance on ordering group tuples to avoid a silent downgrade [@openssl-groups].

Two precisions that keep the story honest

First, a KEM is not a drop-in Diffie-Hellman. It has no non-interactive static-static agreement, so X25519MLKEM768 is a hybrid KEM handshake, not "post-quantum Diffie-Hellman." Second, in messaging, Signal's PQXDH (2023) is the analog: it adds an ML-KEM encapsulation to the older X3DH design but "still relies on the hardness of the discrete log problem for mutual authentication in this revision," so X25519 is retained, not retired [@pqxdh], [@x3dh]. Signal described it as "an upgrade to the X3DH specification which we are calling PQXDH" [@pqxdh-blog].

State the adoption figure carefully. Cloudflare measured post-quantum key agreement at nearly 2% of TLS 1.3 connections in early 2024, with double-digit adoption projected by year-end rather than measured -- so "roughly 2% in early 2024, rising" is the defensible phrasing without a newer source [@cloudflare-pq].

X25519 is the default, TLS 1.3 made the discipline mandatory, and the hybrid buys time against Shor. So which primitive, with which parameters, in which case? That is a decision matrix -- and it is not a single winner.

10. Competing Approaches: The Decision Matrix and the AKE Families

There is no single best key-agreement primitive. The state of the art is a small set of deployed constructions, each dominant in a niche, wrapped by a small set of authentication families. The honest answer is "it depends."

The primitive decision matrix

Primitive	Best classical attack	Classical security	Post-quantum	Public value size	Peer-input validation	Best suited for
FFDHE-3072	Sub-exponential NFS	about 128-bit	No	about 384 bytes	Subgroup check on a safe prime	Legacy FIPS or interop only
ECDH P-256	Generic rho, about $2^{127.8}$	about 128-bit	No	65 bytes	Hand-written on-curve and subgroup MUST	FIPS, HSM, existing deployments
X25519	Generic rho, about $2^{125.8}$	about 128-bit	No	32 bytes	Structural, via twist security	New classical designs
X25519MLKEM768	Generic rho plus lattice attacks on ML-KEM	about 128-bit and post-quantum	Yes, if either half holds	about 1.2 KB (client share)	X25519 structural plus KEM ciphertext check	The post-quantum default going forward

Two rows carry the weight. "Best classical attack" separates FFDHE's sub-exponential tax from the curves' generic-only attack, which is why a curve needs a quarter of the bits [@rho], [@sp80057]. "Peer-input validation" separates a hand-written MUST for P-256 and a subgroup check for FFDHE from the structurally-unnecessary case of X25519 [@sp80056a], [@rfc7748]. The head-to-head rules fall out cleanly: X25519 for new designs; ECDHE with P-256 or FFDHE at 3072 bits and up only where FIPS or interop compels it; and ephemeral, always, for forward secrecy.

The authentication families

A primitive is only half a deployment; something must authenticate the exchange. Four families cover essentially all real usage.

Family	How DH is authenticated	Deployed in	Trade-off
Signed-DH	Each side signs the transcript or the DH values	TLS 1.3, IKEv2, STS and SIGMA	Simple and well understood; needs a PKI or pinned keys
Implicitly-authenticated DH	Long-term and ephemeral keys combine inside the shared-secret formula	MQV and HMQV, parts of IKE	Compact, no signatures; subtle to get exactly right
DH-pattern frameworks	Compose several static and ephemeral DH operations	Noise, WireGuard's Noise_IK	Mutual auth plus identity hiding plus KCI resistance
Asynchronous AKE	Prekeys let a recipient be offline	Signal's X3DH and PQXDH	Deniable and offline-friendly; more moving parts

Signed-DH dominates the open web through TLS 1.3, whose handshake is SIGMA in spirit [@rfc8446], [@sigma2003]. WireGuard composes several X25519 operations in the Noise_IK pattern to get mutual authentication, forward secrecy, key-compromise-impersonation resistance, and identity hiding at once [@wireguard]. Signal's X3DH and its post-quantum successor PQXDH deliver asynchronous, deniable key agreement to an offline recipient [@x3dh], [@pqxdh].

The composition hazard

One more lesson hides in those families, and it is easy to miss: sub-protocols each proven secure in isolation can still compose into an insecure whole. The Triple Handshake attack (Bhargavan, Delignat-Lavaud, Fournet, Pironti, and Strub, IEEE Symposium on Security and Privacy 2014) chained a TLS key exchange with session resumption and renegotiation so that two distinct connections could be driven to share the same master secret, which broke client authentication and defeated the countermeasures of the day [@triple-handshake].

Paired with key-compromise impersonation -- where stealing your long-term key lets an attacker impersonate others to you -- it is the standing reminder that a secure handshake is not simply the sum of secure steps. It is also the concrete reason TLS 1.3 binds the entire transcript: the Finished MAC covers the whole handshake, so two runs that differ anywhere cannot be coerced into agreeing [@rfc8446].

The Triple Handshake attack (2014) and key-compromise impersonation are adjacent AKE-composition pitfalls, not breaks of the signed-DH template itself. They are why TLS 1.3 authenticates the full handshake transcript rather than individual messages [@triple-handshake].

Signposts, not sections

Several approaches deserve a pointer rather than a treatment. MQV and HMQV are the implicitly-authenticated DH family, with narrow deployment in some IKE and Suite B profiles [@sp80056a]. DH-based PAKEs and OPRFs -- CPace, OPAQUE, SPAKE2 -- use Diffie-Hellman for password-authenticated and oblivious key agreement and are the subject of the hash-to-curve and PAKE installment of this series. CSIDH is the isogeny-based candidate for a genuinely post-quantum Diffie-Hellman analog, and its cautionary neighbor SIDH/SIKE was broken outright in 2022 [@sike-break]. ElGamal is DH's public-key encryption cousin, not a key-agreement scheme. And X448 is the conservative higher-security sibling of X25519. Each is one sentence here by design.

Every row of those tables assumes the underlying hardness holds. That assumption has a precise shape on each track -- and one hard ceiling above both.

11. Theoretical Limits: Where the Hardness Lives, and Its Ceiling

Here is what a first course skips: the two Diffie-Hellman tracks do not have the same kind of hardness, the raw shared secret is provably not a good key, and every scheme in this article dies to the same quantum algorithm.

Finite-field DLP is sub-exponential

The general number field sieve solves finite-field discrete logs in $L_p[1/3,\ (64/9)^{1/3}]$, and its first step depends only on the prime -- the engine behind Logjam. Because the attack is sub-exponential rather than exponential, key sizes must grow quickly to stay ahead: 3072 bits for 128-bit security, 7680 for 192-bit [@weakdh], [@sp80057]. The Logjam paper's own field estimates trace that curve concretely: a 512-bit prime falls in near-real time after a one-week, 89,000-core-hour precomputation (a median of 70 seconds per subsequent log); a 768-bit prime is an academic reach at about 36,500 core-years; and a shared 1024-bit prime is a standing nation-state liability at about 45 million core-years of one-time precomputation [@weakdh]. As an independent measured anchor one size down, the RSA-250 factoring record fell to the number field sieve in February 2020 at about 2,700 core-years [@rsa250].

Elliptic-curve DLP is generic square-root, and no better

For a strong curve the best known attack is generic Pollard rho at about $0.886\sqrt{\ell}$ operations, and -- this is the deep part -- that matches Shoup's generic lower bound of $\Omega(\sqrt{\ell})$ [@shoup1997]. For a well-chosen curve the gap between the best attack and the proven floor is closed: Curve25519 sits at about $2^{125.8}$ and P-256 at about $2^{127.8}$ [@rho]. The only escapes are specific bad families -- pairing (MOV and Frey-Ruck) reductions and anomalous curves -- which is why rigidity and vetted parameters matter, and which the elliptic-curves installment of this series treats in full.

Target security	Finite-field DH prime	Elliptic curve (rho cost)	Best classical attack
128-bit	3072-bit	Curve25519 about $2^{125.8}$, P-256 about $2^{127.8}$	Sub-exponential NFS vs generic rho
192-bit	7680-bit	P-384 about $2^{191.8}$	Sub-exponential NFS vs generic rho

Rho also amortizes across targets: breaking $T$ keys at once costs only about $\sqrt{T}$ times a single break, the elliptic-curve echo of Logjam's shared-prime amortization, and another reason to prefer a generous subgroup order [@rho].

The CDH-DDH gap is why the KDF is a theorem

The assumptions form a ladder, but mind the direction: an algorithm that solves the left solves the right, so DLP is at least as hard as CDH, which is at least as hard as DDH (read instead as hardness assumptions, the implication runs the other way, with DDH-hardness implying CDH-hardness implying DLP-hardness). That last gap is real and not merely conservative. On pairing-friendly curves, DDH is easy while CDH is plausibly still hard, so the raw $g^{ab}$ can be distinguished from uniform even when it cannot be computed by an attacker [@cryptobook]. That is precisely why RFC 5869 forbids skipping the extract step and insists the shared value be run through a KDF before use [@rfc5869]. Condition #5 is not a style preference; it is a consequence of a proven gap between two assumptions.

Forward secrecy's precise limits

Stated formally, forward secrecy protects the past, not the present or future, and only under the conjunction from Section 8: the ephemeral must have been ephemeral and the group strong. Its unmet conjuncts are, exactly, the failure catalog.

The ceiling: Shor

Above both tracks sits one algorithm that does not care which group you chose. Shor's algorithm solves discrete logarithms -- finite-field and elliptic-curve -- in polynomial time on a sufficiently large quantum computer, and no key size escapes it [@rfc9794]. This is the one break in the entire article that is a break of the math rather than a leaked condition.

Key idea: Every other failure in this article was a leaked condition -- a shared prime, an unvalidated point, a reused ephemeral, a missing signature. Shor is the only one that breaks the math itself. That is why the answer to Shor is a new problem, ML-KEM wrapped around X25519, and not simply a bigger curve.

If the theory is this settled -- a closed generic gap on curves, a sub-exponential tax on fields, a proven quantum cliff above both -- then what is left is genuinely open. And what is open is not the math. It is the interface, again.

12. Open Problems: What Remains Genuinely Unsettled

The discrete log is not the frontier. The frontier is what "post-quantum Diffie-Hellman" even means, whether constant-time can ever be a settled property, and how much broken cryptography is still in the field.

A practical post-quantum NIKE

Diffie-Hellman is a non-interactive key exchange: two parties who have each merely published a static public key can agree on a shared secret with no further interaction, and that single property is what makes asynchronous and static-static designs -- X3DH, Noise's static-static patterns -- possible. A KEM cannot do this. It is inherently interactive: one side encapsulates to the other's key and returns a ciphertext, so there is no agreement between two published static keys [@ecdhe-mlkem].

A scheme in which two parties agree on a shared secret purely from each other's published static public keys, with no live message exchange. Diffie-Hellman is a NIKE; a KEM is not, which is why KEMs cannot directly replace DH in static-static and asynchronous designs.

The only serious candidate for a genuinely post-quantum NIKE is the isogeny scheme CSIDH (Castryck, Lange, Martindale, Panny, and Renes, ASIACRYPT 2018), a commutative supersingular-isogeny group action that offers Diffie-Hellman's exact static-static, non-interactive interface. Its appeal is size: the paper advertises "public keys of only 64 bytes at a conjectured AES-128 security level, matching NIST's post-quantum security category I" [@csidh]. But that quantum-security claim is contested. Bonnetain and Schrottenloher analyzed the underlying quantum abelian-hidden-shift attack and concluded that "the parameters proposed by the authors of CSIDH do not meet their expected quantum security" (EUROCRYPT 2020), a finding Peikert reached independently the same year [@bs2020], [@peikert2020].

The consensus repair is to grow the parameters: the SQALE authors set out to "optimize large CSIDH parameters ... while still achieving the NIST security levels 1, 2, and 3," which pushes the prime to 1024 bits and beyond, with correspondingly slower group actions [@sqale]. And CSIDH's close relative SIDH/SIKE was broken outright in 2022, when Castryck and Decru recovered keys against SIKEp434 "in about ten minutes on a single core" [@sike-break]. That is a reminder that young isogeny assumptions can fall catastrophically, and it is why today's hybrids sidestep the missing PQ-NIKE rather than solve it [@pqxdh].

Key idea: "Post-quantum Diffie-Hellman" is not a solved problem. A KEM is not a drop-in for DH's non-interactive interface, and the closest true analog -- 64-byte CSIDH -- buys much less quantum security than its key size advertises, so restoring the intended level pushes it to far larger, far slower parameters. The hybrid buys time; it does not resurrect the NIKE.

Deniability versus post-quantum authentication

Diffie-Hellman gives messaging protocols a property signatures cannot: deniability. Because a session secret in X3DH is derived from DH values rather than a signature, neither party can later prove to a third party who they talked to -- the transcript could have been produced by either side alone [@x3dh]. That is a deliberate feature, and it is in tension with the post-quantum migration. Signal's PQXDH ships post-quantum confidentiality first, but in its own words it "provides post-quantum forward secrecy ... but still relies on the hardness of the discrete log problem for mutual authentication in this revision" [@pqxdh]. The reason it keeps a DH operation for the authentication step is precisely the open problem: the obvious post-quantum fix -- a post-quantum signature -- is inherently non-deniable, and a deniable post-quantum authentication scheme is not yet a settled, deployed design.

This is why PQXDH retains a discrete-log DH operation for mutual authentication even after adding ML-KEM for confidentiality: post-quantum confidentiality has shipped ahead of post-quantum authentication, and the deniability that DH provides has no drop-in post-quantum replacement yet [@pqxdh].

Constant-time as a moving target

X25519's ladder removes the timing channel at the primitive level, but Raccoon showed the same class of leak can live one layer up, in the protocol, when a premaster secret has its leading zeros stripped before hashing -- and it recurs specifically when a DH key is reused [@raccoon]. Formally-verified constant-time implementations are the structural answer, and they are not yet universal [@rfc7748].

The legacy long tail

This is a deployment problem, not a math problem. 1024-bit FFDHE, shared and custom primes, static DH, and DHE on TLS 1.2 all persist in the field years after the fixes shipped, and Logjam's precomputation economics make those shared 1024-bit primes a standing mass-decryption risk [@weakdh]. RFC 7919's named groups, the TLS 1.3 ephemeral mandate, and browsers dropping DHE have shrunk the surface, but the migration is incomplete [@rfc7919], [@rfc8446].

Hybrid-combiner and downgrade robustness

The entire value of X25519MLKEM768 is "secure if either half holds," and that guarantee is only as good as the combiner and the negotiation around it: a flawed combiner, or an attacker who forces a downgrade to the weaker half, voids it. RFC 9794 standardizes the post-quantum/traditional vocabulary and OpenSSL's group-tuple syntax guards the ordering, but end-to-end downgrade-resistance proofs for the deployed handshakes are still being worked out [@ecdhe-mlkem], [@rfc9794], [@openssl-groups].

Flagged as reasoning, not documented fact: by analogy to every generation before it, the next wave of post-quantum breaks will most likely again be interface leaks -- bad randomness, unvalidated ciphertexts, non-constant-time decapsulation -- rather than breaks of the lattice problem itself. No source documents a failure that has not yet happened; this is an inference from the pattern of the previous five generations.

If the open problems are mostly about the interface, then so is the guidance. Here is fifty years of failure compressed into rules you can apply in a design review on Monday.

13. The Practical Guide, and the One Sentence Underneath

Every rule below is one row of the failure catalog, inverted. If you remember nothing else, remember the diagnostic question, and the four conditions it audits.

Decision rules: use X, with parameters Y, in case Z

New key agreement, general purpose: X25519, ephemeral [@rfc7748], [@ecdh].
Post-quantum-hardened (the recommended default going forward): X25519MLKEM768 [@ecdhe-mlkem], [@openssl35-release], [@openssh99].
FIPS, regulated, or HSM-interop: ECDHE with P-256 or P-384, ephemeral, with full public-key validation; or the FIPS hybrid SecP256r1MLKEM768 [@sp80056a], [@ecdhe-mlkem].
Legacy finite-field interop only: FFDHE ffdhe3072 or larger, ephemeral, with the subgroup check -- never a custom prime and never one below 2048 bits [@rfc7919], [@weakdh].
Always, regardless of primitive: ephemeral and destroyed after use; validate the peer value appropriately (clamping is not validation); run the shared secret through HKDF; authenticate the exchange; never static DH; never reuse the ephemeral [@rfc5869], [@rfc8446].

Situation	Use	Key parameters	Because (named break avoided)
New design, general	X25519, ephemeral	32-byte keys, HKDF the secret	Validation and timing are structural
PQ-hardened default	X25519MLKEM768	Hybrid, both secrets into the KDF	Shor and harvest-now-decrypt-later
FIPS / HSM / interop	ECDHE P-256 or P-384, ephemeral	Full public-key validation	Invalid-curve attacks
Legacy FF interop only	FFDHE `ffdhe3072`+, ephemeral	Subgroup check, never below 2048-bit	Logjam shared-prime precomputation
Always	Ephemeral, validate, KDF, authenticate	Destroy the ephemeral after use	Reuse, man-in-the-middle, CDH-DDH gap

Note: X25519 for greenfield. X25519MLKEM768 when you need post-quantum hardening. ECDHE-P256 or FFDHE-3072-plus only where FIPS or interop forces your hand. And always: ephemeral, validated, KDF'd, and authenticated.

For TLS, run `openssl s_client -connect example.com:443 -tls1_3` and read the "Negotiated TLS1.3 group" line in the output; it names the group actually chosen, such as `X25519` or `X25519MLKEM768`. To offer only the hybrid and confirm the server supports it, add `-groups X25519MLKEM768` (OpenSSL 3.5 or later). For SSH, `ssh -Q kex` lists the key-exchange methods your client supports, and connecting with `ssh -vv` prints the method actually negotiated, for example `mlkem768x25519-sha256`. flowchart TD A{"New greenfield design?"} -- no --> F{"FIPS or HSM interop required?"} A -- yes --> Q{"Post-quantum sensitive?"} Q -- yes --> H["X25519MLKEM768, ephemeral"] Q -- no --> X["X25519, ephemeral"] F -- yes --> P["ECDHE P-256 or P-384, ephemeral, full validation"] F -- no --> L["FFDHE ffdhe3072 or larger, ephemeral, subgroup check"]

The misuse catalog

Each common mistake maps to exactly one named break. Static DH gives no forward secrecy. A reused or cached "ephemeral" collapses forward secrecy and enables Raccoon. A custom, shared, or sub-2048-bit prime invites Logjam, and a non-prime "prime" you cannot audit invites the socat failure. Skipping the on-curve and subgroup check for P-256 ECDH builds an invalid-curve oracle. Treating clamping as validation misreads why X25519 is safe. Using the raw x-coordinate or $g^{ab}$ as a key ignores the CDH-DDH gap. And anonymous DH with no authentication is a standing man-in-the-middle.

The failure catalog

This is the thesis as evidence: every world-scale Diffie-Hellman break, in one grid, each a violated condition with the math intact underneath. The rows were derived across earlier sections -- Logjam [@weakdh] and its RSA twin FREAK [@freak], small-subgroup confinement [@limlee1997] and CVE-2016-0701 [@openssl-cve], the non-prime socat modulus [@socat-secadv7], the invalid-curve class [@bmm2000] and its practical TLS demonstration [@jss2015], Raccoon [@raccoon], and the KDF requirement [@rfc5869].

Break	Year	Condition violated	Root cause	Foreclosed by
Anonymous-DH MITM	design gap	#4 Authentication	DH values bound to no identity	STS/SIGMA; TLS 1.3 signatures
Logjam shared-prime	2015	#2 Strong, unshared group	NFS first step precomputed per shared prime, about 45M core-years at 1024-bit	RFC 7919 named safe primes
Logjam 512-bit export	2015	#2 Strong group (active)	Downgrade to breakable export parameters	TLS 1.3 removes export and static DH
FREAK (Logjam's RSA twin)	2015	#2 Strong group (active)	Downgrade to 512-bit export RSA key transport, then factor it	TLS 1.3 removes export and static RSA
Small-subgroup (Lim-Lee); CVE-2016-0701	1997; 2016	#3 Validation and #1 reuse	Low-order element vs a reused exponent, no subgroup check	Safe primes plus the subgroup check
Non-prime modulus (socat)	2016	#2 Strong, unshared group	A shipped custom 1024-bit "prime" that was composite, possibly backdoored	RFC 7919 named safe primes; never bring your own
Invalid-curve (BMM); JSS TLS-ECDH	2000; 2015	#3 Validation	Off-curve point, formulas ignore b, reused key	Mandatory on-curve and subgroup check; X25519 twist
Raccoon	2020	#1 Freshness (reuse)	Leading-zero stripping plus a reused DH key gives an MSB timing oracle	No key reuse; TLS 1.3 key schedule
Ephemeral reuse or caching	ongoing	#1 Freshness	A cached "ephemeral" is a static key; forward secrecy collapses	Fresh-per-session and destroyed; TLS 1.3
Static DH	ongoing	#1 Freshness	No ephemeral, so no forward secrecy	TLS 1.3 ephemeral mandate
Raw x-coordinate as key	ongoing	#5 KDF discipline	CDH-DDH gap leaves the shared value biased	HKDF extract, per RFC 5869

No, and this is the field's most-corrected misconception. Forward secrecy is a *conjunction*: the ephemeral must be freshly generated per session, never reused, destroyed after use, and run over a strong unshared group. Reuse a performance-optimized ephemeral and you have a static key; run over a shared 1024-bit prime and a precomputation reads you anyway, which is why the foundational paper is titled *Imperfect Forward Secrecy*. "Ephemeral, therefore forward-secret" is false without those conditions. No. Clamping constrains *your own* secret scalar so your side of X25519 avoids cofactor and small-order pitfalls; it does nothing to check or reject a malicious peer value. X25519 is safe against off-curve inputs because of *twist security* -- the curve and its twist are both hard -- not because of clamping. That distinction trips up a lot of otherwise-correct code. No. A Diffie-Hellman value is a structured group element, not a uniformly random string, and there are groups where it is even distinguishable from random -- the CDH-versus-DDH gap. Always run it through a KDF such as HKDF. Skipping the extract step is exactly what RFC 5869 warns against. No. Fresh per-connection keys do not help against Logjam's central result: the number-field-sieve's expensive step depends only on the *prime*, so a shared or common 1024-bit prime can be precomputed once and then used to passively decrypt every connection on it. Use ffdhe3072 or larger, or move to a curve. Below 2048 bits is indefensible. X25519 for anything greenfield: 32-byte keys, a single constant-time Montgomery ladder, and twist security that makes the two hardest ECDH mistakes -- timing leaks and missing point validation -- structurally unreachable. Use P-256 where FIPS, an HSM, or an existing deployment compels it, and then with full public-key validation and a constant-time library. No. ML-KEM is a key encapsulation mechanism, which is inherently interactive and has no non-interactive static-static agreement, so it cannot express the asynchronous and static-static designs DH enables. That is why the post-quantum state of the art is a *hybrid* -- X25519MLKEM768, with X25519's secret combined with ML-KEM's -- rather than a like-for-like swap. The closest true post-quantum analog of Diffie-Hellman, the isogeny scheme CSIDH, does keep the non-interactive interface with 64-byte keys, but its quantum security is contested and reaching the intended level forces much larger, slower parameters. No. Authentication defeats the *active* man-in-the-middle and nothing else -- it is orthogonal to the group's hardness and to input validation. A signed handshake over a shared 1024-bit prime is still Logjam-exposed, and a signed exchange that skips the on-curve check is still an invalid-curve oracle. Authentication is one of four conditions, not a substitute for the others.

The one sentence underneath

Return to Logjam. Across fifty years, almost no deployed break ever solved a discrete logarithm. Attackers precomputed a shared prime, confined a reused key to a small subgroup, fed an off-curve point to a validation-free server, read the clock while a server stripped leading zeros, shipped a modulus that was not even prime, or simply sat in the middle of an unauthenticated exchange. "Using Diffie-Hellman safely" is not one choice but a stack: a strong unshared group, a validated input, a genuinely fresh-and-destroyed ephemeral, an authenticated exchange, and a KDF beneath them. The fifty-year story is the field pulling each of those off the caller's shoulders and into the primitive, the named group, and the protocol, so that the simple thing to do became the safe thing to do. Remove any layer and the matching failure class reopens.

The math held; the deployment handed the secret away.

There is one exception, and it is the horizon. Shor's algorithm is the single break in this whole story that touches the math itself, which is why today's ECDH is being wrapped, not replaced, and why the destination is a hybrid rather than a bigger prime. So audit the exchange the way the whole article has: when a public value you did not generate arrives, and you combine it with a secret you must have freshly generated and will immediately destroy -- is the group strong and unshared, is that incoming value validated, is the exchange authenticated, and does the raw result go through a KDF before anyone calls it a key? Using Diffie-Hellman safely is the discipline of never handing an attacker a condition your protocol forgot to own.