Parag Mali - tag: post-quantum-crypto

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.

The Curve Was Hard; The Gap Was Soft: A Field Guide to Using Elliptic Curves Safely

noreply@paragmali.com (Parag Mali) — Sat, 11 Jul 2026 16:08:14 GMT

**The elliptic-curve discrete-log problem was never the weak point.** On a well-chosen curve, ECDLP is the hardest discrete log we know how to build -- which is why a 256-bit curve buys what a 3072-bit RSA modulus does -- and yet across three decades of deployment, almost no real-world break ever solved one. They did not have to. Every named disaster lives in the gap between a hard curve and safe code: the server that fed an attacker's off-curve point into scalar multiplication and leaked its private key (invalid-curve attacks); the low-order point that clamping never filtered (the Monero cofactor bug); the certificate whose *base point* was never checked (Curveball, CVE-2020-0601); the microsecond of branch timing in a non-constant-time ladder (Brumley-Tuveri). The evolution of curves -- NIST short-Weierstrass (P-256, secp256k1), then Curve25519/X25519, then Ed25519, then the Ristretto255 prime-order abstraction -- is one sustained move: take the safety burden off the implementer and bake it into the curve, the group, and the encoding, so the simple implementation becomes the secure one. Using elliptic curves safely is a stack: the right curve for the job (X25519 for key agreement, Ed25519 for new signatures, P-256 only where FIPS compels it, secp256k1 only for blockchain), validate every untrusted point, multiply in constant time, and prefer constructions where the dangerous case cannot be reached. Remove any layer and the gap reopens.

1. Two Lines of Code

In January 2020, Microsoft patched a vulnerability the U.S. National Security Agency had quietly reported to it -- an unusually public gesture from an agency that normally hoards such findings. The bug was almost embarrassing in its simplicity. Windows would check a TLS certificate's elliptic-curve signature against a trusted root, and it would never check the curve's base point. If you supplied a certificate that carried its own curve parameters -- with a generator you had chosen yourself -- Windows would trust the forged chain as though a real certificate authority had signed it [@cve-2020-0601]. Nobody factored a modulus. Nobody solved a discrete logarithm. The math of P-256 stood untouched. The attacker handed the code one parameter it forgot to validate, and the industry named the result Curveball.

Now go one layer down and back five years. In 2015, researchers recovered a TLS server's ECDH private key -- the actual secret -- by feeding it points that were not on the intended curve at all. The server's own scalar-multiplication routine did the leaking, one small residue at a time, until the whole key fell out [@jager-2015]. Two breaks, at two different layers of the same stack, with exactly one shape. In neither case did anyone attack the problem the textbooks call hard.

That is the claim this article proves. ECDLP-hardness is not the same thing as ECC-security, and every deployed elliptic-curve break lives in the gap between them. The discrete logarithm on a good curve is the strongest one-way function in wide use. The security of a system built on it is a different property entirely -- one that depends on what your code does with a point before it has decided the point is legitimate, and whether it does the arithmetic in a time an attacker cannot measure.

The private curve stayed hard; the code around it confessed.

So here is the diagnostic question the rest of this piece hands you, the one to ask of any elliptic-curve code you own: when a point you did not generate arrives, what does your code do with it before it has checked that the point is on the intended curve and in the right prime-order subgroup -- and does it do that arithmetic in constant time? Hold that question. The names you already fear -- invalid-curve attacks, Curveball, twist attacks, small-subgroup leaks, the cofactor, timing side channels -- are all one sentence underneath it. One mechanism explains the entire catalog, and the thirty-year evolution of curves is a single sustained campaign to put that mechanism out of reach.

To see how an unchecked point hands over a private key -- and why "just use Curve25519" is a real answer but not the whole one -- you first have to see what an elliptic curve actually is, and what makes its discrete log hard.

2. What an Elliptic Curve Actually Is, and Where It Came From

In 1976, Whitfield Diffie and Martin Hellman handed the world a template rather than a cryptosystem [@diffie-hellman-1976]. Pick a mathematical group in which one operation is easy to compute and its inverse is hard. Publish the result of applying that operation $k$ times to a fixed element -- call it $[k]G$. Keep $k$ secret. Anyone can combine public values to agree on a shared secret; no eavesdropper can run the operation backward. The template was sound. The group they had, the integers modulo a large prime, was not thrifty: because sub-exponential algorithms (index calculus) attack discrete logs in that group, safety demanded enormous keys. The obvious question hung in the air for nine years. What if you kept the template and changed the group?

Two inventors, no shared citation

The answer arrived twice, independently, from two people who did not cite each other. Victor Miller proposed it at CRYPTO '85 [@miller-1985]; Neal Koblitz published the same idea in Mathematics of Computation in 1987 [@koblitz-1987]. Both suggested using the group of points on an elliptic curve over a finite field. The decisive property: for a well-chosen curve, the best algorithm anyone knows is generic -- it works in any group and costs about $\sqrt{n}$ operations for a group of size $n$ -- rather than the sub-exponential index calculus that makes ordinary discrete logs cheap. No shortcut specific to the curve exists. That single absence is the whole reason elliptic-curve cryptography exists.Miller (1985) and Koblitz (1987) proposed elliptic-curve cryptography independently and neither cited the other. It is one of cryptography's cleaner cases of simultaneous invention -- the idea was ready to be found.

The primitive, kept tight

Here is the object itself, because this is the primitive and everything later depends on reading it correctly. Take the equation

$$y^2 = x^3 + ax + b$$

over a finite field $\mathbb{F}_p$ (the integers modulo a prime $p$). The set of solutions $(x, y)$, together with one extra "point at infinity" that acts as a zero, forms a finite abelian group. The group operation is a geometric rule called chord-and-tangent addition: to add two points, draw the line through them, find the third place it meets the curve, and reflect over the $x$-axis. To double a point, use the tangent line instead. The rule looks whimsical and turns out to be associative -- the proof runs through divisors and Riemann-Roch, which we cheerfully defer to Silverman.

Repeated point addition: adding a base point G to itself k times, written [k]G. Computed in about log k doublings and additions by the double-and-add method, it is the easy, forward direction of the elliptic-curve trapdoor -- fast to compute, believed hard to reverse.

Scalar multiplication is that forward direction: $[k]G = G + G + \dots + G$, $k$ times. Because you can double repeatedly, computing $[k]G$ for a 256-bit $k$ takes a few hundred operations, not $2^{256}$ of them. Reversing it -- recovering $k$ from $G$ and $Q = [k]G$ -- is the hard problem the whole field rests on.

Given a base point G on an elliptic curve and a second point Q = [k]G, recover the scalar k. This is the one-way assumption elliptic-curve cryptography depends on: easy to compute [k]G in the forward direction, believed infeasible to invert for a well-chosen curve.

Feel the asymmetry directly. The demonstration below computes $[13]G$ on a tiny curve in a handful of steps, then tries to walk it back. At these toy sizes the reversal is trivial; at 256 bits the same reversal is roughly $2^{128}$ operations, which is why the forward arrow is a trapdoor and the backward arrow is a wall.

{` // Toy curve y^2 = x^3 + 2x + 2 over F_17. Illustrative sizes, NOT secure. const p = 17n, a = 2n; function mod(x){ return ((x % p) + p) % p; } function inv(x){ // modular inverse via Fermat: x^(p-2) mod p let r = 1n, b = mod(x), e = p - 2n; while (e > 0n){ if (e & 1n) r = mod(rb); b = mod(bb); e >>= 1n; } return r; } function add(P, Q){ if (P === null) return Q; if (Q === null) return P; const [x1,y1] = P, [x2,y2] = Q; if (x1 === x2 && mod(y1 + y2) === 0n) return null; // P + (-P) = O let s; if (x1 === x2 && y1 === y2) s = mod((3nx1x1 + a) * inv(2ny1)); // tangent (double) else s = mod((y2 - y1) * inv(x2 - x1)); // chord (add) const x3 = mod(ss - x1 - x2); const y3 = mod(s*(x1 - x3) - y1); return [x3, y3]; } function mul(k, G){ // double-and-add: the FORWARD (easy) direction let R = null, base = G; while (k > 0n){ if (k & 1n) R = add(R, base); base = add(base, base); k >>= 1n; } return R; } const G = [5n, 1n]; // generator; this subgroup has prime order 19 const secret = 13n; // the "private key" const Q = mul(secret, G); // the "public key" [13]G, computed in ~5 steps console.log('public point [13]G =', Q[0].toString() + ',' + Q[1].toString());

// Now INVERT it: recover the secret from G and Q. The only general method on a // real curve is search -- trivial here, about 2^128 work at 256 bits. let found = null, R = null; for (let k = 1n; k <= 19n; k++){ R = add(R, G); if (R && R[0] === Q[0] && R[1] === Q[1]){ found = k; break; } } console.log('recovered secret by brute force =', found.toString()); `}

Why the keys shrink

That missing shortcut is not an academic footnote; it is the entire economic case for the primitive. For discrete logs modulo a prime, and for RSA, index-calculus methods run in sub-exponential time, so defenders must inflate the modulus to stay ahead -- 3072 bits to reach roughly 128-bit security. On a well-chosen prime-field curve, no such method is known, so the attacker is stuck paying the generic $\sqrt{n}$ price. A 256-bit curve therefore delivers about 128 bits of security [@miller-1985], [@safecurves-rho]. Same protection, an order of magnitude smaller keys, faster operations. Hold onto one detail for later: this economic win, the thing everyone remembers about elliptic curves, is the one property that has never been what broke.The absence of a sub-exponential attack on prime-field curves is the whole argument. It is why 256-bit ECC stands in for a 3072-bit RSA key -- and it is a statement about what we do not know how to do, not a theorem.

One clean curve, and the seeds of trouble

Standardization made the primitive interoperable. ECDSA was standardized as a digital-signature algorithm (ANSI X9.62) and folded into NIST's FIPS 186 series [@fips-186-5]; the P-curve we still call P-256 dates to FIPS 186-2 in 2000. The Standards for Efficient Cryptography Group published the matching secp parameter sets -- including secp256r1, which is P-256, and its efficiency-minded sibling secp256k1 [@sec2-v2]. The result was a single, clean, interoperable curve with prime order and a genuine strength most of its successors would come to envy. Which raises the puzzle that drives the next two sections: if P-256 is that good, why do the very people who designed its replacement consider "just implement P-256" to be dangerous advice?

3. The NIST Curves, and What They Cost

P-256 did one big thing exactly right, and three smaller things in a way that made the simple implementation insecure. Both halves are true at once, and holding them together is the beginning of expertise here.

What went right

P-256 is the curve $y^2 = x^3 - 3x + b$ over the special prime $p = 2^{256} - 2^{224} + 2^{192} + 2^{96} - 1$, and its single most underrated property is boring: its group has prime order, cofactor 1 [@sec2-v2]. There is no smaller subgroup for an attacker to trap you in, no cofactor to clear, no torsion points hiding in the corners. Add to that an enormous interoperable deployment -- P-256 is the elliptic curve behind most of the web's ECC certificates [@ssl-pulse] -- and you have a curve whose group-level security is excellent. Remember this when Curve25519 arrives two sections from now carrying a cofactor of 8.

The ratio of a curve's full group order to the prime order of the subgroup used for cryptography. P-256 has cofactor 1 (its whole group has prime order), while edwards25519 has cofactor 8, meaning small-order "torsion" points exist alongside the useful prime-order subgroup and must be handled with care.

Note: Cofactor 1 means P-256 has no small-order subgroups at all. That single fact rules out an entire family of attacks at the group level. Keep it in mind when the next generation trades it away for other advantages -- prime order is exactly what Curve25519 gives up and what Ristretto255 later works hard to rebuild.

Cost one: nobody can explain the seed

The coefficient $b$ and the base point were produced from a seed run through SHA-1 -- "verifiably random," in the standard's language, meaning anyone can rerun the hash and confirm the parameters were not obviously cooked. The catch is that the seed itself is an unexplained string of bytes. Nobody outside its authors can say why that seed and not another. SafeCurves calls this failure rigidity: a curve is rigid only when its parameters follow from stated principles with no unexplained freedom, and the NIST P-curves are not [@safecurves-index]. This is a trust concern, not a break -- but trust is a load-bearing beam, as the next beat shows.The P-256 parameters are "verifiably random" from a seed, yet the seed is never justified. That gap -- reproducible but unexplained -- is exactly what rigidity objects to. You can check the arithmetic and still not know why these constants.

Cost two: the addition law has holes

The classic short-Weierstrass addition formulas are not total. They have exceptional cases -- adding a point to its own negation, doubling a point whose $y$-coordinate is zero, anything involving the point at infinity -- where the generic slope formula divides by zero and returns nonsense. A working implementation must branch around those cases. And a branch whose direction depends on secret data is either wrong on the rare input that hits it, or observable through timing, or both. This incomplete addition law is the seed of the timing break we meet in the next section.

Cost three: the formula never looks at b

Here is the sharp one. Look back at the addition code in Section 2 and notice what is missing: the coefficient $b$ never appears. The short-Weierstrass scalar-multiplication formulas depend on $a$, on the coordinates, on the prime -- but not on $b$. So if you hand the routine a point that satisfies some other curve $y^2 = x^3 + ax + c$ with a different constant term, the arithmetic proceeds without complaint, silently computing on that other, possibly far weaker, curve [@safecurves-twist]. The curve has no twist security to catch the mistake. This omission is the seed of the invalid-curve break, and we detonate it in Section 4.

The Dual EC shadow

There is one more reason the community distrusts NIST-supplied constants, and precision matters because it is widely misremembered. In 2007, Dan Shumow and Niels Ferguson showed that the Dual EC DRBG random-number generator could conceal a back door: whoever chose its two special points might hold a secret relationship between them that predicts the generator's output [@shumow-ferguson-2007]. Edward Snowden's 2013 disclosures and, in 2015, a backdoor found inside Juniper's ScreenOS gave that theoretical worry a concrete afterlife.

But be exact about what this does and does not implicate. No weakness has ever been demonstrated in the P-256 curve itself. Dual EC poisoned trust in NIST-supplied constants as a category -- which is precisely why so many engineers now prefer rigid curves -- but it is a trust-and-rigidity argument, not a proven backdoor in the P-curves.Dual EC DRBG is a random-number-generator story, not a P-curve story. It shows NIST-chosen constants could be poisoned; it does not show that P-256's were. Conflating the two overstates the case and is a common error. And notice the shape already forming: prime-order, FIPS-mandated, mathematically strong -- yet the simple implementation is the insecure one.

The efficiency sibling

One more curve belongs on the table. secp256k1 is the SECG's efficiency variant: the curve $y^2 = x^3 + 7$ over $p = 2^{256} - 2^{32} - 977$, with $j$-invariant 0 and an endomorphism (the GLV method) that speeds scalar multiplication [@sec2-v2]. It is the curve Bitcoin chose, and later the base for Taproot's BIP-340 Schnorr signatures [@bip-340]. Keep its domain straight throughout this article: secp256k1 owns the blockchain world and is essentially absent from web PKI and TLS -- a blockchain-interoperability answer, never a general-purpose competitor to the curves that carry your HTTPS traffic.

Two of those three costs -- the unused $b$ and the branchy ladder -- are not abstractions. Each became a remote private-key recovery against real servers. To see how, you need the one mechanism that sits underneath the entire failure catalog.

4. The Failure Catalog: One Atom, Many Surfaces

