Parag Mali - tag: side-channel-attacks

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

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

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

1. Seven Breaks, One Unbroken Problem

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

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

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

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

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

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

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

2. What the Math Actually Promises

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

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

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

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

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

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

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

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

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

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

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

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

3. Three Contracts the Deployment Signs and Never Reads

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

The nonce contract: k must be fresh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pillar 2: the parameters, unvalidated (CurveBall)

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

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

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

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

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

Pillar 3: the negotiation, downgraded (Logjam)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Validation: reject what you cannot vouch for

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

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

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

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

Negotiation: remove the weak option entirely

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

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

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

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

7. Competing Approaches: Which Defense Answers Which Adversary

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

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

Nonce: which signing discipline stops which adversary

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

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

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

Validation: three philosophies of not trusting your input

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

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

Downgrade: hardening, deletion, or hedging against tomorrow

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

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

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

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

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

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

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

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

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

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

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

The leakage side: no room to hide a little bias

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

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

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

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

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

9. Where EC and DH Still Break in the Field

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

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

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

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

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

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

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

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

10. What to Do on Monday

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

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

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

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

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

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

11. FAQ: Misconceptions, Precisely Corrected

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

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

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

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

How ML-KEM Breaks in Real Life: The Machine Leaked While the Math Held

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

ML-KEM (FIPS 203) is the first standardized post-quantum KEM, and as of publication its Module-LWE mathematics is unbroken -- the IND-CCA2 security of its Fujisaki-Okamoto construction is even machine-checked [@fvk], and the two headline quantum "breaks" both failed to withstand expert scrutiny -- Chen withdrew his own claim, and Luo's was refuted by named experts [@chen2024][@postquantum-luo]. Yet every real attack on it has recovered secret keys anyway: KyberSlash through a variable-time division instruction disclosed in December 2023 [@kyber-commit][@kyberslash-paper], Clangover through a compiler that reintroduced a secret branch [@clangover], and fault attacks like Carry Your Fault straight through the masking meant to stop them [@carry-fault]. The through-line is a law two decades old, first seen when AES was attacked at the implementation and never at the cipher [@bernstein2005]: a security proof constrains values, not execution, so the attacker's frontier moves outward -- instruction, compiler, construction, countermeasure -- and never has to reach the lattice. This article catalogs each documented break from its primary source and shows you how to choose an ML-KEM implementation that does not leak.

1. A fortress breached at the doorknob

On 13 August 2024, the U.S. National Institute of Standards and Technology published FIPS 203 and gave the world its first standardized post-quantum key-encapsulation mechanism: ML-KEM [@fips203]. It arrived with something almost no cipher in history has had at birth -- a machine-checked mathematical proof that the construction is secure [@fvk]. Eight months earlier, on 1 December 2023, the maintainers of its reference code had quietly committed a patch to stop that same code from handing an attacker the full secret key [@kyber-commit]. Not through any weakness in the lattice mathematics. Through a single division instruction.

The proof was about the numbers. The attack was about the machine. This article is about the gap between them.

A KEM is a three-algorithm protocol -- key generation, encapsulation, and decapsulation -- for agreeing on a shared secret over an insecure channel. Encapsulation takes a public key and outputs a ciphertext plus a shared secret; decapsulation takes the ciphertext and the private key and recovers the same shared secret. ML-KEM is the KEM standardized in FIPS 203, derived from CRYSTALS-Kyber, and its security rests on the Module Learning With Errors problem [@fips203].

Here is the thesis this article defends: as of publication, every documented attack on ML-KEM is an implementation attack. Not one has touched the Module-LWE mathematics. The keys have been recovered through a division instruction, a compiler optimization, and a fault injected into a countermeasure -- never through the lattice. This is exactly the class of attack that its structural-mathematics sibling, "How ML-KEM and ML-DSA Would Break," deliberately sets aside to ask how the primitive itself might one day fall. That article studies the door; this one shows you that so far, every intruder has come through the doorknob.

There is no documented in-the-wild exploitation of a production ML-KEM deployment as of publication. The "breaks" cataloged here are of three honest kinds: vulnerable code shipping in the reference implementation and downstream libraries; CVE-class advisories such as RUSTSEC-2023-0079 [@rustsec]; and researcher proof-of-concept key recovery on real hardware [@kyberslash-paper]. That is stronger for the thesis, not weaker. The implementation layer broke first, at deployment scale, before the primitive had finished rolling out -- which is precisely what the pattern predicts.

And it has finished rolling out into places that matter. Google's BoringSSL and the Go standard library's constant-time crypto/mlkem both ship ML-KEM today [@kyberslash-site][@go-mlkem], as do filippo.io/mlkem768 and the vectorized AVX2 reference paths [@kyberslash-site]. The common deployment shape is a hybrid key exchange, X25519MLKEM768, that stays secure if either half holds [@tls-hybrid] -- a hedge, as we will see, against both a future math break and a present implementation bug. When we say the reference code was leaking keys, we mean the code from which production ML-KEM was built.

The proof was real. So where did the key go? To answer that we have to be precise about what the proof actually promises -- and what it does not.

2. The contract: what ML-KEM actually promises

A security proof is a legal contract, and like every contract it binds only what it names. Read ML-KEM's proof carefully and you find it makes a precise, narrow promise about what an adversary can learn from a public key and a set of ciphertexts. It says nothing at all about how many clock cycles decapsulation takes, what assembly the compiler emits, how the power rail fluctuates, or what happens when a cosmic ray flips a carry bit. Those are not loopholes in the contract. They are simply not in it.

ML-KEM began life as CRYSTALS-Kyber, presented at IEEE EuroS&P in 2018 as "a CCA-secure module-lattice-based KEM" [@kyber2018]. Six years of analysis and a NIST competition later, it became FIPS 203 with only modest changes [@fips203]. Its security rests on one hard problem.

Module-LWE hides a short secret vector inside a system of noisy linear equations over a polynomial ring modulo a public prime $q = 3329$. Given many pairs $(\mathbf{a}, \mathbf{a}\cdot\mathbf{s} + e)$ with small error $e$, recovering the secret $\mathbf{s}$ is believed hard for both classical and quantum computers. ML-KEM uses a module of rank 2, 3, or 4 to produce its three security levels; the internals of why the problem is hard belong to the companion article on how the lattice itself might fall [@kyber2018][@fips203].

The module rank is the only structural dial, and it defines the three parameter sets.