Here is the mechanism the whole catalog reuses. Call it the atom: a point you did not generate, fed into scalar multiplication before you validate it -- or multiplied in variable time -- is a key-recovery oracle. The discrete logarithm is never solved. The implementation simply computes on the attacker's terms and leaks the answer, one small piece at a time.

Key idea: The atom of every deployed elliptic-curve break: a point you did not generate, used before it is validated -- or a secret scalar multiplied in a time an attacker can measure -- turns your own scalar-multiplication routine into an oracle that hands back the private key. ECDLP stays intact; the code around it does the leaking.

Deriving the atom: invalid-curve attacks

Recall Cost three from the last section: the short-Weierstrass formulas never read $b$. Ingrid Biehl, Bernd Meyer, and Volker Muller turned that omission into an attack at CRYPTO 2000 [@biehl-meyer-muller-2000]. Send the victim a point that satisfies a different curve $y^2 = x^3 + ax + c$ -- one you chose specifically because its group has small-order subgroups. The victim's routine, blind to the constant term, computes your scalar multiple on that weak curve. Its response now lives in a small subgroup, so it reveals the secret scalar modulo a small number. SafeCurves states the mechanism about as plainly as it can be stated:

The standard formulas for scalar multiplication on short Weierstrass curves do not involve the constant coefficient b, so they automatically also work for y^2 = x^3 + ax + c ... Bob will successfully compute n(x,y) without realizing that anything is amiss. Feeding an implementation a point that is not on the intended curve into scalar-multiplication formulas that ignore the coefficient b. The operation runs on a different, attacker-chosen curve whose group has small subgroups, so the response leaks the private scalar modulo small numbers -- with the intended curve's discrete-log hardness never touched. flowchart TD A["Attacker sends a point not on the intended curve"] --> B["Scalar-multiply formula ignores coefficient b"] B --> C["Arithmetic runs on a different, weaker curve"] C --> D["That curve has small-order subgroups"] D --> E["Response reveals the secret modulo a small number"] E --> F["Repeat with several coprime small orders"] F --> G["Chinese Remainder Theorem reassembles the whole key"]

The demonstration below runs the leak on a toy curve whose order factors as $105 = 3 \times 5 \times 7$. The attacker sends three low-order points, harvests three residues, and the Chinese Remainder Theorem stitches them into the secret. Nothing here is a discrete-log computation; it is bookkeeping.

{` // Toy curve y^2 = x^3 + x + 1 over F_101. Group order 105 = 357. // Illustrative ONLY -- a real curve has PRIME order and ~2^256 points. const p = 101n, a = 1n; const mod = x => ((x % p) + p) % p; function inv(x){ let r=1n,b=mod(x),e=p-2n; while(e>0n){ if(e&1n) r=mod(rb); b=mod(bb); e>>=1n;} return r; } function add(P,Q){ if(P===null) return Q; if(Q===null) return P; const [x1,y1]=P,[x2,y2]=Q; if(x1===x2 && mod(y1+y2)===0n) return null; // P + (-P) = O const s = (x1===x2 && y1===y2) ? mod((3nx1x1+a)inv(2ny1)) // tangent (double) : mod((y2-y1)inv(x2-x1)); // chord (add) const x3 = mod(ss-x1-x2); return [x3, mod(s*(x1-x3)-y1)]; } function mul(k,P){ let R=null,b=P; while(k>0n){ if(k&1n) R=add(R,b); b=add(b,b); k>>=1n;} return R; }

const k = 47n; // the victim's PRIVATE scalar // Attacker-crafted low-order points (orders 3, 5, 7). None is the real base point. const traps = [ {P:[28n,8n], t:3n}, {P:[86n,67n], t:5n}, {P:[72n,5n], t:7n} ];

// Chinese Remainder Theorem stitches the residues into k mod 105. let M=1n; for(const m of moduli) M*=m; let x=0n; for(let i=0;i<residues.length;i++){ const Mi=M/moduli[i]; let mi=1n; for(let j=1n;j<moduli[i];j++){ if((Mi*j)%moduli[i]===1n){ mi=j; break; } } x += residues[i]Mimi; } console.log('CRT-reassembled secret =', (((x%M)+M)%M).toString(), ' (true k = '+k+')'); `}

Surface one: small-subgroup attacks

You do not even need to leave the intended curve to run the atom. Chae Hoon Lim and Pil Joong Lee showed this at CRYPTO '97 [@lim-lee-1997]. If the curve's group is not of prime order -- if it has small-order subgroups -- then an attacker submits an element of small order $t$, and the victim's response is forced into that tiny subgroup, revealing the secret modulo $t$. Collect a few coprime $t$ values, apply the Chinese Remainder Theorem, and the full scalar falls out. This is the conceptual root of the rule "validate the subgroup, not just the curve," and it is exactly why prime order mattered so much back in Section 3. It also plants a flag we return to: any curve with a cofactor greater than 1 has these small subgroups by construction.

Submitting a group element of small order so that the victim's scalar multiplication lands in a tiny subgroup, making the response reveal the secret scalar modulo that small order. Repeated across several coprime small orders, the Chinese Remainder Theorem reassembles the full private key. It is the reason implementations must check that inputs lie in the correct prime-order subgroup.

Surface two: the atom made remote

Theory became a remote server compromise in 2015, when Tibor Jager, Jorg Schwenk, and Juraj Somorovsky recovered real TLS servers' ECDH private keys [@jager-2015]. The conditions were mundane: a server that reused a single ECDH key pair across handshakes and did not validate the incoming peer point. Each handshake fed the server another attacker-chosen invalid point; each response leaked another small residue; a few thousand handshakes later, the CRT delivered the private key. No discrete logarithm was ever computed. This is the atom of Section 4, wearing a TLS badge.The practical TLS result is Jager, Schwenk, and Somorovsky's ESORICS 2015 paper, "Practical Invalid Curve Attacks on TLS-ECDH" -- distinct from the same trio's separate USENIX Security 2015 work. The theoretical root is Biehl-Meyer-Muller (2000). Getting the citation right matters, because the two 2015 papers are often conflated.

Surface three: the cofactor, in production

Now the promised return to cofactors. The curve edwards25519 (the signing sibling of Curve25519) has cofactor 8, which means low-order "torsion" points exist. Monero's ring-signature scheme used key images to prevent double-spending: each spent output should map to exactly one key image. The bug was that the code never required a key image to lie in the prime-order subgroup, so an attacker could add a low-order torsion point to a legitimate key image, producing a different but still valid-looking image for the same output -- and spend it twice [@loup-vaillant-cofactor]. The fix was to demand that every key image $I$ satisfy $[\ell]I = \mathcal{O}$, where $\ell$ is the prime subgroup order: multiply by the group order and you must land on the identity, proving no torsion component is hiding inside.

The precise lesson here is the one most often gotten wrong, so it gets its own box.

Note: Curve25519 secret scalars are "clamped" -- specific bits are forced -- and engineers routinely mistake this for input validation. It is not. Clamping constrains your own secret scalar so that it is a multiple of the cofactor and sits in a fixed range. It does nothing to a malicious low-order input point someone else hands you. The Monero cofactor bug is exactly this confusion. If a protocol needs a prime-order group, validate or clear the cofactor on inputs -- or use a construction that removes the choice entirely.

Surface four: Curveball, one layer up

The atom does not care which layer it runs on. In Curveball (CVE-2020-0601), the mishandled point was not a peer's ephemeral key but the curve's own base point. Windows CryptoAPI accepted certificates carrying explicit curve parameters and trusted the generator inside them without checking it against the named curve's real generator. Choose your own generator with a known relationship to a trusted CA's public key, and you forge a signing chain [@cve-2020-0601]. Same disease, higher in the stack: a parameter that should have been validated -- here, the generator itself -- was taken on faith.

Surface five: the clock, with no malicious point at all

The final surface uses no bad input whatsoever. In 2011, Billy Bob Brumley and Nicola Tuveri recovered an OpenSSL ECDSA private key from a remote server purely by timing its scalar multiplications [@brumley-tuveri-2011]. OpenSSL's ladder for binary-field curves ran in data-dependent time; the timing leaked the bit-length of each per-signature nonce, and a lattice computation turned a few hundred such leaks into the key. The underlying flaw earned CVE-2011-1945, whose description is blunt: the implementation "does not properly implement curves over binary fields, which makes it easier for ... attackers to determine private keys via a timing attack and a lattice calculation" [@cve-2011-1945]. This is the atom's other face: arithmetic on a secret, performed in observable time, is an oracle even when every input is honest.

The one family this article does not re-derive

There is a whole lineage of ECDSA breaks -- fail0verflow's PlayStation 3 key recovery, biased-nonce lattice attacks, LadderLeak, Minerva, TPM-Fail -- that shares the atom's DNA but belongs to a sibling story about randomness and leakage rather than point validation [@minerva-2020], [@ladderleak-2020]. The result is quick to state: a repeated or biased per-signature nonce leaks the ECDSA private key through a lattice, deterministic nonces (RFC 6979) fix the generation half, and constant-time arithmetic fixes the leakage half [@rfc6979]. The lattice machinery is owned by this series' dedicated nonce-reuse post, so this article signposts it and moves on.

The pattern, stated once

Read the six surfaces together and one sentence covers all of them: the implementation touched a value it should have rejected, or acted in a time it should have hidden. The leaked bit is never "the discrete logarithm." It is "was this point on the curve," or "was this element in the right subgroup," or "how long did that multiply take," or "do I trust this generator." The table below is the evidence for the entire thesis. Every row is the same atom on a different surface.

Attack	Year	Surface	Channel	Root cause	The rule it teaches
Small-subgroup, Lim-Lee [@lim-lee-1997]	1997	Subgroup	Response residue	Non-prime-order group element accepted	Validate subgroup membership
Invalid-curve, Biehl-Meyer-Muller [@biehl-meyer-muller-2000]	2000	Off-curve point	Response residue	Formula ignores the coefficient b	Check the point is on the intended curve
Remote timing, Brumley-Tuveri [@brumley-tuveri-2011], [@cve-2011-1945]	2011	Scalar-mult timing	Wall-clock time	Non-constant-time ladder	Multiply in constant time
Practical invalid-curve TLS, Jager et al. [@jager-2015]	2015	Off-curve point, reused key	Response residue	No peer-point validation	Validate points, do not reuse ECDH keys
Cofactor key image, Monero [@loup-vaillant-cofactor]	2017	Cofactor torsion	Forged key image	Key image not in prime-order subgroup	Enforce prime order, clamping is not validation
Curveball [@cve-2020-0601]	2020	PKI base point	Forged certificate chain	Explicit generator trusted	Use named curves, never trust explicit parameters
ECDSA-nonce family [@minerva-2020], [@ladderleak-2020]	2020	Nonce leakage	Timing then lattice	Biased or leaked nonce	Deterministic nonces plus constant time

Six surfaces, one disease. And notice what the cure was not: it was not a warning label stapled to P-256. It was a decade-long engineering program to build curves where the dangerous case cannot be reached at all -- and that program, not the catalog, is the most instructive part of the story.

5. The Evolution: Moving Safety Off the Implementer

Read the last section again as a to-do list for curve designers. Each generation that follows crosses off one entry -- and here is the pattern that makes the story an argument rather than a parade of curves: they do it not by warning implementers to be careful, but by making the mistake unreachable. It is an attacker's kill-chain run in reverse. Where an intruder normally advances stage by stage, here the defenders advance, retiring one failure class per curve generation until the dangerous case no longer exists to reach.

flowchart LR G1["Gen 1 NIST short-Weierstrass"] --> F1["Leaves timing and invalid-curve to the implementer"] F1 --> G2["Gen 2 Curve25519 ladder"] G2 --> R2["Retires branch timing and invalid-curve for DH"] R2 --> G3["Gen 3 Ed25519 Edwards law"] G3 --> R3["Retires incomplete addition and the nonce disaster"] R3 --> G4["Gen 4 Ristretto255 encoding"] G4 --> R4["Retires the cofactor class at the type level"]

The chronology underneath that progression spans half a century, from a template to a post-quantum hybrid.

flowchart LR A["1976 Diffie-Hellman template"] --> B["1985-87 Miller and Koblitz propose ECC"] B --> C["2000 NIST P-curves standardized"] C --> D["2006 Curve25519 constant-time ladder"] D --> E["2011 Ed25519 complete Edwards law"] E --> F["2015-2023 Ristretto255 prime-order abstraction"] F --> G["2024-2026 X25519 plus ML-KEM hybrid"]

Generation one, and its own rescue

The NIST and SECG short-Weierstrass curves gave the world prime order, which we have already granted is a real strength. But their exceptional-case addition law and their branchy, easily-non-constant-time ladders left the two most dangerous jobs -- constant-time arithmetic and on-curve validation -- squarely with the implementer. Section 4 is the proof of what happens when an implementer drops them.

The honest rebuttal belongs right here, though, because it is the reason "P-256 is broken" is the wrong sentence. In 2016, Joost Renes, Craig Costello, and Lejla Batina published efficient complete addition formulas that work for every prime-order short-Weierstrass curve, with no exceptional cases to branch around [@rcb-2016]. Given those formulas and a vetted constant-time field implementation, P-256 is perfectly safe -- harder to implement safely, not broken. Its danger is that the naive implementation is the insecure one, and for two decades the naive implementation is what shipped.

Generation two: the ladder that is constant-time by construction

In 2006, Daniel J. Bernstein introduced Curve25519, the Montgomery-form curve $y^2 = x^3 + 486662x^2 + x$ over the prime $2^{255} - 19$ [@curve25519-2006]. The form and its ladder trace back to Peter Montgomery's 1987 work on factorization, revived here for an entirely new purpose [@montgomery-1987]. Two design choices retire whole rows of the failure catalog for free.

The first is the Montgomery ladder: a scalar-multiplication method whose sequence of field operations is identical regardless of the secret bits. There is no secret-dependent branch to time, so the timing surface -- Brumley-Tuveri's surface -- closes by construction rather than by careful coding. Key agreement uses only the $x$-coordinate, so a peer sends 32 bytes and the $y$-coordinate never enters the arithmetic.

A scalar-multiplication algorithm that performs the same sequence of field operations for every bit of the secret -- one conditional swap plus a combined add-and-double per bit -- so its running time and memory-access pattern are independent of the scalar. It is constant-time by construction rather than by defensive programming.

The second is twist security. When someone hands you an $x$-coordinate, it corresponds either to a point on Curve25519 or to a point on its quadratic twist. Bernstein chose the parameters so that both the curve and its twist have near-prime order [@curve25519-2006], [@safecurves-twist]. A hostile off-curve input therefore still lands you in a group where the discrete log is hard, and the invalid-curve attack of Section 4 is defused -- without any explicit on-curve check in the fast path.

A property of a curve whose quadratic twist also has near-prime order. Because a hostile input maps to a point on either the curve or its twist, and both groups are cryptographically hard, an off-curve input cannot be steered into a weak subgroup -- so invalid-curve attacks are defeated without an explicit on-curve validation step.

The new cost is the seed of the next two generations: Curve25519 does not have prime order. Its group has cofactor 8, so low-order points exist.Bernstein states the orders exactly: the curve over its base field has $8 \times \ell$ points, where $\ell$ is the prime $2^{252} + 27742317\ldots$, and its twist has $4 \times \ell'$ points for a different prime $\ell'$ [@curve25519-2006]. That factor of 8 is the cofactor the next two generations spend their effort taming. To keep secret scalars inside the safe range, X25519 clamps them. And clamping is the single most misunderstood step in the whole subject.