Parameter set	Module rank	FIPS 203 security category	Typical role
ML-KEM-512	2	Category 1	Lightweight
ML-KEM-768	3	Category 3	Default / recommended
ML-KEM-1024	4	Category 5	High assurance

The modulus $q = 3329$ is a public constant baked into the standard.Everyone knows the divisor. What is secret is the numerator the divisor acts on -- the coefficients of the decrypted polynomial. That asymmetry, a public modulus dividing a secret operand, is the entire seed of the first break in the catalog. That distinction between the public and the secret operand is worth holding onto; it returns with a vengeance in Section 4.

Now picture the whole story as a set of concentric layers around that untouched mathematics.

flowchart LR M["Layer 0: Module-LWE mathematics (unbroken)"] I["Layer 1: the instruction (KyberSlash)"] C["Layer 2: the compiler (Clangover)"] F["Layer 3: the construction (FO plaintext-checking oracle)"] K["Layer 4: the countermeasures (Carry Your Fault)"] M --> I --> C --> F --> K

Why does an active adversary matter here? Because a KEM that only resisted passive eavesdroppers -- the property called IND-CPA -- would be useless for a reused key. Real deployments reuse a decapsulation key across many sessions, and an attacker who can submit chosen or malformed ciphertexts and watch the results needs a stronger guarantee.

IND-CCA2 is the gold-standard secrecy notion for a KEM: even an adversary who can submit ciphertexts of its choosing and observe how the system responds cannot distinguish the real shared secret from random. It is exactly the notion you need when one long-lived private key decapsulates attacker-supplied ciphertexts, which is how KEMs are used in practice [@fips203].

Kyber reaches IND-CCA2 from a weaker IND-CPA core using a classic construction.

The FO transform, introduced in 1999 [@fo1999] and given its modern implicit-rejection analysis in 2017 [@hhk2017], upgrades a passively secure encryption scheme to an actively secure KEM. On decapsulation, it decrypts the ciphertext to a candidate message, then re-encrypts that message and checks whether the result matches the ciphertext it received. A genuine ciphertext re-encrypts to itself; a tampered one does not.

What happens on a mismatch is the hinge of the entire article.

When re-encryption does not match, ML-KEM does not return an error. It returns a pseudorandom shared secret $\bar{K} = J(z, c)$, derived by hashing a secret rejection seed $z$ together with the ciphertext $c$. To the caller, a rejected ciphertext is indistinguishable from an accepted one -- there is no decapsulation-failure signal to query. By construction, the FO transform gives an attacker no caller-visible oracle [@fips203]. flowchart TD A["Ciphertext c arrives at decapsulation"] B["Decrypt c to a candidate message"] C["Re-encrypt the candidate to c-prime"] D{"Re-encryption matches?"} E["Return the true shared secret K"] F["Return pseudorandom K-bar equals J of z and c"] A --> B --> C --> D D -->|yes| E D -->|no| F

That construction is not just believed secure; in 2024 a team machine-checked the IND-CCA2 security and correctness of Kyber in EasyCrypt, tying the proof to a real implementation [@fvk]. So the baseline is as strong as cryptography gets: the mathematics is unbroken, and the reduction from it to the KEM has been verified by a computer.

A security proof is a contract about values; a side channel is a breach in execution.

And there is the first shift in understanding. The proof constrains what an adversary learns from the specified inputs and outputs -- the values. It is silent on cycles, on emitted assembly, on power traces, on a flipped carry bit -- the execution. The key can walk out through the machine while the proof stays perfectly true. The contract is airtight about values. But the contract is run by a machine, and the machine is where this story happens. Before we watch it leak, one piece of history tells us it was always going to.

3. The precedent: AES was attacked at the implementation, never at the cipher

In April 2005, a widely used, carefully written AES implementation was handing out its key. Not to a cryptanalyst who had found a weakness in the cipher, but to a stopwatch. Daniel J. Bernstein showed that the time AES took to encrypt depended on its secret key, because the standard software used secret-indexed table lookups whose cache behavior varied with the data [@bernstein2005]. The cipher was fine. The code was leaking. The same researcher would, eighteen years later, be among the first to flag the division timing in Kyber [@kyberslash-site].

A side-channel attack recovers secrets not from the mathematical output of an algorithm but from physical or behavioral byproducts of running it: elapsed time, cache state, power consumption, electromagnetic emissions, or the effect of induced faults. The algorithm can be perfectly secure on paper and still leak through the machine executing it.

A year later, Osvik, Shamir, and Tromer turned Bernstein's observation into a general methodology, naming the Prime and Probe and Evict and Time techniques that let one process read another's cache footprint and recover an AES key from a few thousand encryptions [@ost2006]. Cache-timing attacks became a standard tool, and "How AES Breaks in Real Life," the earlier article in this series, is largely their story.

Now the counterweight, and it is the whole point. In all the years since, the AES mathematics has barely moved. The best known single-key attack on the full cipher is the 2011 biclique cryptanalysis, which recovers an AES-128 key in about ${2}^{126.1}$ operations rather than the ${2}^{128}$ of brute force [@biclique2011]. That is a speedup of less than a factor of four against a number with thirty-nine digits -- a result its own authors framed as not threatening the practical use of AES.

Two decades of the world's best cryptanalysts, and the cipher's security margin shrank by two bits, while its implementations leaked keys to a stopwatch in an afternoon.

Note: A strong new primitive is attacked at the implementation first, and often only ever there. The mathematics is the hardest thing to break and the last thing to fall; the code around it is where the keys actually walk out. AES lived this for twenty years. ML-KEM, as of publication, is living it from the moment it was born.

If that law holds, ML-KEM's first breaks should be implementation breaks -- and the theory behind them should already exist. It does. Years before FIPS 203, researchers had worked out exactly how to attack a CCA-secure lattice KEM through its physics. In 2019, Ravi and colleagues demonstrated generic side-channel key recovery against CCA-secure lattice-based PKE and KEMs, exploiting the decryption-failure structure of these schemes [@ravi2019]. In 2021, Ueno and colleagues published "Curse of Re-encryption," showing that the FO re-encryption step itself is a generic power and electromagnetic oracle across post-quantum KEMs [@ueno2021].Bernstein bookends both halves of this series: the 2005 cache-timing attack that defined how AES breaks, and the 2023 division-timing flag that opened how ML-KEM breaks. The same person, the same lesson, eighteen years apart.

So the blueprint for breaking ML-KEM's implementation was drawn before the standard was finished. If the pattern holds, the first real breaks should show up early, maybe before the ink on the standard is dry. They did. Here is the catalog.

4. The catalog: the frontier moves outward

Here is the pattern to watch as we walk the documented breaks: each one lands one layer further from the mathematics than the last. The first is a single machine instruction. The second is the compiler. The third is the construction that proves the whole scheme secure. The fourth is the countermeasure built to stop the third. Not one of them reaches the lattice.

timeline title The frontier moves outward, December 2023 to 2025 2023 : KyberSlash1 patched on 1 December, commit dda29cc : Bernstein flags it possibly exploitable on 15 December : KyberSlash2 disclosed on 30 December 2024 : Clangover compiler-introduced branch : Carry Your Fault on masked Kyber : FIPS 203 standardized on 13 August 2025 : KyberSlash paper at IACR TCHES, a CHES best paper

The whole break surface fits in one table, and every number in it comes from a primary source.

Layer	Attack	Mechanism	Measured result	Defense
1. Instruction	KyberSlash	Secret numerator divided by the public modulus compiles to a variable-time `DIV` [@kyberslash-site]	Full keys in minutes for KyberSlash2, a few hours for KyberSlash1 -- both on the Cortex-M4 and Raspberry Pi 2 (Cortex-A7) [@kyberslash-paper]	Reciprocal multiplication; never-divided and AVX2 paths
2. Compiler	Clangover	Clang re-emits a secret-dependent branch from constant-time source [@clangover]	ML-KEM-512 key in 5-10 minutes on an i7-13700H [@clangover]	Verify the binary; verified assembly
3. Construction	Plaintext-checking oracle	Any physical pass/fail leak in FO re-encrypt-and-compare [@ravi2019][@ueno2021]	Generic key recovery against a reused key	Constant-time plus masked comparison
4. Countermeasure	Carry Your Fault	Fault in the A2B carry chain that masking itself added [@carry-fault]	Keys from arbitrary-order masked Kyber via EM fault on an STM32 [@carry-fault]	Fault detection and redundancy

Layer 1 -- the instruction: KyberSlash

Start with one line of reference C. In poly_tomsg, the routine that turns a decrypted polynomial back into message bits, the code computes t = (((t << 1) + KYBER_Q/2)/KYBER_Q) & 1; [@kyberslash-site]. It divides a secret numerator t by the public modulus KYBER_Q, which is 3329. On paper that is one arithmetic operation. On silicon it is a catastrophe.

Code is constant-time, or data-oblivious, when its execution -- the instructions retired, the memory addresses touched, and the total cycle count -- does not depend on any secret value. No secret-dependent branches, no secret-indexed memory, no variable-latency instructions on secret operands. It is the baseline defense against timing side channels, and it is a property of the running binary, not of good intentions.

The trouble is that on many processors, integer division is not constant-time. On many CPU, compiler, and flag combinations, /KYBER_Q compiles to a hardware DIV whose cycle count depends on the numerator: on an AMD Zen 2 core the division slows by a cycle once the numerator reaches 8192; on the SiFive U74 RISC-V core the timing shifts at 2048, 4096, and 8192; gcc -Os emits a DIV where gcc -O3 emits a constant-time multiplication; and on a Raspberry Pi 2, gcc -Os -- whose default ABI does not guarantee a hardware divide -- emits a call to a branchy software-division routine instead [@kyberslash-site]. Any one of these makes decapsulation time depend on the secret.

KYBER_Q is a public integer 3329, but t is secret ... the time taken by division depends on the inputs.

That quote is from the KyberSlash FAQ [@kyberslash-site], and it is the entire attack in one sentence. There was, it turns out, a second copy of the same bug: KyberSlash2 is the identical secret-dependent division in poly_compress and polyvec_compress, the compression functions called from indcpa_enc [@kyberslash-site]. Because decapsulation also runs encryption during FO re-encryption, both the decryption and the re-encryption paths leak [@pqcforum-kyberslash2]. The measured consequence, from the KyberSlash paper, is blunt: Kyber secret keys are "reliably recovered within minutes for KyberSlash2 and a few hours for KyberSlash1" on an Arm Cortex-M4 and a Raspberry Pi 2 with an Arm Cortex-A7 [@kyberslash-paper].

flowchart TD A["Secret numerator t from the decrypted polynomial"] B["Public modulus KYBER_Q, the constant 3329"] C["Source computes t divided by KYBER_Q"] D["Compiler emits a hardware DIV on many targets"] E["DIV latency depends on the operand"] F["Decapsulation time leaks bits of the secret"] G["Plaintext-checking oracle, then full key recovery"] A --> C B --> C C --> D --> E --> F --> G

The timeline matters, because it is the proof of the thesis. The reference implementation was patched in pq-crystals/kyber commit dda29cc on 1 December 2023, with the message "Updated poly_tomsg to prevent a compiler from using DIV," crediting Cryspen's Goutam Tamvada, Karthikeyan Bhargavan, and Franziskus Kiefer [@kyber-commit].The leak was found not by an attacker but by a formal-verification team. Cryspen's engineers noticed the division while building a machine-checked Rust implementation of Kyber [@cryspen]. The people proving the code correct were the ones who saw it leak. Bernstein announced it publicly as a "possibly exploitable" issue on 15 December 2023 [@pqcforum-bernstein]; Ravi and Kannwischer disclosed the compression-function copy, KyberSlash2, on 30 December 2023 [@pqcforum-kyberslash2]. This is eight months before FIPS 203 existed. The standard had a machine-checked proof and a leaking reference implementation at the same time.KyberSlash carries a CVE-class advisory but no NVD number. The record is RUSTSEC-2023-0079 against the pqc_kyber crate, rated CVSS 7.4 HIGH, with no patched versions released upstream [@rustsec].

You can see why the fix looks trivial: never divide by a public constant on a secret. Multiply by its reciprocal instead. The two compute the same value, but only one is data-oblivious.

{` const q = 3329;

// Illustrative model of hardware DIV latency: on several real cores the // cycle count creeps up as the (secret) dividend grows. Not a measurement. function divCycles(secretNumerator) { return secretNumerator >= 8192 ? 18 : 17; }

// Reciprocal multiplication: multiply by a precomputed constant, then // shift. One fixed cost, whatever the operand. function reciprocalCycles(_secretNumerator) { return 3; }

// Both routines decode the same message bit; only the timing differs. function decodeBit(t) { return (((t << 1) + (q >> 1)) / q) & 1; }

const secrets = [1200, 6000, 9000, 15000]; const divCosts = secrets.map(divCycles); const mulCosts = secrets.map(reciprocalCycles);

console.log("secret numerators :", secrets.join(", ")); console.log("DIV cycle model :", divCosts.join(", "), " (varies with the secret)"); console.log("reciprocal model :", mulCosts.join(", "), " (constant)"); console.log("decoded bits match:", secrets.map(decodeBit).join(", ")); `}