Forcing specific bits of an X25519 secret scalar: clearing the low three bits so the scalar is a multiple of the cofactor 8, clearing the high bit, and setting the second-highest bit so every scalar has the same length. Clamping constrains your own secret to sidestep small-subgroup and timing issues on your side. It is emphatically not validation of an input point someone else sends you.

Clamping clears the low three bits (making your scalar a multiple of 8, so multiplying a low-order input contributes nothing on your side), clears the top bit, and sets the second-highest bit so the ladder runs a fixed number of steps [@rfc7748].The X25519 clamp: scalar[0] &= 248 clears the low three bits, scalar[31] &= 127 clears bit 255, and scalar[31] |= 64 sets bit 254 [@rfc7748]. It protects you, the holder of the secret. It does nothing about a malicious low-order point arriving from outside -- which is why the Monero bug happened on a curve whose users clamped diligently.

Generation three: a complete addition law, and deterministic nonces

Curve25519 fixed key agreement, but signatures still lived on the branchy Weierstrass world or on Curve25519's cofactor. Ed25519 (2011) moved signing onto edwards25519, the twisted-Edwards curve birationally equivalent to Curve25519 [@ed25519-2011]. The payoff is Harold Edwards' 2007 normal form: a single addition formula with no exceptional cases at all [@edwards-2007]. Doubling, adding, the identity -- one formula handles them, so the code has no secret-dependent branch and is naturally constant-time at the group-law level, retiring the incomplete-addition surface. Ed25519 also pairs the curve with deterministic nonces, derived by hashing the message and a secret, which kill the catastrophic ECDSA per-signature-randomness disaster by construction (the nonce can no longer be repeated or biased by a weak RNG).

The cofactor did not vanish, though. edwards25519 still has cofactor 8, which is why signature malleability, non-canonical encodings, and disagreements about whether verification should be "cofactored" are real concerns -- and precisely why RFC 8032 specifies canonical-encoding checks, bounds on the signature scalar, and cofactor handling [@rfc8032]. The nonce disaster itself is this series' nonce-reuse post's territory; here it is enough that determinism closes the generation half of it.

Generation four: quotient the cofactor out of existence

The fourth generation asks a sharper question. Instead of patching every protocol to handle cofactor 8, what if the cofactor simply did not exist at the level you program against? Mike Hamburg's Decaf (2015) showed how: build a genuine prime-order group in the encoding on top of a cofactor curve, so that the torsion points are quotiented away and never appear as elements [@decaf-2015]. Ristretto255 is the cofactor-8 instantiation for edwards25519, standardized in RFC 9496 in 2023 [@rfc9496]. The consequence is the cleanest safety property in the whole article: decoding is validation. A sequence of bytes either decodes to a unique, legitimate prime-order element or it is rejected. There is no low-order point to submit, because low-order points are not representable.

flowchart TD A["Wire bytes for a ristretto255 element"] --> B{"Valid canonical encoding?"} B -->|No| C["Reject: not a group element"] B -->|Yes| D["Decode yields a unique prime-order point"] D --> E["No cofactor, no torsion, no small subgroup"] E --> F["Element is safe to use directly"] A group of prime order with no cofactor, constructed over the cofactor-8 curve edwards25519 by encoding equivalence classes of points rather than raw points. Because only valid prime-order elements have encodings, decoding a byte string is itself the validation step, and the entire cofactor and small-subgroup failure class disappears at the type level.

Curve448 and its prime-order sibling decaf448 play the conservative role: a larger, roughly 224-bit-security option standardized in the same family but far more thinly deployed than the 25519 curves [@ed448-goldilocks-2015], [@rfc9496]. Treat it as the extra-margin choice, not a rival to X25519's ubiquity.

The through-line

These four generations are not a strict succession where each kills the last. They coexist: P-256 remains FIPS-mandated, X25519 and Ed25519 split the key-agreement and signature jobs between them, and ristretto255 sits underneath new protocols that need a clean prime-order group. What each generation truly superseded was not its predecessor curve but the burden on the person writing the code.

Note: Each generation took a rule off the implementer and baked it into the curve, the group, or the encoding. Constant-time became the ladder's default. On-curve validation became twist security. Exception-free addition became the Edwards law. Cofactor handling became the ristretto255 encoding. The simple implementation kept becoming the secure one.

Curve	Form	Field prime	Cofactor	Constant-time	Twist secure	Coordinates	Best for
P-256 (secp256r1)	Short Weierstrass	2^256 - 2^224 + 2^192 + 2^96 - 1	1	With care (complete formulas)	No	Full (x, y)	FIPS certificates, ECDSA
secp256k1	Short Weierstrass	2^256 - 2^32 - 977	1	With care	No	Full (x, y)	Blockchain (Bitcoin, BIP-340)
Curve25519 / X25519	Montgomery	2^255 - 19	8	By construction	Yes	x-only (32 bytes)	Key agreement
edwards25519 / Ed25519	Twisted Edwards	2^255 - 19	8	By construction	n/a	Compressed point	Signatures
ristretto255	Prime-order over edwards25519	2^255 - 19	1 (effective)	By construction	Yes	32-byte encoding	New prime-order protocols

Four generations, each erasing one line of the failure catalog. Someone still had to name the law they were all obeying -- and to say out loud that a hard curve and a safe cryptosystem were never the same thing.

6. ECDLP-Hardness Is Not ECC-Security

In 2013, Daniel J. Bernstein and Tanja Lange put the entire argument of this article onto one website, with a claim engineered to provoke: if you implement the standard curves, chances are you are doing it wrong [@safecurves-index]. The website was SafeCurves, and it is the moment the field said the quiet part out loud.

There is a gap between ECDLP difficulty and ECC security ... if you implement the standard curves, chances are you're doing it wrong.

SafeCurves names four concrete places that gap opens: implementations that return wrong results on rare curve points, that leak secrets when fed off-curve inputs, that branch in secret-dependent time, and that leak through cache-timing [@safecurves-index]. Every one of those is a surface from Section 4. And the criteria SafeCurves proposes -- rigidity, twist security, complete addition, ladder support, a handled cofactor -- are not a beauty contest. They are a single design program stated as a checklist: choose the curve so that the easy implementation is the safe one. That is the whole of Section 5 compressed into one sentence.

Which lets us state the thesis in its most general form.

Key idea: Security is a property of the curve, the group, and the implementation together -- not of ECDLP alone. A hard discrete logarithm is necessary and nowhere near sufficient. Every generation in the previous section is this one sentence, applied to a different part of the stack.

The honest tension, handled carefully

It would be easy to read SafeCurves as a verdict that the NIST curves are unsafe. That reading is wrong, and getting it right is part of being an expert here rather than a partisan.

SafeCurves is a strong, deliberately opinionated argument from around 2013 to 2015, not a neutral consensus standard. NIST P-256 and P-384 do fail several of its criteria -- rigidity, twist security, complete addition in the naive formulas -- and yet they remain FIPS-mandated and, implemented with care, secure. The Renes-Costello-Batina complete formulas close the completeness gap in software [@rcb-2016], and vetted constant-time libraries close the rest. The defensible position is precise: P-256 is *harder to implement safely* than Curve25519, not *broken*. "Prefer 25519 for new designs" and "P-256 is unsafe" are different claims, and only the first is true [@safecurves-index].

The scorecard below is the honest version. Read a "No" or a "With care" as "the naive implementation needs help here," never as "this curve is broken." Prime order is where the NIST curves quietly win, and it is exactly what the 25519 curves trade away.

Curve	Rigidity	Twist security	Complete addition	Ladder-friendly	Prime order
P-256	No	No	With care	No	Yes
secp256k1	Partly	No	With care	No	Yes
Curve25519 / X25519	Yes	Yes	Yes	Yes	No (cofactor 8)
Ed25519	Yes	Yes	Yes	n/a	No (cofactor 8)
ristretto255	Yes	Yes	Yes	Yes	Yes

The footnote that keeps this table honest: every "No" for the NIST curves is a statement about the default implementation, not the mathematics. secp256k1 is marked "Partly" rigid because its parameters follow a stated efficiency rationale rather than an unexplained seed. Give P-256 complete formulas and a constant-time field, and its row stops mattering. That is why the state of the art is not a single crowned curve but a matter of knowing which curve already does which job for you -- and in 2026, that picture is unusually settled.

7. State of the Art (2024-2026): Which Curve Does Which Job

There is no single best curve to crown. The state of the art is a small, stable set, each member owning a job -- plus one transition quietly rewriting every handshake on the internet.

X25519 owns key agreement

For ephemeral key agreement, X25519 is the default answer. It is constant-time by construction, twist-secure, and moves 32 bytes per side; it is a standardized TLS 1.3 named group [@rfc8446], the Diffie-Hellman step in WireGuard's Noise handshake [@wireguard-protocol], and the key exchange in Signal, all built on the same Curve25519 arithmetic [@rfc7748]. For plain Diffie-Hellman you need no explicit point-validation code, because twist security already handles hostile inputs -- the operational rules reduce to rejecting the all-zero output and running the shared secret through a KDF rather than using it raw.

P-256 ECDSA owns FIPS certificates

P-256 is co-dominant, and for a specific reason: it is FIPS-mandatory for certificates [@fips-186-5]. Among the curves used in web certificates it is overwhelmingly the one [@ssl-pulse], now implemented with complete formulas or vetted constant-time assembly plus point validation on untrusted inputs [@sp-800-56a-r3]. Where a compliance regime names the curve, P-256 done carefully is exactly right.

Ed25519 is now FIPS-approved too

The important recent shift for signatures is regulatory. FIPS 186-5, published February 3, 2023, approves EdDSA alongside ECDSA [@fips-186-5], so Ed25519 is now both the technically cleaner option and a compliant one. It is standard in OpenSSH, in Git commit signing, and in package-signing tools such as minisign and OpenBSD's signify. Ed25519 needs about 87,500 CPU cycles to sign and about 273,000 to verify -- near 134,000 per signature when many are checked in one batch [@ed25519-2011] -- with the eBACS suite serving as the live cross-CPU benchmark authority [@bench-cr-yp-to]. The state-of-the-art guidance: Ed25519 for new designs, ECDSA where compliance compels it [@rfc8032].

secp256k1 owns blockchain, and only blockchain

secp256k1 carries an enormous deployment -- Bitcoin, Ethereum, and their descendants -- through ECDSA and, since Taproot, BIP-340 Schnorr signatures [@bip-340]. It is nonetheless essentially absent from web PKI and TLS. On any decision about a certificate or a general key exchange, secp256k1 is not a candidate; it is the answer only when the job is blockchain interoperability.

Ristretto255 is the prime-order substrate for new protocols

When a protocol needs a clean prime-order group -- password-authenticated key exchange, verifiable random functions, oblivious pseudorandom functions, threshold signatures, zero-knowledge systems -- ristretto255 (RFC 9496) is the current substrate [@rfc9496]. It is the recommended ciphersuite of the FROST threshold-Schnorr standard, which is defined generically over any prime-order group and also specifies Ed25519, Ed448, P-256, and secp256k1 suites [@rfc9591]; and it ships in production inside Signal's libsignal, whose zkgroup and zkcredential modules build on ristretto255 points [@libsignal].

The post-quantum overlay: ECC wrapped, not replaced

The headline of 2024 to 2026 is not a new curve; it is a wrapper. The hybrid X25519 plus ML-KEM-768 combines the classical curve with the NIST-standardized lattice KEM, and it is now shipping by default in Chrome and across Cloudflare's network [@cloudflare-pq-2024], and available in OpenSSH 9.9, released September 2024 [@openssh-9.9]. The motive is "harvest now, decrypt later": an adversary can record today's X25519 traffic and wait for a quantum computer, so the hybrid forces them to break both the curve and the lattice.Post-quantum-encrypted traffic on Cloudflare's network nearly doubled across 2025, from about 29% of human-generated web requests at the start of the year to roughly 52% by early December [@cloudflare-radar-2025], with a live tracker following the trend [@cloudflare-radar-pq-tracker].

The enabling techniques are themselves state of the art. The Montgomery ladder, the Renes-Costello-Batina complete formulas [@rcb-2016], and machine-checked, correct-by-construction field arithmetic (fiat-crypto, whose code for Curve25519 and P-256 ships inside BoringSSL) are what make these curves safe in practice rather than merely on paper [@fiat-crypto].

Note: It is not a single best curve. It is "the right curve for the job" -- X25519 for key agreement, Ed25519 for new signatures, P-256 where FIPS compels it, secp256k1 only for blockchain, ristretto255 for new prime-order protocols -- plus the hybrid transition that wraps the classical curve in a post-quantum KEM.

FIPS 186-5 approves EdDSA, so Ed25519 is now a compliant signature choice [@fips-186-5]; ECDSA over P-256 remains mandated for certificates; and SP 800-56A Rev. 3 requires point and subgroup validation for untrusted inputs in key establishment [@sp-800-56a-r3]. Compliance and good engineering point the same way more often than they used to.

"Which curve owns which job" is a summary, not a decision procedure. When the jobs overlap -- when a compliance regime, a blockchain, and a threshold protocol pull in three directions at once -- you need the head-to-head.

8. The Decision Matrix

The deployed curves do not all compete for the same job, so the useful comparison is per task -- and it hinges on one axis the benchmarks never advertise: how much of the failure catalog you must defend against by hand.

Key agreement: X25519 unless something forces your hand

Default to X25519. Its twist security and constant-time ladder mean the dangerous inputs are already handled, so your implementation burden is low: reject the all-zero shared secret and run the result through a KDF. Choose P-256 ECDH only where a compliance regime mandates it -- and then take on the full burden the curve leaves you: validate the peer point is on the curve and in the prime-order subgroup, use complete formulas or vetted constant-time code, and never feed the raw x-coordinate to anything but a KDF [@sp-800-56a-r3], [@rcb-2016]. Reach for X448 only when a policy demands a larger margin.

| Curve | Form | Security | Cofactor | Constant-time | Twist secure | Element | Safety burden | Compliance | | --- | --- | --- | --- | --- | --- | --- | --- | | X25519 | Montgomery | ~128-bit | 8 | By construction | Yes | 32 B | Low: reject zero, KDF the output | Not required for certificates | | P-256 ECDH | Short Weierstrass | ~128-bit | 1 | With care | No | 33 B compressed | High: validate point and subgroup, constant-time | FIPS-mandated | | X448 | Montgomery | ~224-bit | 4 | By construction | Yes | 56 B | Low | Extra-margin option |

The one rule that survives every row: never use the raw shared x-coordinate as a key. Run it through a KDF, as this series' key-derivation installment argues.

Signatures: Ed25519 for new work, ECDSA where mandated

For new designs, Ed25519 wins on the axis that matters -- it removes the per-signature randomness that has destroyed more ECDSA keys than any cryptanalysis, and its complete addition law removes the exceptional cases [@rfc8032]. Use ECDSA over P-256 only where a standard names it, and then defend it deliberately: RFC 6979 deterministic nonces, constant-time scalar multiplication, and point validation [@rfc6979]. BIP-340 Schnorr is the right choice for new Bitcoin work and nowhere else [@bip-340].