The obvious fix, then, is to delete the division and write constant-time source. So people did. It was not enough.

Layer 2 -- the compiler: Clangover

You wrote constant-time C. The compiler disagreed. This is the uncomfortable discovery behind Clangover, published by Antoon Purnal in 2024 [@clangover]. The reference implementation's poly_frommsg routine, which expands each message bit into a polynomial coefficient, was written to be branch-free by construction: no if on a secret, just arithmetic and masks. Inspect the C and it is constant-time.

Then compile it. Clang versions 15 through 18, under optimization levels -Os, -O1, and -O2 or -O3 with -fno-vectorize, recognize the branch-free idiom and "optimize" it back into a secret-dependent conditional branch in the emitted x86 assembly [@clangover]. The compiler, trying to be helpful, reintroduced exactly the leak the programmer had carefully removed. End-to-end decapsulation-timing measurements then recover the full ML-KEM-512 secret key in 5 to 10 minutes on an Intel Core i7-13700H compiled with Clang 16.0.6 [@clangover].

Key idea: Constant-time source is not constant-time binary. A proof about C, or even a careful reading of C, does not bind the machine code an optimizing compiler emits. The property you need holds of the instructions that actually run, and the compiler stands between you and them.

The reference maintainers already knew the compiler was an adversary, even if the full extent was not yet clear. Recall the wording of the KyberSlash patch: not "fix a bug" but "prevent a compiler from using DIV" [@kyber-commit].The commit message names the real opponent. The source did not contain a division instruction; it contained a division operator that the maintainers had to actively stop the compiler from turning into a DIV. The adversary was the toolchain, not the algorithm. Clangover is the general form of that fear: the toolchain can undo any source-level constant-time property you think you have.

Note: Every defense so far lived in the source language. KyberSlash was patched in source; the branch-free poly_frommsg was written in source. Clangover shows the guarantee you actually need lives one level down, in the binary -- and nothing about writing careful C forces the binary to inherit the property. This is the coverage gap that Section 6's strongest defenses exist to close.

One detail in the Clangover repository ties this layer to the next. Purnal describes his attack, in his own words, as "a plaintext-checking oracle attack a la Ravi et al. and Ueno et al." [@clangover] -- and so does the KyberSlash lineage. Both breaks call themselves the same thing, which is no coincidence: it is the tell that they are two instantiations of a single, deeper surface. Time to see it.

Layer 3 -- the construction: the plaintext-checking oracle

The armor is the wound. The re-encrypt-and-compare step that proves ML-KEM secure against active attackers is the exact code that every documented break pries open. To see why, you have to understand what the attacks are actually querying.

A plaintext-checking oracle answers one question about a decapsulation: did this ciphertext decrypt to a particular message, or not? Lattice KEMs have a small, secret-dependent decryption-failure event, so an attacker who crafts ciphertexts near that boundary and learns pass-or-fail for each one can, over many queries against a reused key, solve for the secret. The oracle need not be a protocol feature; any physical leak that separates the two cases will serve [@ravi2019][@ueno2021].

This is the surface Ravi and colleagues formalized in 2019, showing generic PC-oracle key recovery against CCA-secure lattice KEMs, and that Ueno and colleagues generalized in 2021 to the FO re-encryption step as a power and electromagnetic oracle across post-quantum schemes [@ravi2019][@ueno2021]. Both predate FIPS 203.

And now the earlier layers snap into focus: KyberSlash is this oracle instantiated at the instruction (division timing separates pass from fail), and Clangover is the same oracle instantiated at the compiler (a reintroduced branch separates pass from fail). Purnal names the lineage outright [@clangover].

flowchart TD A["Attacker crafts a ciphertext near a decryption-failure boundary"] B["Victim decapsulates with the reused secret key"] C["Re-encrypt-and-compare runs on secret-derived data"] D{"Side channel reveals pass or fail?"} E["Record one bit about the secret key"] F["Update the secret-key estimate"] G["Full secret key recovered"] A --> B --> C --> D D -->|leak observed| E --> F F -->|repeat with a new ciphertext| A F -->|enough bits gathered| G

Here is the point that has to be stated precisely, because it is the most common misreading of ML-KEM.

Note: Implicit rejection means a re-encryption mismatch returns a pseudorandom shared secret, not an error [@fips203]. There is no caller-visible reject to query, so the FO transform hands an attacker no oracle by construction. Every real oracle in this article is a side-channel leak in the re-encryption and comparison -- timing, power, electromagnetic, or fault -- never a signal the protocol emits.

So the FO transform's mathematics never failed. It is machine-checked [@fvk]. What "failed" is subtler and more interesting: the construction that earns the security proof is precisely the construction that forces secret-dependent computation to run at decapsulation time. The proof guarantees the values leak nothing. It cannot guarantee the execution leaks nothing, because guaranteeing that was never the mathematician's job -- it is the implementer's. The armor and the wound are the same lines of code.

If timing and compiler leaks feed this oracle, the natural next move is to attack a different channel entirely: mask the implementation so that power and electromagnetic measurements reveal nothing either. That worked. Until the defense became the surface.

Layer 4 -- the countermeasure: masking, and Carry Your Fault

The last layer out is the defense itself. If timing and compiler channels can be closed, the remaining physical threat is an attacker with an oscilloscope or an electromagnetic probe against a device in hand. The standard answer is masking.

Masking splits every secret into $t+1$ random shares whose combination recovers the secret, so that any $t$ probes of the circuit are statistically independent of it -- the guarantee of the Ishai-Sahai-Wagner probing model. Linear operations stay cheap per share; the expensive part in Kyber is the nonlinear Arithmetic-to-Boolean (A2B) conversion needed because the scheme mixes arithmetic modulo $q$ with bitwise operations. Masking is the primary defense against power and electromagnetic analysis [@masking-kyber].

Masking is not busywork or redundancy.Constant-time execution closes the timing channel; masking closes the power and electromagnetic channel. They defend different physics, so a device facing a physical adversary needs both. Neither subsumes the other [@masking-kyber]. First- and higher-order masked implementations of Kyber are a mature line of work [@masking-kyber]. And this is where the frontier does something remarkable: it marches one layer further and turns the countermeasure into the target.

A fault-injection attack deliberately corrupts a computation -- with a voltage or clock glitch, a laser, or an electromagnetic pulse -- and infers secrets from how the wrong result differs from the right one. It is a different threat from passive measurement: the attacker actively perturbs the device rather than only observing it [@carry-fault].

Carry Your Fault, published by Kundu and colleagues in 2024, does exactly this [@carry-fault]. The A2B conversion that masking requires is built on an adder with a carry chain. Inject a fault into that carry chain -- the very component added to enable masking -- and its data-dependent propagation leaks information about the secret. Using belief propagation over the faulted values, the attack recovers keys from Kyber masked to arbitrary order, validated with electromagnetic fault injection on an STM32 microcontroller [@carry-fault]. Read that again: no masking order defeats it, because the attack feeds on a structure that higher-order masking only makes larger.

It is not an isolated result. Deep-learning side-channel analysis has defeated a masked hardware implementation of Kyber [@ji-dubrova], and the surveys of the field confirm that the entire documented corpus of attacks on these schemes is implementation-class -- side channel and fault, not lattice [@sca-survey].

So count the layers. The instruction leaked (Layer 1). The compiler leaked (Layer 2). The construction defined the surface (Layer 3). The countermeasure for that surface became the surface (Layer 4). Four layers out from the lattice, and the mathematics has not moved a single bit. That is not luck. It is the shape of the problem -- and the shape points straight at the fix.

5. The breakthrough: constant-time or it is not secure

Step back and the four layers share one address. Every break lives in the gap between what the specification promises about values and what the machine does during execution. The response to that, the actual breakthrough, is not a new theorem. It is a change in what counts as "done."

Key idea: The armor that proves CCA security is exactly the code that leaks. So side-channel resistance cannot be an afterthought bolted onto a correct implementation -- it is a property the implementation must be built and verified to have, at the level of the binary that ships. Constant-time or it is not secure.

For decades, constant-time execution was treated as a performance-adjacent nicety, a thing careful cryptographers did by hand and hoped the compiler respected. The ML-KEM breaks retire that attitude. The discipline has three prongs: treat data-obliviousness as a hard security requirement; move the guarantee into formally verified implementations; and build tooling that checks the property instead of trusting it.

That last prong is where the KyberSlash authors made their most durable contribution. Ordinary constant-time checkers had a blind spot. The lineage runs from Adam Langley's ctgrind in 2010 [@ctgrind], which repurposed Valgrind's uninitialized-memory tracking to flag secret-dependent branches, through TIMECOP's automated sweep of the SUPERCOP benchmark suite [@timecop], to dudect's black-box statistical timing test [@dudect] and the ct-verif formal verifier [@ctverif].

But as the TIMECOP authors themselves note, Valgrind "cannot spot cases where variable-time code is caused by variable-time CPU instructions" [@timecop] -- which is precisely what a DIV is. So the KyberSlash team patched Valgrind to flag variable-time instructions operating on secret data, and ran it across more than 1000 implementations in SUPERCOP [@kyberslash-paper]. The tool now catches the exact class of bug that produced it.

Why was the burden on implementers in the first place? Because the standard never claimed otherwise. As Cryspen puts it plainly:

The goal of the NIST specification is clarity and succinctness, not performance or even security concerns like side-channel resistance. -- Cryspen

Side-channel resistance is the implementer's responsibility [@cryspen]. The breakthrough is not pretending otherwise -- it is making that responsibility mechanically checkable, so a leak is caught in continuous integration instead of in a paper two years later. And checking is something you can do yourself. The dudect method needs no source access at all: measure two populations of decapsulation timings, one for a fixed input and one for random inputs, and apply Welch's t-test. A large t-statistic means the timing depends on the data.

{` // dudect-style leak test: compare two timing populations with Welch's t. // The dudect threshold: |t| above 10 is strong evidence of a timing leak. // A deterministic generator keeps the demo reproducible. let seed = 424242; function rand() { seed = (1103515245 * seed + 12345) & 0x7fffffff; return seed / 0x7fffffff; }

function welchT(a, b) { const mean = xs => xs.reduce((s, x) => s + x, 0) / xs.length; const vary = (xs, m) => xs.reduce((s, x) => s + (x - m) * (x - m), 0) / (xs.length - 1); const ma = mean(a), mb = mean(b); const va = vary(a, ma), vb = vary(b, mb); return (ma - mb) / Math.sqrt(va / a.length + vb / b.length); }

function measure(n, leaks) { const fixedClass = [], randomClass = []; for (let i = 0; i < n; i++) { const noise = rand() * 2; // A leaking build spends extra cycles on the fixed-input class. fixedClass.push(100 + noise + (leaks ? 6 : 0)); randomClass.push(100 + rand() * 2); } return welchT(fixedClass, randomClass); }

console.log("leaking build t =", measure(4000, true).toFixed(1), " -> leak, |t| well above 10"); console.log("constant-time build t =", measure(4000, false).toFixed(1), " -> no leak"); `}

Discipline is a goal; a shipped binary is a fact. So how do you actually build an ML-KEM that does not leak, today?

6. State of the art: how a correct ML-KEM is built today

Here is the good news the catalog has earned: every one of those breaks has a known, shipping answer, and not one of the answers required touching the mathematics. The state of the art is not a single silver bullet. It is a stack of defensive layers, and it is useful to read them from nearest the math outward.

Division-free constant-time source. The innermost fix is the one KyberSlash demanded: never divide by a public constant on a secret operand. Replace /KYBER_Q with a fixed-point reciprocal multiplication -- multiply by a precomputed $\lceil 2^k / q \rceil$ and shift right by $k$ -- which is constant-cycle and frequently faster than the DIV it replaces. Replace secret-dependent branches with bit-masks and conditional moves. This is now the default in maintained libraries: the Go standard library's crypto/mlkem [@go-mlkem], Google's BoringSSL, filippo.io/mlkem768, and the PQClean AVX2 paths all ship division-free constant-time ML-KEM [@kyberslash-site].The vectorized AVX2 and NEON code paths never issued a scalar DIV on secret data in the first place, so a KyberSlash-immune implementation existed in parallel the entire time [@kyberslash-site]. The bug was in the portable reference, not in the fast paths people actually deployed on servers.