Scheme	Nonce	Nonce-failure blast radius	Addition law	Malleability rule	Sizes	Batch verify	Compliance
Ed25519	Deterministic (hash-based)	None by construction	Complete Edwards	Enforce canonical S and cofactor checks	64 B sig, 32 B key	Yes	FIPS 186-5 approved
ECDSA P-256	Random, or RFC 6979 deterministic	Catastrophic: a reused or biased nonce leaks the key	Incomplete Weierstrass	Low-S recommended	~64-72 B sig, 33 B key	Limited	FIPS-mandated
BIP-340 Schnorr	Deterministic with auxiliary randomness	Reduced versus ECDSA	secp256k1	Fixed by encoding	64 B sig, 32 B x-only key	Yes	Bitcoin only

Group abstraction: ristretto255 over hand-rolled cofactor clearing

If you are building a new prime-order protocol -- a PAKE, a VRF, an OPRF, a threshold scheme, a zero-knowledge system -- build it on ristretto255 rather than hand-rolling cofactor clearing over raw edwards25519 [@rfc9496]. Decode-is-validation removes the last implementation choice that could go wrong, which is the entire point of Generation four.

The cross-primitive view

Two comparisons sit outside this table but belong in your head. Against RSA, elliptic curves do the same public-key jobs with smaller keys and faster operations, and they share the reframe this series keeps returning to: the math was never the thing that broke. Against post-quantum schemes, ECC is not yet replaced -- the classical curve is the defense-in-depth half of a hybrid, present precisely because a lattice KEM is young and a recorded handshake is forever. Neither comparison changes a single row above; both change how long these rows stay valid.

Every row here assumes the curve's discrete log is genuinely hard. That assumption has a precise boundary -- and a hard expiration date.

9. Where the Hardness Lives, and Its Ceiling

Here is the uncomfortable pair of facts a first course tends to skip. For a well-chosen curve, the security level is exactly the generic bound -- there is no hidden margin above it, but nothing better is known either. And that entire edifice falls to a quantum computer in polynomial time.

The generic bound, matched from both sides

The best classical attacks on a well-chosen curve are generic -- they work in any group and know nothing special about elliptic curves. Pollard rho finds a discrete log in about $\sqrt{n}$ group operations for a group of order $n$, using parallel collision search with distinguished points and almost no memory [@safecurves-rho]. Pohlig-Hellman reduces the problem to the largest prime factor of the group order, which is the deep reason prime order matters: a smooth order is a soft target. Against those upper bounds sits a matching lower bound -- Shoup (1997) and Nechaev (1994) proved that any generic algorithm needs $\Omega(\sqrt{n})$ operations. Upper and lower bounds meet.

Note: For a well-chosen curve, the security level is the generic square-root bound itself: about $\sqrt{n}$ work, matched by a proven lower bound. That is solid -- but it means there is no safety margin hiding above the number, and, as we are about to see, a quantum cliff waiting below it.

That closed gap is genuinely unusual among cryptographic assumptions, and it is the whole reason a 256-bit curve is trusted at the 128-bit level.Most hardness assumptions leave a gap between the best known attack and the best provable lower bound. For generic ECDLP on a well-chosen curve, the two coincide at $\sqrt{n}$. You are trusting a bound that is tight, not merely unbroken. The reason no better attack exists is the absence we opened with: no index-calculus method is known that beats $\sqrt{n}$ on prime-field curves. Semaev's summation polynomials and the programs built on them have not produced one. The economic case of Section 2 is really this limit, seen from the other side.

Symmetric security	Elliptic-curve size	RSA / finite-field DH modulus
112-bit	224-bit	2048-bit
128-bit	256-bit	3072-bit
192-bit	384-bit	7680-bit
256-bit	512-bit	15360-bit

The table is the standard security-level mapping, and its middle row is the sentence everyone quotes: 256-bit ECC stands in for 3072-bit RSA at roughly 128-bit strength, because the curve attacker pays $\sqrt{n}$ while the RSA attacker enjoys sub-exponential index calculus [@safecurves-rho], [@miller-1985].

What "well-chosen" rules out

The generic bound holds only for curves that avoid a short list of special structures, and each item on that list is a curve that looks fine but collapses. The MOV reduction (Menezes, Okamoto, and Vanstone, 1993) maps a curve with low embedding degree -- supersingular curves are the extreme case -- into a finite field where index calculus applies, collapsing its ECDLP [@mov-1993]. Anomalous, or trace-one, curves, where the number of points equals the field prime, admit an additive transfer that solves the discrete log in polynomial time (Smart; independently Satoh-Araki and Semaev) [@smart-1999]. And the small-subgroup and twist conditions of Section 4 round out the list. "Well-chosen" is exactly "avoids these."

The one bound that is not the square root

Every limit so far is classical. The exception is the one that sets the deadline. Shor's algorithm (1997) solves both factoring and discrete logarithms -- including ECDLP -- in polynomial time on a fault-tolerant quantum computer [@shor-1997]. Resource estimates make it concrete: at equal classical security ECC is the easier quantum target -- breaking a 256-bit curve needs roughly 2,330 logical qubits and about $1.3 \times 10^{11}$ Toffoli gates, versus roughly 6,100 logical qubits for RSA-3072, so ECC's smaller keys are the smaller quantum target and fall first [@roetteler-2017]. No choice of curve escapes this; it is a property of the group structure Shor exploits, not of any parameter.

This is why today's ECDH traffic is already on a clock, before any quantum computer exists. An adversary records your X25519 handshakes now and decrypts them the day a machine can run Shor at scale. The recorded session is not refreshed; its forward secrecy is only as good as the assumption that the curve stays hard forever -- which Shor says it will not [@shor-1997]. That single fact, not any classical advance, is what put the hybrid transition of Section 7 on every roadmap.

If the mathematics is this settled -- a closed classical bound and a known quantum ceiling -- then everything still open lives in the code, the trust, and the migration. That is where the real frontier is.

10. What Remains Genuinely Unsettled

The core science is settled, and the failure catalog and its defenses are not in dispute. What is open sits at the edges -- and two of these are live in your dependency tree right now.

Constant-time is a perpetually moving target

Montgomery ladders and complete formulas close the obvious channels, and still the leaks keep reappearing at finer grain. Minerva recovered secp256r1 private keys from about 2,100 signatures by measuring how the nonce's bit-length shifted the signing time [@minerva-2020]. TPM-Fail pulled 256-bit ECDSA keys out of an Intel firmware TPM and an STMicroelectronics TPM despite their certifications [@tpm-fail-2020]. LadderLeak broke ECDSA with less than one bit of nonce leakage [@ladderleak-2020]. There is no general, machine-checkable guarantee of constant-time behavior that survives arbitrary compilers and microarchitectures. The lattice step that turns these leaks into keys belongs to this series' nonce-reuse post; the open problem here is the leakage itself.

The NIST-curve trust question is sociological, not solved

No weakness has ever been demonstrated in P-256 or P-384, and they remain FIPS-mandated [@safecurves-index]. Yet Dual EC DRBG proved that NIST-supplied constants could be poisoned, which is why a large part of the community prefers rigid curves for new work [@shumow-ferguson-2007]. This is not the kind of question a proof can close -- you cannot prove the absence of a motive. The practical resolution is a posture, not a theorem: prefer 25519 for new designs, use P-256 with care where compliance compels it.

The cofactor long tail

RFC 9496 eliminates the cofactor failure class -- for the protocols that adopt it [@rfc9496]. The long tail of deployed EdDSA and X25519 protocols that predate or simply ignore ristretto255 remains a live source of subgroup bugs, with Monero the canonical example [@loup-vaillant-cofactor]. This is a migration problem, not a research problem, which somehow makes it more stubborn rather than less.

The post-quantum migration, past the easy part

Hybrid key agreement is deploying fast [@cloudflare-radar-2025], but the interesting questions start after the first hybrid ships: how long ECC's small keys keep it useful inside hybrids, whether and when to drop the classical half, which combiner and negotiation are right, and the genuinely harder migration on the signature side, where the post-quantum replacements are large and awkward.

Formal verification at scale

fiat-crypto ships proven-correct field arithmetic for Curve25519 and P-256 inside BoringSSL, which is a real milestone [@fiat-crypto]. But end-to-end verification -- field, then group law, then protocol, then constant-time behavior on the actual target instruction set -- is not yet routine. The field-arithmetic layer is solved; the stack above it is not.

There is also a structural non-problem worth naming, so you can stop worrying about it: no one has found a faster-than-square-root attack on prime-field ECDLP, and the summation-polynomial work that raised hopes lives in binary and composite fields -- one more reason NIST now steers new work to prime-field curves: SP 800-186 deprecates the binary and Koblitz curves, retaining them only for legacy interoperability, and FIPS 186-5 dropped them from approval for new signatures [@sp-800-186], [@fips-186-5].

Note: Of the five open fronts, two are the ones likely to be in your stack today: a non-constant-time scalar multiplication somewhere in a dependency, and a protocol built on raw edwards25519 that never adopted ristretto255. The other three are the industry's problem. These two are yours.

Enough theory and frontier. Here is the entire article compressed into rules you can apply on Monday -- each one a named break from the catalog, turned inside out.

11. The Practical Guide and the Misuse Catalog

Every rule below is one row of the failure catalog, inverted. If you remember nothing else from this article, remember the decision tree.

flowchart TD A{"What is the job?"} --> B["Key agreement"] A --> C["Signature"] A --> D["Prime-order protocol"] A --> E["Long-lived confidentiality"] B --> B1{"FIPS-mandated curve?"} B1 -->|No| B2["X25519, reject zero output, KDF the result"] B1 -->|Yes| B3["P-256 ECDH, validate point and subgroup, constant-time, KDF"] C --> C1{"New design?"} C1 -->|Yes| C2["Ed25519, enforce canonical S, strict library"] C1 -->|Mandated| C3["ECDSA P-256, RFC 6979 nonce, constant-time, validate points"] D --> D1["Build on ristretto255 or decaf448"] E --> E1["Wrap X25519 in the ML-KEM-768 hybrid"]

The decision rules, in words

For key agreement, reach for X25519 by default: constant-time by construction, twist security handling hostile inputs, and one operational rule -- run the shared secret through a KDF and reject the all-zero output, never using the raw x-coordinate as a key [@rfc7748]. Use P-256 ECDH only where FIPS compels it, and then validate the peer point on the curve and in the prime-order subgroup, use complete formulas or a vetted constant-time library, and KDF the result [@sp-800-56a-r3], [@rcb-2016].

For signatures, choose Ed25519 for new designs -- deterministic nonces, a complete addition law, and a strict library that enforces the canonical-S check [@rfc8032]. Use ECDSA over P-256 only where mandated, with RFC 6979 deterministic nonces, constant-time scalar multiplication, and point validation [@rfc6979].

For point handling, always validate untrusted points -- on the curve and in the right subgroup -- remember that clamping is not validation, and never accept explicit curve parameters from a certificate or message; use named curves only, which is the whole lesson of Curveball [@cve-2020-0601]. For new prime-order protocols, build on ristretto255 or decaf448 instead of hand-rolling cofactor clearing [@rfc9496]. For long-lived confidentiality, deploy the X25519 plus ML-KEM-768 hybrid now rather than waiting for a pure post-quantum replacement.

Job	Use	Key parameters	Because (the named break)
Key agreement (default)	X25519	Reject zero output, KDF the secret	Raw-x misuse, twist security handles inputs [@rfc7748]
Key agreement (FIPS)	P-256 ECDH	Validate point and subgroup, constant-time	Invalid-curve TLS recovery [@jager-2015], timing [@brumley-tuveri-2011]
Signature (new)	Ed25519	Canonical S, strict library	Nonce disaster and malleability [@rfc8032]
Signature (mandated)	ECDSA P-256	RFC 6979 nonce, constant-time, validate	Nonce reuse or bias [@rfc6979]
Prime-order protocol	ristretto255 / decaf448	Decode is validation	Cofactor double-spend [@loup-vaillant-cofactor]
Certificates	Named curves only	Reject explicit parameters	Curveball [@cve-2020-0601]
Long-lived secrecy	X25519 + ML-KEM-768	Hybrid combiner now	Harvest-now-decrypt-later [@shor-1997]

Why "clamping is not validation" is a rule, not a slogan

The single most common confusion deserves a demonstration rather than an assertion. On a curve with a cofactor, an attacker can add a low-order point to a legitimate one. Clamping your secret scalar hides that tampering inside a Diffie-Hellman product -- so clamping alone cannot even detect it -- while an explicit prime-order subgroup check catches it immediately.

{` // Toy curve y^2 = x^3 + x over F_53. Group order 68 = 4 * 17 (cofactor 4, prime l = 17). const p = 53n, a = 1n, ELL = 17n; const mod = x => ((x % p) + p) % p; function inv(x){ let r=1n,b=mod(x),e=p-2n; while(e>0n){ if(e&1n) r=mod(rb); b=mod(bb); e>>=1n;} return r; } const eq = (P,Q) => (P===null&&Q===null) || (P&&Q&&P[0]===Q[0]&&P[1]===Q[1]); function add(P,Q){ if(P===null) return Q; if(Q===null) return P; const [x1,y1]=P,[x2,y2]=Q; if(x1===x2 && mod(y1+y2)===0n) return null; const s=(x1===x2&&y1===y2)? mod((3nx1x1+a)inv(2ny1)) : mod((y2-y1)inv(x2-x1)); const x3=mod(ss-x1-x2); return [x3, mod(s*(x1-x3)-y1)]; } function mul(k,P){ let R=null,b=P; while(k>0n){ if(k&1n) R=add(R,b); b=add(b,b); k>>=1n;} return R; }

const P = [6n,13n]; // legitimate prime-order point (order 17) const Low = [0n,0n]; // low-order point (order 2, divides the cofactor 4) const tampered = add(P, Low); // attacker adds a low-order component console.log('P and P+Low are distinct encodings?', !eq(P, tampered));

// Clamping forces the secret to a multiple of the cofactor, so it HIDES the tamper: const kClamped = 4n * 5n; // 20, a multiple of the cofactor 4 console.log('clamped [k]P equals clamped k?', eq(mul(kClamped,P), mul(kClamped,tampered)));

// The real defence is an explicit prime-order subgroup check [l]X == identity: console.log('subgroup check -- [l]P is identity?', mul(ELL,P) === null); console.log('subgroup check -- l is identity?', mul(ELL,tampered) === null); `}

The clamped multiplication reports the tampered point as identical, and only the $[\ell]X = \mathcal{O}$ subgroup check flags it. That is the Monero bug in nine lines: the code that needed to reject the tampered element was not the clamp, it was the subgroup test.

On most systems you can see the real curves in seconds. `ssh -Q key` and `ssh -Q kex` list your SSH key and key-exchange algorithms -- look for `ssh-ed25519` and a hybrid like `mlkem768x25519-sha256`. For TLS, `openssl s_client -connect example.com:443 -tls1_3` reports the negotiated group, often `X25519` or the hybrid `X25519MLKEM768`. Versions differ, but these tell you which curve and which post-quantum wrapper your traffic actually uses today, rather than which one you assume it does.

The misuse catalog

Each antipattern below is exactly one violated rule, and each maps to a named break you have now met:

Using the raw ECDH x-coordinate as a key. Run it through a KDF instead; the shared secret is an input to key derivation, not a key.
Treating clamping as validation. Clamping constrains your secret; it does not filter a hostile input point (Monero [@loup-vaillant-cofactor]).
Skipping point validation on Weierstrass curves. The formula ignores $b$, so an off-curve point is processed on a weaker curve (invalid-curve, Jager et al. [@jager-2015]).
Accepting explicit curve parameters. Trusting a generator you did not choose forges chains (Curveball [@cve-2020-0601]).
Non-constant-time or unvalidated P-256. Data-dependent timing is an oracle even with honest inputs (Brumley-Tuveri [@brumley-tuveri-2011]).
Ignoring the cofactor or non-canonical encodings in edwards25519 protocols. Low-order points and duplicate encodings break uniqueness (Monero [@loup-vaillant-cofactor]).
Rolling your own curve arithmetic. Use fiat-crypto-backed libraries; hand-written field code is where constant-time dies [@fiat-crypto].
Reusing or biasing ECDSA nonces. A repeated or leaky nonce hands over the key through a lattice (RFC 6979 fixes the generation half [@rfc6979]).