Formally verified implementations. Constant-time source is necessary but, as Clangover proved, not sufficient. The stronger layer moves the guarantee into the binary. There are two mature routes. The first is verified assembly: the formosa-crypto libjade project, built with Jasmin and EasyCrypt, ships assembly "connected through computer-verified proofs to a cryptographic security notion," including constant-time proven of the emitted code itself [@libjade]. That closes the exact gap Clangover opened -- there is no optimizing compiler left to betray you -- though its latest release supports only the AMD64 architecture [@libjade].

The second route is verified Rust: Cryspen's libcrux uses the hax toolchain and F* to machine-check correctness, memory safety, and source-level secret-independence, reusing verified code from HACL* [@libcrux][@haclstar].

There is an important honesty in the libcrux documentation, and it is on-thesis. The repository states that "executables compiled from the code in this repository are not verified to be side-channel resistant, although we try to enforce that the source code is secret-independent" [@libcrux]. In other words, libcrux verifies the source, not yet the binary, and it is still pre-release.The verified-Rust effort that produced libcrux is the same effort that surfaced KyberSlash [@cryspen]. The tooling built to prove the code correct is what found the leak first -- the strongest possible argument for verification as a discipline.

Hardware timing guarantees. As a backstop beneath the software, modern processors offer modes that guarantee operand-independent timing for a listed subset of instructions: Arm's Data-Independent Timing (DIT) register [@arm-dit] and Intel's Data Operand Independent Timing Mode (DOITM) [@intel-doitm]. These push part of the constant-time burden from the programmer to the silicon.Both are opt-in: the operating system or program must set the register or mode before the guarantee applies, and only the listed instructions are covered. Section 7 returns to their limits.

Binary verification tooling. Wrapping the whole stack is the checking discipline from Section 5: dudect for black-box statistical timing tests [@dudect], TIMECOP for automated SUPERCOP-wide sweeps [@timecop], ct-verif for formal constant-time verification [@ctverif], and the KyberSlash Valgrind patch for variable-time instructions on secret data [@kyberslash-paper]. Run them against the artifact you ship.

flowchart TD M["Unbroken Module-LWE mathematics"] subgraph timing["Closes the timing channel"] T1["Division-free constant-time source"] T2["Verified assembly, proven at the binary"] T3["Hardware DIT and DOITM backstop"] end subgraph power["Closes the power and EM channel"] P1["Masking with t+1 shares"] end subgraph fault["Closes the fault channel"] FA["Redundancy and fault detection"] end M --> timing M --> power M --> fault

Note: Verify the binary you ship, not the source you wrote. KyberSlash lived in a source-level division operator; Clangover lived in compiler output that no source review would catch. Every layer here is ultimately about making a guarantee that holds of the instructions that actually execute [@kyberslash-paper].

Notice what is absent from the entire stack: any change to Module-LWE, any new hardness assumption, any adjustment to the parameter sets. The mathematics was never the problem, so it is not part of the fix. But these layers are not free, and they do not all defend the same thing. Choosing among them is its own problem.

7. Competing approaches: what each defense actually buys

There is no single winner here, and pretending otherwise is how deployments end up with the wrong protection. Each layer answers a different threat model at a different cost with a different strength of guarantee. Lay them side by side and no column is all-yes.

Defense	Channel closed	Guarantee	Cost	Platform scope
Constant-time source	Timing	Self-asserted, source only	Near zero	Portable
Verified assembly (libjade) [@libjade]	Timing	Proven at the binary	Low	AMD64 only in latest release
Verified Rust (libcrux) [@libcrux]	Timing (source)	Machine-checked source, binary not yet claimed	Low	Portable, pre-release
Masking [@masking-kyber]	Power and EM	Probing model of order $t$	Quadratic, $O(t^2)$	Portable
Fault countermeasures [@carry-fault]	Fault	Detection and redundancy	Roughly 2x or more	Portable
Hardware DIT / DOITM [@arm-dit][@intel-doitm]	Timing	Operand-independent for listed instructions	Near zero	Specific microarchitectures

Read across the rows and the trade-offs are stark. Constant-time source costs almost nothing but certifies nothing about the binary -- Clangover is the proof. Verified assembly gives the strongest timing guarantee anyone can offer, proven of the shipped code, but libjade's latest release is AMD64-only [@libjade], and most ML-KEM in the world runs on Arm phones and microcontrollers. Verified Rust is maintainable and machine-checks correctness and safety, but its authors do not yet claim binary-level constant-time [@libcrux].

The physical-defense rows trade differently. Masking is the only layer that stops power and electromagnetic differential analysis, but it costs quadratically in the protection order [@masking-kyber] and, as Carry Your Fault showed, does not stop faults at any order [@carry-fault]. Fault countermeasures add redundancy and roughly double the work. Hardware DIT and DOITM are nearly free but cover only listed instructions on specific microarchitectures [@arm-dit][@intel-doitm].

Which explains why different deployments make opposite choices, and are both right to.

A server or browser attacker cannot put an oscilloscope on your power rail or fire an electromagnetic pulse at your CPU. For that threat model the whole risk is timing, so a division-free constant-time implementation plus binary scanning is sufficient, and general-purpose stacks like the Go standard library and BoringSSL skip masking entirely [@kyberslash-site]. A smartcard, hardware security module, or embedded device sitting in an adversary's hand faces power, electromagnetic, and fault attacks directly, so it must add masking and fault countermeasures on top [@masking-kyber][@carry-fault]. Same primitive, same proof, opposite implementations -- because the threat models are opposite.

The deepest tension in the table is between the two things you most want. Formal verification gives the strongest guarantee but is platform-scoped: the proof for x86-64 says nothing about the Arm build. Masking is essential against physical adversaries but is expensive and, alone, incomplete. No single implementation today is verified-constant-time at the binary, masked to high order, fault-resistant, and portable all at once. You assemble the stack from partial guarantees.

Stack them all and you still hit walls -- and some of those walls are provable. So the honest next question is: what can side channels not let you close?

8. Theoretical limits: what side channels can and cannot close

The limits in this story are strikingly asymmetric, and not one of them is a limit on the lattice.

Timing is the easy one. Secret-independent execution is achievable at essentially zero asymptotic cost, because ML-KEM's compression divide was never necessary in the first place -- reciprocal multiplication is just as fast and constant-cycle. The "lower bound" on timing safety is therefore not a performance penalty but a matter of discipline plus verification. You can close the timing channel provably and for free.