Note: If your time is limited, hunt these first: the raw ECDH x-coordinate used directly as a key; a P-256 ECDH path that neither validates the peer point nor runs in constant time; and any code path that accepts explicit curve parameters instead of a named curve. Those three account for most real elliptic-curve findings in production code.

Read the whole failure catalog again as this checklist, and one sentence remains true of every row.

12. The Curve Was Hard; The Gap Was Soft

Return to where we started. The NSA phoned Microsoft, and nobody solved a discrete logarithm [@cve-2020-0601]. That is not an anomaly; it is the whole pattern in one image. Across three decades of deployed elliptic-curve cryptography, almost no real break ever inverted the function the textbooks call hard. Attackers fed the implementation a point it should have rejected -- off the curve, or of small order, or a certificate's own untrusted generator (invalid-curve, small-subgroup, Curveball) [@jager-2015]. They added a low-order component that clamping never filtered (Monero) [@loup-vaillant-cofactor]. Or they simply read the clock while the code multiplied a secret (Brumley-Tuveri, and the Minerva-TPM-Fail-LadderLeak lineage) [@brumley-tuveri-2011].

Key idea: The curve was hard; the gap was soft. ECDLP-hardness bought the small keys and the speed, and it held every single time. The breaks all lived in the code, the trust, and the encoding around the curve -- the space between a hard problem and a safe system.

So "using elliptic curves safely" is not one decision but a stack: the right curve for the job, point and subgroup validation on every untrusted input, constant-time scalar multiplication, and -- the deepest lesson the evolution kept teaching -- a preference for constructions where the dangerous case cannot be reached at all, as ristretto255 makes literal [@rfc9496]. Remove any single layer and the gap reopens. And the horizon is honest about its own limit: the destination is not a better curve, because no curve survives Shor [@shor-1997]. It is wrapping the curve in a post-quantum hybrid and buying time.

The private curve stayed hard; the code around it confessed.

Which makes the diagnostic question we opened with finally answerable. When a point you did not generate arrives, what does your code reveal about it -- through its result, its timing, or the parameters it trusts? Using elliptic curves safely is the discipline of making that answer nothing an attacker can measure.

No weakness has ever been shown in P-256 or P-384. The real concern is *rigidity*: their generator and coefficient come from an unexplained seed, and the Dual EC DRBG affair proved that NIST-supplied constants *could* be poisoned in some other primitive. That history is why many engineers prefer rigid curves like Curve25519 for new designs. But "prefer 25519" is a different claim from "P-256 is broken," and only the first one is supported. No -- it is *harder to implement safely*, not broken. Its naive addition formulas have exceptional cases and it lacks twist security, so a careless implementation can leak. Complete addition formulas (Renes-Costello-Batina) and vetted constant-time libraries close those gaps. Implemented carefully, P-256 is secure and remains FIPS-mandated for certificates. For plain Diffie-Hellman, no on-curve check is required: Curve25519's twist security means a hostile input still lands in a hard group, so you just reject the all-zero output and run the result through a KDF. But low-order points still matter for protocols that need a genuine prime-order group. Validate or clear the cofactor there, or better, build on ristretto255 and let decoding do the validation. No. Clamping constrains *your own* secret scalar so a low-order component contributes nothing to your Diffie-Hellman product. It does nothing to validate a malicious input point, and it does not make a tampered point canonical. The Monero cofactor bug is exactly this confusion -- the fix was an explicit prime-order subgroup check, not clamping. Only if you are doing blockchain interoperability. secp256k1 is the Bitcoin and Ethereum curve; it is essentially absent from web PKI and TLS. For general key agreement use X25519, and for certificates use P-256. Reaching for secp256k1 outside the blockchain context is almost always a sign something is being reinvented. Use Ed25519 for new work: deterministic nonces remove the per-signature randomness that has destroyed more ECDSA keys than any cryptanalysis, the addition law is complete and constant-time, and EdDSA has been FIPS-approved since 186-5. Use ECDSA over P-256 only where a standard mandates it, and then with RFC 6979 deterministic nonces, constant-time scalar multiplication, and point validation. No. Shor's algorithm breaks the elliptic-curve discrete log in polynomial time on a fault-tolerant quantum computer, and at equal classical security ECC is the easier quantum target -- a 256-bit curve needs about 2,330 logical qubits versus roughly 6,100 for RSA-3072, so it falls first. Because recorded traffic can be decrypted later, deploy the X25519 plus ML-KEM-768 hybrid now rather than waiting for a pure post-quantum replacement.

One Secret Is Not One Key: The Discipline of Key Derivation with HKDF

noreply@paragmali.com (Parag Mali) — Sat, 11 Jul 2026 16:02:53 GMT

A raw shared secret is not a key -- it is key *material*. A Diffie-Hellman output is non-uniform and an ML-KEM output is single-use, and neither is safe to key a cipher with directly, so protocols run the secret through a key derivation function that does two separable jobs: **Extract** concentrates its entropy into one uniform pseudorandom key (it cannot *amplify* entropy -- that is where password hashing lives), and **Expand** stretches that key into many independent subkeys, each bound to a distinct context label [@rfc5869]. HKDF (RFC 5869) is the deployed instantiation, HMAC playing both roles [@rfc5869]; the TLS 1.3 key schedule is the flagship hierarchy built from it [@rfc8446], and post-quantum migration changed only what gets fed in, not the primitive [@draft-hybrid]. Get three rules right -- do not skip Extract, separate every key by context, bind the transcript -- and the named breaks such as Triple Handshake [@doi-sp2014] and Selfie [@eprint-2019-347] never happen to you.

1. One Secret Is Not One Key

You have just finished a Diffie-Hellman exchange -- or, in 2026, an ML-KEM encapsulation -- and you are holding a shared secret that no eavesdropper can compute [@fips203]. The obvious next move is to use it as your AES-256 key. That move is wrong, and it is wrong twice over. Those two reasons are the entire reason key derivation exists.

Reason one: the secret may not be uniform. A Diffie-Hellman output is a structured group element -- an integer of a particular form living in a particular subgroup, not a uniformly random string of bytes. A block cipher and a MAC both expect their key to be indistinguishable from random bits, and a raw group element simply is not that. RFC 5869 says it plainly: a Diffie-Hellman value "is NOT a uniformly random or pseudorandom string," so the extraction step "SHOULD NOT be skipped" [@rfc5869]. TLS 1.3 carries the same warning into its own design, never keying anything directly from the raw (EC)DHE value [@rfc8446].

An ML-KEM shared secret is the other case. FIPS 203 derives it from an internal hash (G, SHA3-512), so the secret is already a uniform 256-bit key rather than a structured value, and it is not entropy extraction that makes it safe [@fips203]. What ships in practice, though, is a hybrid: the input keying material is the concatenation of the ML-KEM secret and an X25519 secret, and because that concatenation still carries the non-uniform Diffie-Hellman half, the whole block goes through HKDF-Extract as one input [@draft-hybrid]. The rule you follow does not change -- run the shared secret through Extract -- but for ML-KEM the reason is the company it keeps, not its own distribution.

Reason two: one protocol needs many keys. A single connection almost never wants one key. TLS wants a client write key and a server write key, an initialization vector for each direction, an exporter secret, a resumption secret, and fresh keys after every update [@rfc8446]. If you carve all of those out of one secret naively -- or worse, reuse the same key for encryption and authentication -- a weakness in one use leaks into the others. The keys must be independent: learning one must tell an attacker nothing about the rest.

A KDF is a function that turns input keying material (IKM) -- a shared secret, a master key, or other high-entropy input -- into one or more output keys that are indistinguishable from random and independent of one another. It is the disciplined replacement for "just hash the secret."

Put the two reasons together and you get the sentence this entire article defends.

Key idea: One secret is not one key. A raw shared secret is material: possibly non-uniform, and dangerous to use for more than one purpose. Key derivation is the discipline of turning that one secret into a hierarchy of keys that are each uniform and mutually independent.

flowchart LR S["One shared secret (DH or ML-KEM)"] --> KDF["Key derivation"] KDF --> K1["Client write key"] KDF --> K2["Server write key"] KDF --> K3["Client IV"] KDF --> K4["Server IV"] KDF --> K5["Exporter secret"] KDF --> K6["Resumption secret"]

Everything that follows falls out of that picture as three rules. Rule one: do not skip Extract on a non-uniform secret. Rule two: do not reuse a derived key across contexts -- give each its own separation. Rule three: do not bind too little context, or two different situations will collapse to the same key.

Almost every famous break in this space -- the Triple Handshake attack [@doi-sp2014], the Selfie reflection [@eprint-2019-347], and the plain mistake of using a raw secret as a key [@rfc5869] -- is the violation of exactly one of these three rules. We will name each one in the catalog at the end.

Note: Never key AES, ChaCha20, or HMAC directly from a Diffie-Hellman or KEM output. It is raw material -- non-uniform, single-use, or both -- not a finished key. Treat it as input to a KDF, and derive every working key with its own context.

One scope boundary before we start. This article is about the high-entropy branch: secrets with real randomness in them, such as key-exchange outputs and master keys. Low-entropy inputs -- passwords and PINs -- live on a different branch (Part 12 of this series, on password hashing) for a reason we will make precise in the theory: Extract can concentrate the entropy already present, but it cannot invent entropy that was never there [@rfc5869].

If the fix is a named discipline, where did it come from -- and why did the field take roughly fourteen years to get it right?

2. Key Derivation Before It Had a Name

Long before anyone wrote "KDF" on a whiteboard, every protocol still faced the same task: one secret in, many keys out. And for about fourteen years, they all reached for the same tool -- hash the secret together with a counter and a label -- without ever quite agreeing on what that tool was supposed to guarantee.

Start with SSL 3.0 around 1996, from Netscape's Alan Freier, Philip Karlton, and Paul Kocher. Its key material came from a bespoke construction that nested MD5 and SHA-1 hashes over the master secret and the two hello nonces [@rfc6101]. There was no separation of concerns, no name for the two jobs it was quietly doing at once; it produced bytes, and the bytes looked random enough. TLS 1.0 openly descended from it: the RFC states it is "based on the SSL 3.0 Protocol Specification as published by Netscape" [@rfc2246].

timeline title Key derivation from 1996 to 2026 1996 : SSL 3.0 bespoke MD5 and SHA-1 key block 1999 : TLS 1.0 PRF, P_MD5 XOR P_SHA-1, feedback mode 2009 : NIST SP 800-108 expand-only PRF modes 2010 : HKDF extract-then-expand, RFC 5869 and CRYPTO 2010 2018 : TLS 1.3 staged key schedule 2020 : NIST SP 800-56C two-step converges on HKDF 2024 : ML-KEM standardized, PQ hybrids ship 2026 : NIST revises SP 800-56C for KEM secrets and KMAC

In January 1999, Tim Dierks and Christopher Allen gave the pattern its first careful specification: the TLS 1.0 pseudorandom function. It split the secret into two halves and computed P_MD5(S1, label + seed) XOR-ed with P_SHA-1(S2, label + seed), where each P_hash is an HMAC-driven feedback-mode expander (A(i) = HMAC(secret, A(i-1))) [@rfc2246]. The design hedged its bets across two hash functions so the result stayed secure if either one held.

It was the first mass-deployed protocol KDF -- and it was expand-only in spirit: it stretched a secret into blocks with a label and a feedback chain, with no explicit extraction step and no clean argument for what happens when the input is a structured Diffie-Hellman value rather than an already-random key.

A PRF is a keyed function whose outputs are indistinguishable from those of a truly random function, to anyone who does not hold the key. HMAC is the workhorse PRF of this whole story; Part 11 of this series covers it in depth. A KDF's expansion step is essentially a PRF chained in feedback mode, driven by a counter.

The same shape appeared in the public-key world. The ANSI X9.63 and IEEE 1363 working groups specified KDF1- and KDF2-style functions that produced keying material by hashing an (elliptic-curve) Diffie-Hellman shared secret together with a counter and some shared information [@sec1-v2]. RFC 5869 later named IEEE 1363a-2004 -- alongside NIST SP 800-56A and SP 800-108 -- among the schemes that "do not explicitly differentiate between the 'extract' and 'expand' stages, often resulting in design shortcomings" [@rfc5869].The ANS X9.63 standard itself sits behind a paywall, but SEC 1 v2.0 (section 3.6.1) documents the identical construction openly as ANSI-X9.63-KDF: Ki = Hash(Z || Counter || SharedInfo) over the shared secret Z [@sec1-v2]. Treat ANSI X9.63 as reported prior art of that "hash the secret with a counter and shared info" shape, not a scheme RFC 5869 names by title (the RFC names IEEE 1363a-2004, not X9.63).

Then NIST codified its own line: a concatenation KDF in SP 800-56A [@sp800-56a], and, in 2009, Lily Chen's SP 800-108 with its counter, feedback, and double-pipeline modes for deriving keys from an already-uniform key [@sp800-108-r1].

Look across all of them -- SSL 3.0, the TLS PRF, X9.63, IEEE 1363, SP 800-56A, SP 800-108 -- and one shape repeats: hash the secret with a counter and a label. So does one blind spot: no explicit Extract step, and no honest argument for a non-uniform input, because every design implicitly treated the hash as if it were a perfectly random function.

The two-hash hedge did not survive. TLS 1.2 replaced P_MD5 XOR P_SHA-1 with a single SHA-256 PRF, declaring that "this PRF with the SHA-256 hash function is used for all cipher suites" [@rfc5246]. The hedge added complexity without giving the modularity a real Extract/Expand split would later provide.

It is tempting to read a history of cryptography as a sequence of disasters, each fixed by the next design. This one is not that. The pre-HKDF KDFs were not catastrophically broken; they were *unproven and muddled*. Two lineages -- the IETF and academic line that became HKDF, and the NIST SP 800-56 and 800-108 line -- were separately groping toward the same structure. The interesting question is not "when did they break" but "why could nobody prove they were sound," and the answer is what finally split the field's one confused step into two honest ones.

These constructions shipped, and they protected real traffic for years without a headline disaster. So what, mechanically, was missing? Why could nobody prove they were sound?

3. Why "Just Hash the Secret" Cannot Be Proven Safe

Zoom in on the mechanics of the antipattern everyone kept reinventing: take the secret, hash it with a counter and a label, use the bytes. Two silent failures hide inside it, and one of them is the kind of bug you can never catch in a test -- only in a proof.

Failure one: a non-uniform input with no proof. Suppose your secret is a Diffie-Hellman value $g^{xy}$. It is unpredictable to an attacker, yes, but it is not uniform: it is an element of a specific group, with algebraic structure an adversary knows about. When you feed it straight into a hash and declare the output "random," you are making an assumption you cannot back up. There is no standard-model argument that H(g^{xy}) is indistinguishable from a random string. The only way the old designs "work" is if you pretend the hash is a perfect random oracle. Krawczyk put the indictment precisely: in practice most KDFs, including widely standardized ones, "follow ad-hoc approaches that treat cryptographic hash functions as perfectly random functions" [@eprint-2010-264].