Masking is where the hard floors appear. Resisting an adversary who can probe $t$ intermediate values requires at least $t+1$ shares -- the Ishai-Sahai-Wagner probing-model bound -- and Kyber's nonlinear steps, the Arithmetic-to-Boolean conversions, scale as $\Theta(t^2)$ [@masking-kyber]. High-order masking is genuinely expensive, and no clever engineering buys it cheaply. Then comes the sharpest result of all, the one with the flavor of an impossibility theorem.

Note: Carry Your Fault recovers keys from Kyber masked to arbitrary order [@carry-fault]. There is no protection order you can reach that also buys fault safety, because the attack feeds on the carry chain that masking itself introduces. Masking and fault resistance do not compose for free -- you must add fault countermeasures as a separate layer, and no amount of the first substitutes for the second.

Step back and the shape of the remaining danger becomes clear, and it is not what people expect.

Key idea: The gap is coverage, not lattice hardness -- and the mathematics was never the problem. The unsolved risks are all gaps in what a guarantee covers: source versus binary (Clangover [@clangover]), platform versus platform (libjade proves AMD64, not your Arm build [@libjade]; DIT and DOITM cover only listed instructions), and channel versus channel (timing is not power is not fault). None of these gaps touches Module-LWE.

That last clause deserves the honesty the series is built on. The series thesis is that the mathematics almost never causes the break, and "almost never" is doing real work: in other episodes, deployment defects were sometimes structural in a deeper way. For ML-KEM, as of publication, the lattice has simply not been reached -- and the two times anyone reached for it are themselves the strongest evidence.

In April 2024, Yilei Chen circulated a claimed polynomial-time quantum algorithm for lattice problems. Within days, informal peer review found a flaw: Hongxun Wu and, independently, Thomas Vidick identified a bug in Step 9, and Chen updated the paper to state that the claim does not hold [@chen2024][@quantuminsider]. The author withdrew it himself. In May 2026, Ming-Xing Luo posted a preprint claiming a polynomial-time quantum attack on Module-LWE and ML-KEM [@luo2026]. It has not been peer-reviewed and the author has not withdrawn it -- but named experts identified fatal flaws: Daniel Apon showed the attack's output is provably independent of the secret key, and Thomas Espitau found its central reduction dimensionally wrong and a supporting result fabricated [@postquantum-luo]. It is a reach that did not land -- and a weaker one than Chen's, because Chen retracted while Luo's claim has simply been refuted. ML-KEM is not considered broken.

The genuine lattice question -- whether Module-LWE itself has an efficient attack -- is the subject of the companion article, "How ML-KEM and ML-DSA Would Break: Module-LWE, Lattice Reduction, and the Correlated-Failure Problem." As of publication it remains open, and open is not the same as broken.

So the frontier is parked at the countermeasure layer. Not because the mathematics is the next thing to fall, but because closing the last coverage gaps -- binary, platform, channel -- is genuinely unsolved. That is exactly where the research is.

9. Open problems: where the frontier is now

The unsolved problems in ML-KEM security are, almost without exception, engineering problems. That is itself the thesis, restated as a research agenda.

One artifact, all three guarantees. The clearest open problem is a single machine-checked implementation that is provably constant-time and masked and fault-resistant, portably, at production scale. Today you assemble those from different tools -- a verified-assembly timing proof here, a masked gadget there, a fault countermeasure bolted on -- and trust that the composition holds. Carry Your Fault is the standing warning that it may not: the pieces can each be correct and still leak at their seams [@carry-fault].

The compiler as an unquantified adversary. Clangover is a specific bug in specific Clang versions, but the phenomenon is general [@clangover]. There is no widely deployed guarantee that an optimizing compiler preserves a source-level constant-time property through arbitrary transformations. "Constant-time preservation" as a compiler discipline is an active research direction, not a solved feature you can switch on.

Portable verification. The strongest proofs are architecture-bound. Verified assembly covers AMD64; hardware timing modes cover listed instructions on particular cores. Yet the most-deployed ML-KEM in the world runs on Arm phones and Cortex-M microcontrollers -- exactly the targets KyberSlash and Carry Your Fault attacked on real silicon [@carry-fault]. Closing the platform gap between where the proofs are and where the code runs is unsolved.

Hardware accelerators. As ML-KEM moves into dedicated hardware, the side-channel surface moves with it. A masked hardware implementation of Kyber has already fallen to deep-learning side-channel analysis [@ji-dubrova], and the surveys treat hardware side channels as an open, active area rather than a closed one [@sca-survey].

Migration and captured traffic. The most realistic exposure needs no wild exploit at all.

An adversary records encrypted traffic today and stores it, betting on decrypting it in the future once cryptanalysis or a quantum computer catches up. Because captured ciphertext cannot be un-sent, any recording made now is a standing liability -- which is the entire motivation for migrating to post-quantum key exchange before a break exists [@cryspen]. Here is the sharp version of why implementation leaks matter even with the mathematics intact. Traffic protected by a hybrid ML-KEM handshake is being recorded now. If the implementation carrying that handshake leaks the key through a side channel, the recorded session is exposed -- no future quantum computer required. A live timing or fault leak in a deployed TLS or SSH path is the realistic threat, and it sits entirely in execution, not in the lattice [@cryspen].

The lattice itself. The one open problem that is mathematical -- whether Module-LWE has an efficient attack -- is deliberately not this article's.That question is the whole subject of the companion piece, "How ML-KEM and ML-DSA Would Break," which takes on how it breaks now, in the implementation, versus how it would break later, in the mathematics. As of publication it is open, and it is handed to the sibling.

Research aside, you have to ship something on Monday. Here is the decision that survives all of the above.

10. What to actually do

The one sentence: pick an ML-KEM implementation that never divided on a secret or is formally verified, and verify the binary you actually ship. Everything else is refinement by threat model.

General-purpose software, no local physical adversary. If you run on servers, browsers, or backends, an attacker cannot probe your power rail, so timing is your whole threat. Use a division-free constant-time implementation from a maintained source -- the Go standard library's crypto/mlkem [@go-mlkem], Google's BoringSSL, filippo.io/mlkem768, or an AVX2/NEON path [@kyberslash-site] -- and scan the binary with a patched Valgrind or TIMECOP [@timecop] and dudect [@dudect] in continuous integration. You do not need masking or fault countermeasures for this threat model.

Maximum timing assurance on x86-64. If you want the strongest guarantee available, use verified assembly: libjade's constant-time property is proven of the emitted code, which is the only thing that closes the Clangover gap outright [@libjade]. Remember its latest release is AMD64-only.