Min-entropy measures a source's worst-case unpredictability. If its most likely value occurs with probability $p$, its min-entropy is $-\log_2 p$. This -- not the friendlier Shannon entropy -- is the quantity that governs extraction, because security must hold against an attacker who guesses the single likeliest value first.

Failure two: no context, so silent reuse. The homemade construction has nowhere to say what this key is for. With no distinct label bound into the derivation, the same secret hashed the same way yields the same bytes, and nothing stops a program from using those bytes for two different purposes. That is not a dramatic bug you can see; it is a latent precondition, the quiet setup behind attacks we will name later.

A randomness extractor is a function that takes a source with enough min-entropy but a non-uniform distribution and produces output statistically close to uniform. It is the formal object the "Extract" half of a KDF is supposed to be -- and precisely what "hash it and hope" fails to provide any guarantee of being.

There is also a concrete, testable hazard in the naive H(secret || info) form, separate from the proof problem.

Note: With a Merkle-Damgard hash (MD5, SHA-1, SHA-256), knowing H(secret || info) and the length of the secret lets an attacker compute H(secret || info || padding || suffix) for a suffix of their choosing -- without ever learning the secret. That is exactly why HMAC keys the hash instead of using raw H [@bck96-hmac], and why homemade concatenation KDFs are dangerous. Sponge and tree hashes (SHA-3, BLAKE3) are not vulnerable to this. Part 10 of this series covers the mechanism in full.

So why not fix it with a better hash, or more rounds? Because the real problem is not the hash function -- it is that a single step is being asked to do two different jobs with two different security requirements, and being proven for neither. Concentrating dispersed entropy into a uniform key is one job. Stamping out many independent context-separated keys is another.

The first of those two jobs even carries a measurable cost: concentrating entropy by purely statistical means is lossy -- the theory section later makes that tax precise -- which is exactly why the eventual fix used a computational extractor, keyed and analyzed under a computational assumption rather than a purely information-theoretic one [@eprint-2010-264].

Note: Concentrating entropy and separating keys are two different jobs, and the old designs did both at once in a single step that was proven for neither -- surviving only by pretending the hash was a perfect random oracle. Name the two jobs, prove each, and the confusion dissolves.

If hashing-with-a-counter cannot be proven sound for a non-uniform secret, the field did not need a different hash. It needed a different mental model. In 2010, one paper supplied it.

4. Krawczyk's Split: Two Jobs, Two Proofs

The insight that reorganized the field is almost embarrassing to state once you see it: the two jobs everyone had been doing at once are actually two different jobs, and they need two different proofs. In 2010 Hugo Krawczyk named them, separated them, and proved each -- and in doing so converted fourteen years of ad-hoc practice into a deployable primitive.

The first job is Extract. Treat it as a keyed computational randomness extractor: it takes the possibly non-uniform input keying material -- a Diffie-Hellman element, or a hybrid secret whose classical half is non-uniform -- and concentrates whatever entropy is dispersed inside it into one uniform pseudorandom key. Its defining limitation is the honest one from the previous section: it concentrates entropy, it cannot create it.

The second job is Expand. Treat it as a variable-length PRF: given that one uniform key, it stamps out arbitrarily many output keys, each independent of the others because each is bound to a distinct context string. The independence is not a hope; it is the PRF property, applied to distinct inputs.

The two-stage structure at the heart of HKDF. Extract concentrates a non-uniform secret's entropy into a single uniform pseudorandom key; Expand then derives many independent keys from that one key, each bound to a distinct context label. Splitting the derivation in two is what lets each half be defined, and proven, on its own terms. An extractor whose output need only be *computationally* indistinguishable from uniform, rather than statistically close to it. Keyed by the salt and analyzed under HMAC's pseudorandomness, it avoids the Leftover Hash Lemma's entropy tax -- at the price of resting on a computational assumption instead of an information-theoretic one.

The engineering move that made this practical was refusing to invent two new gadgets. Both stages are instantiated with the same primitive: HMAC. One construction, two roles. Extract is PRK = HMAC(salt, IKM); Expand is HMAC chained over its previous output (feedback mode, counter-stepped). Because HMAC was already everywhere, HKDF cost implementers essentially nothing new to adopt (Part 11 of this series treats HMAC as its own subject).

flowchart TD IKM["IKM -- the raw shared secret"] --> EX["HKDF-Extract, a computational extractor"] SALT["salt (optional, extract-time)"] --> EX EX --> PRK["PRK -- one uniform pseudorandom key"] PRK --> EXP["HKDF-Expand, a variable-length PRF"] INFO["info -- a distinct context per key"] --> EXP EXP --> OKM["OKM -- many independent subkeys"]

Two artifacts landed in 2010, weeks apart, and it is worth keeping them distinct. The interface is RFC 5869, "HMAC-based Extract-and-Expand Key Derivation Function," by Krawczyk and Pasi Eronen, published that May, whose stated goal was "to discourage the proliferation of multiple KDF mechanisms" [@rfc5869]. The theory is the CRYPTO 2010 paper, which supplied what the field had never had.

"...the first general and rigorous definition of KDFs and their security which we base on the notion of computational extractors." -- Hugo Krawczyk, "Cryptographic Extraction and Key Derivation: The HKDF Scheme," CRYPTO 2010 [@eprint-2010-264]

That is the whole reframing in one line. A KDF is not a fancy hash; it is an extractor followed by a PRF, and each has a definition and a proof. The paper analyzes the HMAC construction "based on the extraction and pseudorandom properties of HMAC," and is careful about "minimizing these assumptions as much as possible for each usage scenario" [@eprint-2010-264].

Here is the corroboration that it was a real discovery and not one team's preference: NIST arrived at the same structure independently. SP 800-56C Rev. 2, by Elaine Barker, Lily Chen, and Richard Davis (2020), standardizes a two-step "extraction-then-expansion" key-derivation method -- the identical shape -- for key establishment [@sp800-56c-r2], while SP 800-108 remains the expand-only sibling for inputs that are already uniform [@sp800-108-r1].

Two lineages, one design. When the IETF and academic line and the NIST line converge on the same two-step structure from different starting points, that is the signature of having found something true rather than merely convenient.

Note: A KDF is two functions with two security notions: an extractor that concentrates entropy into one uniform key (and provably cannot create entropy), and a PRF that stamps out arbitrarily many keys, each independent because each names a distinct context. Once you separate them -- and build both from the same HMAC -- everything the old designs groped toward becomes provable. Nothing was "broken"; the field finally named the two jobs.

A design and a proof are worth nothing until you can actually call the thing. What does the construction look like in code, and what, exactly, are salt and info for?

5. Extract, Then Expand: The Deployable Primitive

Here is the whole thing, worked. Two function calls you could implement this afternoon, and two knobs that do all the work.

Extract is one line. The salt becomes the HMAC key, and the secret becomes the message:

$$\mathrm{PRK} = \mathrm{HMAC\text{-}Hash}(\text{salt},\ \mathrm{IKM})$$

If you have no salt, RFC 5869 says use a string of HashLen zero bytes [@rfc5869]. The output is one uniform pseudorandom key.

The uniform, pseudorandom key that Extract produces from the input keying material. It is `HashLen` bytes long (32 for SHA-256) and is the sole keying input to every subsequent Expand call. Everything downstream depends only on the PRK, never on the raw secret again.

Expand is an iterated (feedback-mode) PRF: it chains HMAC over its own previous output block, the context string, and a single incrementing counter byte, then takes the first L bytes:

$$T(i) = \mathrm{HMAC\text{-}Hash}(\mathrm{PRK},\ T(i-1)\ \Vert\ \text{info}\ \Vert\ \mathrm{byte}(i)), \quad T(0)=\varepsilon$$

flowchart TD PRK["PRK"] --> T1["T1 = HMAC of PRK over info and byte 0x01"] T1 --> T2["T2 = HMAC of PRK over T1, info, byte 0x02"] T2 --> T3["T3 = HMAC of PRK over T2, info, byte 0x03"] T1 --> OKM["OKM = first L bytes of T1 then T2 then T3"] T2 --> OKM T3 --> OKM

That single incrementing byte is why the output has a hard ceiling: $L \le 255 \cdot \mathrm{HashLen}$ [@rfc5869]. Ask for more and the counter would overflow a byte.The counter starts at 1, not 0, so the largest block index is 255 -- hence the factor of 255 rather than 256.

The pseudorandom bytes Expand produces, which the caller slices into the actual working keys. A single derivation is capped at $255 \cdot \mathrm{HashLen}$ bytes; longer needs cannot be met by asking for a bigger `L`.

That cap is 8,160 bytes with SHA-256 and 16,320 bytes with SHA-512 -- comfortably more than any single key, but a real limit if you try to run HKDF as a general keystream generator. It is not one. Derive keys with it; use a stream cipher for streams.

None of this needs to stay abstract. The code below is HKDF built from nothing but HMAC-SHA-256, run on RFC 5869's own first test vector, so you can check the output against the standard.

{` // HKDF (RFC 5869) built from HMAC-SHA-256, run on the RFC's own Test Vector 1. const toHex = (buf) => Array.from(new Uint8Array(buf)).map((b) => b.toString(16).padStart(2, '0')).join(''); const hexToBytes = (h) => new Uint8Array(h.match(/../g).map((x) => parseInt(x, 16)));

async function hmac(keyBytes, msgBytes) { const key = await crypto.subtle.importKey( 'raw', keyBytes, { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']); return new Uint8Array(await crypto.subtle.sign('HMAC', key, msgBytes)); }

// Extract: concentrate the (non-uniform) IKM into one uniform PRK. async function hkdfExtract(salt, ikm) { return hmac(salt, ikm); }

// Expand: T(i) = HMAC(PRK, T(i-1) || info || byte(i)); OKM = first L bytes. async function hkdfExpand(prk, info, L) { const N = Math.ceil(L / 32); // SHA-256 output is 32 bytes let t = new Uint8Array(0); let okm = new Uint8Array(0); for (let i = 1; i <= N; i++) { // L must stay <= 255 * 32 = 8160 bytes const block = new Uint8Array(t.length + info.length + 1); block.set(t, 0); block.set(info, t.length); block.set([i], t.length + info.length); t = await hmac(prk, block); const merged = new Uint8Array(okm.length + t.length); merged.set(okm, 0); merged.set(t, okm.length); okm = merged; } return okm.slice(0, L); }

(async () => { const ikm = hexToBytes('0b'.repeat(22)); const salt = hexToBytes('000102030405060708090a0b0c'); const info = hexToBytes('f0f1f2f3f4f5f6f7f8f9'); const prk = await hkdfExtract(salt, ikm); const okm = await hkdfExpand(prk, info, 42); console.log('PRK =', toHex(prk)); // expect 077709362c2e32df0ddc3f0dc47bba63... console.log('OKM =', toHex(okm)); // expect 3cb25f25faacd57a90434f64d0362f2a... })(); `}

`PRK = 077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5` and `OKM = 3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865` -- byte for byte the values published in RFC 5869 Appendix A [@rfc5869]. If your implementation prints these two lines, your Extract and Expand are correct.

Now the two knobs. Salt is an extract-time input; RFC 5869 says a salt "adds significantly to the strength of HKDF," and although it is optional it is recommended when you have one [@rfc5869]. Info is an expand-time input, and it is the load-bearing one: distinct info strings give you independent keys for free, because RFC 5869 designed info precisely so that it "may prevent the derivation of the same keying material for different contexts" [@rfc5869].

A non-secret value used as the HMAC key during Extract. It is optional but recommended; RFC 5869 states it "adds significantly to the strength of HKDF." Unlike a nonce, a salt is fixed and reusable -- the same salt across many sessions is fine. Binding a distinct context label into each derivation so that keys for different purposes are cryptographically independent, even though they descend from one secret. In HKDF this is exactly the job of the `info` string.

Note: info is not decoration. It is the entire mechanism of key separation. Two Expand calls with the same PRK and the same info return identical bytes; two calls with different info return independent keys. Every key-separation bug in this article is, at bottom, a missing or duplicated info.

Run the separation yourself. From one PRK, two different info strings yield unrelated keys, and -- the part worth internalizing -- the same info yields the same key, which is the misuse made visible.

{` // Domain separation: one PRK, different info -> independent keys; same info -> identical. const toHex = (buf) => Array.from(new Uint8Array(buf)).map((b) => b.toString(16).padStart(2, '0')).join(''); const hexToBytes = (h) => new Uint8Array(h.match(/../g).map((x) => parseInt(x, 16))); const bytes = (s) => new TextEncoder().encode(s);

async function hmac(k, m) { const key = await crypto.subtle.importKey( 'raw', k, { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']); return new Uint8Array(await crypto.subtle.sign('HMAC', key, m)); } async function hkdfExpand(prk, info, L) { const N = Math.ceil(L / 32); let t = new Uint8Array(0), okm = new Uint8Array(0); for (let i = 1; i <= N; i++) { const block = new Uint8Array(t.length + info.length + 1); block.set(t, 0); block.set(info, t.length); block.set([i], t.length + info.length); t = await hmac(prk, block); const merged = new Uint8Array(okm.length + t.length); merged.set(okm, 0); merged.set(t, okm.length); okm = merged; } return okm.slice(0, L); }

(async () => { // Pretend we already ran Extract and hold this PRK. const prk = hexToBytes('077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5'); const encKey = await hkdfExpand(prk, bytes('app enc key'), 32); const macKey = await hkdfExpand(prk, bytes('app mac key'), 32); const encKey2 = await hkdfExpand(prk, bytes('app enc key'), 32); // same info as encKey console.log('enc =', toHex(encKey)); console.log('mac =', toHex(macKey)); console.log('distinct info -> independent keys? ', toHex(encKey) !== toHex(macKey)); console.log('same info -> identical keys? ', toHex(encKey) === toHex(encKey2)); })(); `}

People constantly confuse salt with a nonce. They are different animals, and so is info. Keeping the three straight prevents a whole class of bugs.

Input	What it is	When it acts	Reuse rule	Cost of getting it wrong
`salt`	Extractor strengthener (the HMAC key in Extract)	Extract time	Fixed, reusable across sessions	Weaker extraction, but not catastrophic
`info`	Domain / key-separation label	Expand time	Distinct per derived key	Two keys collide -> reuse across contexts
nonce	Per-message uniqueness for the AEAD	Encryption time	Never repeat under one key	Catastrophic cipher failure -- and not a KDF input at all

Part 2 of this series covers salt and nonce generation; the one thing to carry here is that a salt is safe to hardcode per protocol, while a nonce never is.

When may you skip Extract? Only when the input is already a uniform key -- an existing symmetric master key, or a PRK you extracted earlier. RFC 5869 has a section literally titled "To Skip or not to Skip," and the rule is exactly the entropy question: uniform input, Extract is wasted work; non-uniform input such as a Diffie-Hellman value, Extract "SHOULD NOT be skipped" [@rfc5869].

One more property, easy to miss now and load-bearing later: because Extract is HMAC(salt, IKM), the salt and the secret both flow through HMAC, and HMAC can be argued secure even when the fresh secret rides in on the message (IKM) side while the salt keys HMAC -- the swap, or dual-PRF, direction. That "either input can carry the security" behavior -- the dual-PRF intuition -- is what lets a post-quantum secret be bolted onto a classical one without a redesign. Hold that thought.

One Extract-and-Expand pair is a primitive. A real protocol needs a whole hierarchy -- many keys, chained and context-bound, across an entire handshake. What does that look like at production scale?

6. How HKDF Is Wired Today: The TLS 1.3 Key Schedule

The primitive froze in 2010 and has not been superseded. Everything called "state of the art" since is about wiring -- how you chain one Extract-and-Expand pair into an entire hierarchy without a separation bug. The flagship wiring is a diagram every TLS implementer has stared at: the TLS 1.3 key schedule, defined in RFC 8446 section 7.1 by Eric Rescorla in 2018, building on the OPTLS design of Krawczyk and Wee [@rfc8446] [@eprint-2015-978].

TLS 1.3 first defines two thin wrappers over HKDF. HKDF-Expand-Label is just HKDF-Expand with the label prefixed by the string tls13 , and Derive-Secret is HKDF-Expand-Label with the transcript hash of the handshake messages as its context [@rfc8446]. Then it chains a sequence of HKDF-Extract calls, each using the previous secret as the salt and a new secret as the IKM:

flowchart TD Z0["0"] --> E1["HKDF-Extract"] PSK["PSK"] --> E1 E1 --> ES["Early Secret"] ES --> B1["Derive-Secret: c e traffic (binds ClientHello)"] ES --> D1["Derive-Secret: derived"] D1 --> E2["HKDF-Extract"] DHE["(EC)DHE shared secret"] --> E2 E2 --> HS["Handshake Secret"] HS --> B2["Derive-Secret: s hs traffic (binds CH to SH)"] HS --> D2["Derive-Secret: derived"] D2 --> E3["HKDF-Extract"] Z1["0"] --> E3 E3 --> MS["Master Secret"] MS --> B3["Derive-Secret: s ap traffic (binds CH to server Finished)"] MS --> B4["Derive-Secret: res master (binds CH to client Finished)"]

Read what that structure buys. The chain Extracts on the non-uniform (EC)DHE value, so rule one is satisfied. Derive-Secret's label separates every key -- c hs traffic is not s hs traffic, so client and server never share a key -- satisfying rule two. And every secret binds a transcript hash, so two handshakes with different Hello randoms can never derive the same traffic keys, satisfying rule three [@rfc8446].

The schedule folds in a pre-shared key, then the (EC)DHE secret, then a final zero. Along the way it stamps out early-data secrets, handshake traffic secrets, application traffic secrets, an exporter secret, a resumption secret, and the PSK binder keys (ext binder and res binder) that "prevent the substitution of one type of PSK for the other" [@rfc8446].

Key updates ratchet forward with an HKDF-Expand-Label using the label traffic upd [@rfc8446]. The final working keys come from HKDF-Expand-Label(Secret, "key", ...) and HKDF-Expand-Label(Secret, "iv", ...), and those feed the AEAD cipher -- AES-GCM or ChaCha20-Poly1305, the subject of Part 7 [@rfc8446].

The RFC states the article's whole thesis in its own words, describing the shape of its own diagram.

"...the secrets shown down the left side of the diagram are just raw entropy without context, whereas the secrets down the right side include Handshake Context and therefore can be used to derive working keys without additional context." -- RFC 8446, section 7.1 [@rfc8446]

Left side, raw entropy; right side, entropy plus bound context. That is Extract and Expand, drawn as a protocol.

The same staged-Extract, labeled-Expand pattern reappears everywhere HKDF is deployed: HPKE (RFC 9180), MLS, the Noise framework behind WireGuard [@noise], and Signal, whose X3DH keys HKDF with a zero-filled salt and an application-identifier context [@signal-x3dh] and whose Double Ratchet builds forward-secure KDF chains from it [@signal-doubleratchet].

The post-quantum front changed the input, not the primitive

The genuinely new development of 2024 to 2026 is not a KDF. It is what gets fed into HKDF-Extract. To resist "harvest now, decrypt later," protocols now run a classical and a post-quantum key exchange side by side and combine the two shared secrets.

The recommended hybrid group [@iana-tls-groups], X25519MLKEM768, concatenates the ML-KEM-768 secret from FIPS 203 [@fips203] and then the classical X25519 secret, and hands the pair to the existing TLS 1.3 HKDF-Extract as its (EC)DHE input [@draft-hybrid]. Order matters for interop: the bytes are ML-KEM || X25519, and the group name deliberately lists the two components in the reverse order for historical reasons [@draft-ecdhe-mlkem].

flowchart LR M["ML-KEM-768 shared secret"] --> CAT["Concatenate: ML-KEM then X25519"] X["X25519 shared secret"] --> CAT CAT --> IKM["Hybrid IKM, a longer secret"] IKM --> EX["The same TLS 1.3 HKDF-Extract"] EX --> HS["Handshake Secret, schedule unchanged"]

No new KDF. No new schedule. The hybrid secret is just a longer IKM, and the security goal is "secure if either component is secure" -- the dual-PRF payoff foreshadowed in the previous section [@draft-hybrid]. This is the entire reason extract-then-expand aged so well: a brand-new kind of secret slotted in without touching the primitive.

Note: HKDF has not been replaced, improved, or deprecated since 2010. Every advance labeled "state of the art" -- the TLS 1.3 schedule, HPKE's labeled derivation, the post-quantum hybrids -- is a new way to wire the same two functions. When a primitive absorbs a shift as large as post-quantum migration with zero changes to itself, that is the sign it was designed at the right level of abstraction.

IANA assigned X25519MLKEM768 the codepoint 4588, that is 0x11EC, marked Recommended, and retired the earlier X25519Kyber768Draft00 at 0x6399 as obsolete [@iana-tls-groups].

How much of this is actually running? Time-stamp it, because it moves fast. Cloudflare reported that in early 2024 "nearly two percent of all TLS 1.3 connections" were post-quantum-secured, and expected "double-digit adoption by the end of 2024" [@cloudflare-pq]; Google documented Chrome's own migration to ML-KEM on the web [@google-blog]. Treat the two-percent figure as a dated snapshot, not a steady state.

The standards body is now catching up to the deployment. In January 2026 NIST announced it will revise SP 800-56C Rev. 2 to let the shared secret incorporate a secret from an approved KEM, to allow flexible formatting of hybrid shared secrets, and to approve KMAC "for the randomness extraction step (in addition to the expansion step)" [@nist-2026-news].

FIPS-validated systems cannot ship a construction the standard does not yet permit, so the standard is currently *behind* deployed TLS. Browsers concatenated a KEM secret into HKDF-Extract in 2024; NIST announced the matching revision to SP 800-56C in 2026 [@nist-2026-news]. That gap is not dysfunction -- it is the normal order of operations. Engineering ships the wiring, the standard blesses it once the analysis settles, and validation follows the standard.

TLS 1.3 is one superb design point. But HKDF is not the only KDF, and it is not always the right one. Given your input and your constraints, which do you actually reach for?

7. Choosing a KDF: The Design Space and a Decision Matrix

HKDF is not a monopoly. It is one answer to two orthogonal questions: does your input need extraction? and what is your compliance and library situation? Answer those two and the choice mostly makes itself. The methods below do not really race one another; they occupy different cells of an input-by-environment grid.

The extract-then-expand family handles non-uniform, high-entropy secrets: HKDF [@rfc5869] and the NIST SP 800-56C two-step method [@sp800-56c-r2]. The expand-only family assumes the input is already uniform and skips extraction: SP 800-108's counter, feedback, and double-pipeline modes over HMAC or KMAC [@sp800-108-r1], and libsodium's crypto_kdf over BLAKE2b [@libsodium]. A single-primitive school argues you never need a separate Extract step if the primitive earns separation structurally: KMAC and cSHAKE from a Keccak sponge [@sp800-185], and BLAKE3's derive_key, which takes a mandatory hardcoded context string [@blake3]. And SP 800-56C's one-step method is the "one call" middle ground [@sp800-56c-r2].

Method	Core primitive	Explicit Extract?	Non-uniform input?	Separation input	FIPS-approved	Best suited for
HKDF (RFC 5869)	HMAC	Yes	Yes	`info`	HMAC approved, cited in NIST guidance	DH/KEM secrets, protocol schedules
SP 800-56C two-step	HMAC or KMAC	Yes	Yes	`FixedInfo`	Yes	FIPS key establishment
SP 800-56C one-step	Hash / HMAC / KMAC	Folded into one call	Yes, with care	`FixedInfo`	Yes	FIPS, one-call ECDH
SP 800-108 (expand-only)	HMAC or KMAC	No	No, extract first	`Label` / `Context`	Yes	Subkeys from a uniform key
KMAC-as-KDF (SP 800-185)	Keccak sponge	Implicit (sponge)	Yes	customization string	Yes (SHA-3)	SHA-3 stacks, built-in separation
BLAKE3 `derive_key`	BLAKE3 tree hash	Implicit (tree)	Yes	`context`	No	High-throughput, non-FIPS
libsodium `crypto_kdf`	BLAKE2b	No	No, extract first	8-byte `context`	No	Ergonomic subkeys from a master key

The load-bearing row is "non-uniform input." If your secret is a raw Diffie-Hellman value, or a hybrid secret whose classical half is non-uniform, you need a real extractor -- HKDF, the 56C two-step, or a sponge or tree that doubles as one -- not a bare expander such as SP 800-108 or crypto_kdf, which assume you already hold a uniform key. A stand-alone ML-KEM secret is already uniform, so extraction there is a harmless safe default rather than a necessity. Everything else in the table is a secondary tiebreak.

libsodium's crypto_kdf can derive up to $2^{64}$ subkeys from a single master key and context, each between 128 and 512 bits, using an 8-byte string context plus a 64-bit subkey_id for separation [@libsodium]. It is delightful for subkeys -- and exactly wrong for a raw DH secret, because it never extracts.

So the decision rules compress to three lines. A uniform key and you need subkeys, reach for expand-only (HKDF-Expand, SP 800-108, KMAC, or crypto_kdf). A non-uniform high-entropy secret such as a Diffie-Hellman output, or a hybrid whose classical half is non-uniform, reach for extract-then-expand (HKDF or the 56C two-step). A low-entropy password, reach for a password hash (Argon2id), never a KDF from this table. Then the tiebreaks: need FIPS, use SP 800-56C or 800-108; on a SHA-3 stack, use KMAC; outside FIPS and chasing raw throughput on many long keys, use BLAKE3.

That last branch -- passwords -- deserves care, because it is where the worst mistakes happen and where terminology misleads people.

Password hashing is genuinely a kind of key derivation -- PBKDF2 literally stands for Password-Based Key Derivation Function. The distinction is not "KDF versus not-KDF"; it is *input entropy*. HKDF and Argon2id are adjacent branches of one family, split by whether the input has real entropy. The error is therefore *directional*: never run HKDF on a password, because Extract "cannot amplify entropy" [@rfc5869], and never run a deliberately slow, memory-hard password hash on a high-entropy DH or KEM secret. Part 12 of this series covers the low-entropy branch; here it only marks the boundary.

Note: You do not have to take my word on the boundary. BLAKE3's own documentation says it "is not a password hashing algorithm" and points you at Argon2 [@blake3]; libsodium keeps crypto_kdf and its password-hashing API strictly separate. Part 10 of this series covers BLAKE3 as a hash in its own right.

Honesty about performance: these constructions do not meaningfully compete on speed. Qualitatively, the KDF's cost is dominated by the surrounding public-key operation -- computing an X25519 or ML-KEM shared secret is orders of magnitude more work than the handful of HMAC compressions HKDF adds on top, as public cycle-count benchmarks for these primitives make plain [@ebacs]. Selection is driven by input assumptions, compliance, and library availability, not throughput.

Every method here, however clever, obeys the same wall: you can concentrate entropy but you can never create it. That conservation law -- and what it forbids -- is the theory underneath all of it.

8. You Cannot Create Entropy

The single most important result in this field is not an algorithm. It is a conservation law.

"The extract step in HKDF can concentrate existing entropy but cannot amplify entropy." -- RFC 5869, section 4 [@rfc5869]

Read literally, that sentence is the border of the entire subject. If the source IKM carries $m$ bits of min-entropy, then no KDF -- however clever, however many rounds, however long its output -- yields more than about $m$ bits of key security [@rfc5869]. A source with 20 bits of entropy cannot become a 128-bit key by any extractor that has ever been or will ever be designed.

This is exactly the wall between high-entropy KDFs and password hashing, and it explains why they are different branches. A password hash does not break this bound either. It cannot add entropy. What it adds is cost per guess: a salt to defeat precomputation, and deliberate slowness or memory-hardness to make each of the attacker's guesses expensive. The entropy of a weak password is still low after hashing; the attacker just pays more per attempt. Confusing "make guessing expensive" with "add entropy" is the conceptual error behind running HKDF on a password.

The conservation law also explains the shape of the 2010 fix. Purely statistical extraction is lossy: the classical Leftover Hash Lemma says that to land within statistical distance $\varepsilon$ of uniform you pay roughly $2\log_2(1/\varepsilon)$ bits of the source as overhead [@crypto-2004-dghkr]. A computational extractor -- HMAC keyed by the salt -- sidesteps that tax, delivering full-length pseudorandom keys under a computational assumption instead of an information-theoretic one [@eprint-2010-264]. You trade a little theoretical purity for not throwing away entropy you cannot spare.

So much for the lower bound. What is the upper bound -- what can the best construction actually promise? At the primitive level, HKDF is a secure KDF if and only if HMAC is simultaneously a good computational extractor (for Extract) and a good variable-length PRF (for Expand) [@eprint-2010-264]. A real gap in that story was closed only recently: the 2023 dual-PRF analysis proved HMAC is a PRF for keys of arbitrary length, in the standard model, with good multi-user bounds [@eprint-2023-861].

And at the schedule level -- the level that actually matters for a deployed protocol -- Fischlin and Gunther proved, in a multi-stage key-exchange model, that the TLS 1.3 handshake modes "establish session keys with their desired security properties under standard cryptographic assumptions" [@eprint-2020-1044]. That is the current ceiling on what we can prove about a whole deployed key schedule, not just one KDF call.

A function that stays a secure PRF whether it is keyed through its normal key input *or* through its message input. HMAC is relied on as a dual-PRF wherever a fresh secret arrives in the message slot -- as in the post-quantum hybrids of the previous section. The 2023 analysis shows this holds only for key sets satisfying a "feasibility" condition, which the authors argue real applications meet [@eprint-2023-861].

The honesty this section owes: the theory is settled at the primitive level but has live gaps at the edges. Some HKDF arguments are cleanest with a salt and standard-model assumptions, yet salt-less HKDF -- the common case, since TLS uses all-zero salts at several stages -- leans on stronger, more idealized assumptions [@rfc5869]. The community shorthand for the danger of over-modeling is blunt.

It is tempting to reason about HKDF as if it were a perfect random function -- the very habit that made the old designs unprovable. HKDF is *not* a random oracle, and treating it as one can prove things that are not true of the real construction. Its guarantees are the extractor and PRF properties of HMAC, no more. The dual-PRF result sharpens the same caution: the swap-key guarantee is *conditional*, holding only for feasible key sets, so each new post-quantum wiring must re-check that its secrets land in a feasible set [@eprint-2023-861]. Part 1 of this series covers the PRF and random-oracle assumptions these arguments rest on.

What would the ideal KDF be? A random oracle keyed by the secret: a black box that, for each distinct pair of secret and context, returns fresh independent uniform bits, with security equal to the secret's min-entropy and zero leakage across contexts. True random oracles do not exist, so that ideal is not reachable in the standard model. But extract-then-expand, with a distinct info per key, is the closest deployable approximation of it -- Extract gives "uniform from non-uniform" up to the entropy bound, and Expand-with-context gives "independent per query" up to PRF security.