Maintainable high-assurance Rust. libcrux gives machine-checked correctness and source-level secret-independence [@libcrux], with the caveat that it is pre-release and does not yet claim binary-level constant-time.

Embedded, smartcard, or HSM with a physical adversary. Stack the layers: division-free constant-time and masking (sized to your threat, remembering the quadratic cost) and fault detection (because arbitrary-order masking still falls to Carry Your Fault [@carry-fault]) and hardware DIT or DOITM where available.

The library map, at a glance:

Status	Implementation	Why
Known-good	Go `crypto/mlkem` [@go-mlkem]	Constant-time, upstreamed from `filippo.io/mlkem768`, never divided
Known-good	BoringSSL, `filippo.io/mlkem768`, PQClean AVX2 [@kyberslash-site]	Never issued a secret-operand `DIV`
Known-good	formosa-crypto libjade [@libjade]	Verified-assembly constant-time on AMD64
Known-good, pre-release	libcrux [@libcrux]	Verified Rust, source secret-independent
Patched reference	`pq-crystals/kyber` portable C [@kyber-commit]	Fixed December 2023; downstream forks may still lag
Known-bad	`pqc_kyber` Rust crate [@rustsec]	RUSTSEC-2023-0079, no patched versions; migrate off it

Note: The Rust pqc_kyber crate carries RUSTSEC-2023-0079 for KyberSlash, rated CVSS 7.4 HIGH, and upstream released no patched versions [@rustsec]. It remains installable today. If it is anywhere in your dependency tree, migrate to the ml-kem crate or the maintained safe_pqc_kyber fork [@rustsec]. A deprecated-but-still-live dependency is the whole series thesis in miniature: the mathematics is fine, and the artifact you pulled from the registry is not.

Run `cargo audit` in your project: it flags RUSTSEC-2023-0079 when `pqc_kyber` appears anywhere in the graph [@rustsec]. To find what pulls it in, run `cargo tree -i pqc_kyber`, then swap in the `ml-kem` crate or the `safe_pqc_kyber` fork and re-run the audit until it comes back clean.

Every pitfall in this article maps to a named incident and a concrete fix.

Pitfall	Incident it recreates	Fix
Dividing a secret by `q` in compression or decode	KyberSlash [@kyberslash-paper]	Reciprocal multiply; use a never-divided or AVX2 path; scan with patched Valgrind
Trusting constant-time C through the compiler	Clangover [@clangover]	Verify the binary; prefer verified assembly
Masking without fault countermeasures	Carry Your Fault [@carry-fault]	Add fault detection and redundancy as a separate layer
Depending on an unpatched crate	RUSTSEC-2023-0079 [@rustsec]	Migrate to `ml-kem` or `safe_pqc_kyber`

Finally, deploy hybrid.The hybrid group X25519MLKEM768 runs a classical elliptic-curve exchange and ML-KEM together. By construction the session stays secure as long as either component does [@tls-hybrid], so it hedges a future lattice break and a present implementation bug in the other component at the same time. A hybrid handshake is the one move that protects you against both the break that has not happened to the math and the break that already happened to the code.

Note: Ship a division-free or formally verified ML-KEM, verify the binary you actually deploy, add masking and fault countermeasures only when a physical adversary can touch the device, and deploy hybrid so you stay secure if either half holds.

Do that and you have closed every gap anyone has actually walked through. The questions that remain are the ones readers always ask.

11. Frequently asked questions

A few misconceptions come up every time this material is discussed. Here they are, answered against the primary sources.

No. As of publication its Module-LWE mathematics is intact and its IND-CCA2 security has been machine-checked [@fips203][@fvk]. Every documented break is an implementation or side-channel attack against specific code -- a division instruction, a compiler optimization, a fault in a countermeasure -- not a weakness in the primitive itself. No. Two prominent claims reached for the lattice mathematics and both failed review. Yilei Chen's 2024 quantum algorithm was withdrawn after Hongxun Wu and Thomas Vidick found a bug in Step 9 [@chen2024]. A 2026 preprint by Ming-Xing Luo was refuted by named experts, who showed the attack's output is provably independent of the secret key [@luo2026][@postquantum-luo]. No quantum machine has broken ML-KEM, and none is known to exist that could. It has a CVE-class advisory but no NVD number. The record is RUSTSEC-2023-0079 against the `pqc_kyber` crate, rated CVSS 7.4 HIGH [@rustsec]. The disclosure and reference patches were December 2023 [@kyber-commit], and the full paper appeared at IACR TCHES in 2025 [@kyberslash-paper]. Not by construction. A re-encryption mismatch returns a pseudorandom shared secret, not an error, so there is no caller-visible rejection to query [@fips203]. The oracle in every real attack is a side-channel leak in the re-encryption and comparison -- timing, power, electromagnetic, or fault -- never a signal the protocol emits. There is no documented in-the-wild exploitation of a production ML-KEM deployment as of publication. The breaks are vulnerable code shipping in libraries, CVE-class advisories, and researcher proof-of-concept key recovery on real hardware [@kyberslash-paper]. No. Masking stops power and electromagnetic analysis but not faults: Carry Your Fault recovers keys from masking of arbitrary order [@carry-fault], and masked hardware has fallen to deep-learning side-channel analysis. A device facing a physical adversary needs constant-time execution and masking and fault countermeasures together. Yes, with care. Pick an implementation that never divided on a secret or is formally verified, verify the binary you ship, add masking and fault countermeasures only for physical-adversary threat models, and deploy a hybrid group such as `X25519MLKEM768` so you stay secure if either half holds [@tls-hybrid].

Count the layers one last time. The instruction leaked; the compiler leaked; the construction defined the surface; the countermeasure became the surface. Four steps outward from the lattice, and the Module-LWE mathematics never moved -- its security proof machine-checked, its two attempted quantum breaks both failed under expert scrutiny (Chen withdrew his claim; Luo's was refuted by named experts) [@fvk][@chen2024][@postquantum-luo]. The mathematics almost never caused the break. The deployment did: the reference division, the compiler's optimization, the unpatched crate, the fault through the mask. The frontier is still marching outward, and the day it finally reaches the lattice is the subject of the companion article, "How ML-KEM and ML-DSA Would Break." Until then, the same law that spared the AES cipher for two decades while its implementations leaked keys to a stopwatch now governs the first post-quantum KEM.

The machine leaked while the math held. That is not a footnote to ML-KEM's security -- as of publication, it is the entire story of how it breaks.