Key idea: No KDF yields more key security than the min-entropy already in its input. That one conservation law is the entire border between HKDF and password hashing, and no amount of stretching moves it. Independence is not free either: if two derivations share a secret and bind the same or empty context, their outputs are identical -- which is not a theoretical nicety but exactly how the Triple Handshake and Selfie breaks happened.

The primitive-level theory is essentially finished. So where is the real frontier? Not in the KDF box -- in everything wired around it.

9. Open Problems at the Wiring Layer

Here is the tell that tells you where the frontier is: every named break in this space was a schedule-level bug, not a primitive-level one. The KDF itself is proven. The genuinely open, hard problems all live in how we wire it and how we prove the wiring.

How safe is plain concatenation as a post-quantum combiner? Deployed hybrids concatenate the classical and post-quantum shared secrets and feed the result to the existing HKDF-Extract [@draft-hybrid]. Is that generic construction always as good as a purpose-built combiner? Generic KEM-combiner theory gives black-box results -- the combined KEM is secure "as long as at least one of the ingredient KEMs is" [@eprint-2018-024]. The dedicated route, X-Wing, earns a tighter proof and better efficiency, but only because it fixes X25519, ML-KEM-768, and SHA3-256 concretely; its guarantees "may not apply in the general case" [@eprint-2024-039]. What is still missing is a clean, general characterization of when concatenation is safe -- covering KEM binding, ciphertext collisions, and how those interact with the rest of the schedule -- versus when a dedicated combiner is required. This is not academic: it guards a growing double-digit share of internet traffic during the migration.

X-Wing's efficiency and tight proof are specific to its exact primitive choices, so they should not be read as a general statement about concatenation. Its author list is deliberately not asserted here: the source page renders none, and prior search results were inconsistent [@eprint-2024-039].

The pending NIST revision is announced, not published. The January 2026 planning note says NIST will revise SP 800-56C to admit a KEM secret, allow flexible hybrid formatting, and approve KMAC as an extraction step [@nist-2026-news]. Until the document actually lands, the exact approved formatting for hybrid secrets and the KMAC-as-extractor parameters are unsettled.

Note: Treat the 2026 SP 800-56C revision as a planning note, not a specification. NIST has stated its intent to bless KEM secrets and KMAC extraction, but the parameters are not final [@nist-2026-news]. Design against the current standard and the IETF drafts, and be ready to adjust the formatting details when the revised document is published.

Nobody has machine-checked an entire modern key schedule. We can prove a great deal about one HKDF call; proving the whole hierarchy of a real protocol -- every stage, every label, resumption, 0-RTT, key updates, external PSKs -- is far harder, and symbolic and computational proofs cover different threat models. Symbolic analysis with Tamarin modeled all of the TLS 1.3 handshake modes and still surfaced an unexpected authentication behavior [@acm-tamarin]; computational multi-stage proofs fix a specific model and version [@eprint-2020-1044]. TLS 1.3 is among the most-analyzed protocols in history, and yet each proof pins one model and one version. The open goal is whole-schedule, machine-checked proofs that track the derivation graph -- labels, transcript binding, key separation -- for the newer hierarchies too: MLS, Signal's Double Ratchet, and the post-quantum hybrids.

Could a KDF API make misuse unrepresentable? Every real break here is a usage error the type system permitted: a skipped Extract, a missing or duplicated info, one Expand output split across two keys. Labeled wrappers push toward "you cannot derive a key without naming its purpose" -- TLS's HKDF-Expand-Label, HPKE's LabeledExtract and LabeledExpand with a suite identifier [@rfc9180], BLAKE3's mandatory context [@blake3]. But these are conventions, not enforcement: they encourage separation without preventing reuse. The open design problem is an interface -- in the type or effect system -- where forgetting the context, reusing an output, or truncating instead of re-deriving simply does not compile.

Is HMAC really a dual-PRF everywhere we now lean on it? The dual-PRF guarantee holds only for feasible key sets [@eprint-2023-861]. TLS 1.3, KEMTLS, MLS, and Noise all assume the swap direction, and the new post-quantum wirings feed novel, structured lattice secrets into the message slot. The open problem is a per-deployment or automated check that each new hybrid schedule's secrets land in a feasible set -- so the assumption is verified rather than assumed.

These are open at the research edge. But you have a protocol to ship this week. What does the whole discipline boil down to in practice?

10. A Practical Guide: What to Actually Type

Strip the theory to rules you can apply without reading a single proof. If you keep one diagram from this article, make it this one.

flowchart TD START["Your input keying material"] --> Q1{"Low-entropy password or PIN?"} Q1 -->|Yes| PW["Password hash: Argon2id (Part 12), not HKDF"] Q1 -->|No| Q2{"Already a uniform key?"} Q2 -->|Yes| EXPAND["Expand-only: HKDF-Expand, SP 800-108, KMAC, or crypto_kdf. Distinct label per subkey"] Q2 -->|No, a raw Diffie-Hellman value| EXTRACT["Extract-then-expand: HKDF or SP 800-56C two-step. Do not skip Extract, salt if you have one"]

That tree is the whole decision. A low-entropy password goes to Argon2id, never to HKDF, because Extract cannot manufacture the entropy a password lacks [@rfc5869]. A non-uniform high-entropy secret -- a Diffie-Hellman output, or a hybrid whose classical half is non-uniform -- goes to extract-then-expand, and you must not skip Extract [@rfc5869]. An already-uniform key goes to expand-only, with a distinct label for every subkey.

Once you are in the HKDF branch, a short checklist keeps you out of trouble:

Give every derived key its own info or label. This is rule two, made operational. Two keys, two distinct context strings.
Use a real salt when you have one, otherwise a fixed protocol-labeled salt. The salt strengthens extraction; the one input you must never omit is the context [@rfc5869].
Respect the output ceiling. A single derivation caps at $255 \cdot \mathrm{HashLen}$ bytes [@rfc5869]. Need more keys? Do more derivations with distinct labels -- never truncate one long output into two keys, and never split one Expand output across two purposes.
Adopt a labeling convention. TLS's Derive-Secret and HPKE's LabeledExtract and LabeledExpand are reusable templates even outside those protocols [@rfc8446] [@rfc9180]. They bake domain separation into every call.

A practical recipe for the info string is to give it structure: a protocol identifier, a version, the purpose, and, where authentication depends on it, the role or identity. "myapp v1 client write" is a better context than "key1", because it cannot accidentally collide with another purpose and it says what it is.

Including a hash of the messages exchanged so far as context in a derivation, so that a derived key is valid only for one exact conversation. TLS 1.3's `Derive-Secret` binds a transcript hash at every stage -- which is precisely what makes the Triple Handshake attack impossible against it.

You can make the correct behavior the only behavior. The wrapper below refuses to derive a key without a purpose label -- a small, self-imposed version of the misuse-resistant API from the open problems. Run it: the unlabeled call is blocked, and the two labeled calls produce independent keys.

{` // A Derive-Secret-style wrapper: no purpose label, no key. const toHex = (buf) => Array.from(new Uint8Array(buf)).map((b) => b.toString(16).padStart(2, '0')).join(''); const hexToBytes = (h) => new Uint8Array(h.match(/../g).map((x) => parseInt(x, 16))); const bytes = (s) => new TextEncoder().encode(s);

// Every derived key MUST name its purpose. The info encodes protocol, version, purpose. async function deriveKey(prk, purpose, lengthBytes) { if (!purpose || purpose.length === 0) { throw new Error('refusing to derive a key with no purpose label'); } return hkdfExpand(prk, bytes('myapp v1 ' + purpose), lengthBytes); }

(async () => { const prk = hexToBytes('077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5'); try { await deriveKey(prk, '', 32); // forgot the purpose -> blocked } catch (e) { console.log('blocked:', e.message); } const clientWrite = await deriveKey(prk, 'client write', 32); const serverWrite = await deriveKey(prk, 'server write', 32); console.log('client write =', toHex(clientWrite)); console.log('server write =', toHex(serverWrite)); })(); `}

You rarely need to implement any of this by hand. HKDF ships in OpenSSL (via EVP_KDF) [@openssl-hkdf] and BoringSSL (via the standalone HKDF, HKDF_extract, and HKDF_expand functions in hkdf.h) [@boringssl-hkdf], in Python's cryptography [@pyca-hkdf], in RustCrypto's hkdf [@rustcrypto-hkdf], and in Go's standard library.Go promoted HKDF into the standard library as crypto/hkdf in Go 1.24; before that it lived in golang.org/x/crypto/hkdf [@go124-notes]. The move is a small signal of how settled the primitive is -- stable enough to be standard-library furniture. For the expand-only and FIPS paths, reach for the SP 800-108 and 56C key-based derivation functions in your platform's crypto library.

Note: The single habit that prevents most KDF bugs: give every derived key an explicit, unique purpose string, and never reuse or split one. If your code derives a key without naming what it is for, that missing name is the bug. And keep the salt-versus-nonce line straight -- a salt is fixed and reusable, a nonce is per-message and must never repeat (Part 2).

Every rule above exists because someone shipped its opposite. Here is the catalog of what goes wrong -- and the three-rule lens that explains all of it.

11. The Antipattern Catalog, Root-Caused

Almost every notable, well-documented break in this space is the violation of one of the three rules from the very first section. Once you see the pattern, you cannot unsee it.

Break	Year	Root cause	Rule broken	Fix	Source
Triple Handshake	2014	Master secret not bound to the session transcript	Rule 3: too little context	Extended Master Secret	[@doi-sp2014] [@rfc7627]
Selfie	2019	Derived keys not bound to who is speaking	Rule 3: identity not bound	Bind role and identity	[@eprint-2019-347]
Raw secret as key	any	Skipped Extract on a non-uniform secret	Rule 1: do not skip Extract	Run Extract first	[@rfc5869]
Homemade `H(secret		info)`	any	No proof, plus length extension	Rule 1, and key the hash
One key for encrypt and MAC	any	One key serving two purposes	Rule 2: separate by context	Two distinct `info` strings	[@rfc5869]

Take the two famous ones in turn. In the Triple Handshake attack, an active attacker set up two TLS sessions so that both derived the same master secret, because that secret was not bound to the sessions' certificates and parameters -- breaking the authentication that resumption and renegotiation depend on [@doi-sp2014]. Root cause: too little context in the derived secret. The fix, the Extended Master Secret, bound the master secret to a hash of the full handshake, and TLS 1.3 later generalized that into per-stage transcript binding [@rfc7627].

In Selfie, a party using an external pre-shared key could be tricked into completing a handshake with itself -- a reflection -- because the derived keys were not bound to who was speaking [@eprint-2019-347]. Root cause: identity and role not bound. It is the same rule-three failure as Triple Handshake, wearing the costume of identity rather than transcript.

And the third break needs no research paper, because it is the antipattern from the opening: use the raw Diffie-Hellman or ML-KEM output directly as a key. For a Diffie-Hellman value that is skipping Extract, which RFC 5869 names and forbids in one clause; a uniform ML-KEM secret is still single-use, so using it directly collapses every purpose onto one key [@rfc5869].

The rest of the misuse list is the same handful of errors: a homemade H(secret || info) that has no proof and leaks by length extension; reusing one derived key for both encryption and its MAC, or splitting one Expand output across two purposes; a missing or duplicate info that silently collides two keys; running HKDF on a password; confusing a fixed salt with a per-message nonce; and truncating a longer output rather than re-deriving with the right length and label [@rfc5869].

Note: If you remember a single prohibition from this article, make it this: never key a cipher or a MAC directly from a raw Diffie-Hellman or ML-KEM secret. A Diffie-Hellman value is non-uniform, so skipping its Extract step is rule one -- the root of the whole misuse catalog, and RFC 5869 spells it out, the extract step "SHOULD NOT be skipped" [@rfc5869]. An ML-KEM secret is already uniform but single-use, so it still must be expanded into a distinct key per context before it goes near a cipher.

No. A Diffie-Hellman output is non-uniform; an ML-KEM output is already uniform but single-use; neither is a finished key. Run HKDF-Extract to get a uniform PRK, then Expand a distinct key for each use with its own `info` string. In the deployed X25519MLKEM768 hybrid the concatenated secret still needs Extract, because its classical X25519 half is non-uniform [@rfc5869]. No. A homemade `H(secret || context)` has no security proof for a non-uniform input, and with a Merkle-Damgard hash such as SHA-256 it invites length-extension attacks. Use HMAC-based HKDF instead; Part 10 covers the hashing details [@rfc5869]. They are one family split by input entropy, and the error is directional. Use HKDF for high-entropy secrets such as DH and KEM outputs; use Argon2id for passwords. Never run HKDF on a password -- Extract cannot amplify entropy -- and never run a slow, memory-hard password hash on a high-entropy DH or KEM secret [@rfc5869]. The `salt` and `info` are both optional in RFC 5869 but recommended. A salt strengthens extraction, and a fixed protocol-labeled salt is acceptable when you have no fresh one. The context input, `info`, is the one you must never omit -- it is what separates your keys [@rfc5869]. No. Derive two keys with two distinct `info` strings. Never split one Expand output across two purposes, and never truncate a longer output into two keys -- re-derive with distinct labels instead [@rfc5869]. No. An ML-KEM shared secret is just another high-entropy input. Deployed hybrids concatenate the classical and post-quantum secrets and feed the pair into the same, unchanged HKDF-Extract [@draft-hybrid]. The primitive did not change; only what you feed it did [@fips203].

So return to the moment we started in: the handshake is done, the shared secret is in your hand, and the tempting one-liner is to use it as a key. You now know why not, twice over, and you know the discipline that replaces the temptation. Extract concentrates the entropy that is there -- never inventing what is not. Expand, with a distinct context for every key, stamps out independence. Bind the transcript and the identities, and two situations can never collapse into one key.

The TLS 1.3 schedule is not a special trick; it is simply what obeying all three rules at once looks like, drawn as a protocol -- and post-quantum migration proved the design right by changing the input without touching the primitive.

Key idea: One secret is not one key. Extract concentrates entropy and can never amplify it; Expand plus a distinct context stamps out independent keys; and binding the transcript keeps two conversations from ever sharing a key. Get those three right and the named breaks never reach you. Reach for the raw secret, and you have already made the one mistake the whole discipline exists to prevent.

Part 14 turns from deriving keys to spending them: the authenticated encryption those traffic keys feed. But the habit you carry out of this one is smaller and sharper than any schedule -- never again reach for the raw secret.

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

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

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

1. The Modulus Was Never Factored

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

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

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

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

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

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

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

2. A Trapdoor for Diffie-Hellman's Challenge

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

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

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

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

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

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

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

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

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

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

3. Why Textbook RSA Is Not a Cryptosystem

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Front B: the physical layer

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

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

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

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

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

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

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

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

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

Front C: the parameters

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Idea 3: the one the first two kept teaching

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

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

Three disciplines close the three channels the catalog exposed:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

And for signing:

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

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

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

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

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

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

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

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

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

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

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

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

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

10. Open Problems: What Remains Genuinely Unsettled

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

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

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

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

11. The Practical Guide and the Misuse Catalog

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

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

Spelled out as decision rules:

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

The same rules as a lookup table:

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

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

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

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

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

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

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

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

12. Trapdoor, Not Cryptosystem

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

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

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

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

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

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

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