Parag Mali - tag: side-channel-attacks

Never Decrypted: When Math Is Too Slow, Silicon Keeps the Secret -- Confidential Computing and GPU TEEs

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

Trusted Execution Environments keep a secret the opposite way to the first four parts of this series. Instead of making the computation unreadable with mathematics, they decrypt it *inside* a hardware boundary that the operating system, the hypervisor, the cloud operator, and a person with a screwdriver are all locked out of -- and they prove which chip you are talking to with remote attestation.

That is what makes confidential AI real in 2026: encrypted model plus encrypted data, attested inference on an NVIDIA H100 at under nine percent overhead, where fully homomorphic encryption is orders of magnitude too slow. But the trust did not vanish; it moved -- to a vendor, a die, and an unprovable "no side channel" assumption that a fifty-dollar memory interposer broke in 2025. The silicon and math anchors are complements, not rivals: choose per workload, or go hybrid.

1. Run the Model in a Cloud That Cannot Read It

A hospital wants to run a proprietary 70-billion-parameter model on patient scans it is legally forbidden to expose. The datacenter belongs to a company neither the hospital nor the model's maker will trust with the plaintext. The model's owner will not ship the weights in the clear. Fully homomorphic encryption -- the mathematics of Part 1, which computes without ever decrypting -- is, as that part measured, three to six orders of magnitude too slow to answer in real time.

And yet, in 2026, this runs at under ten percent overhead, because the weights and the scans are decrypted only inside a GPU that the cloud operator, the hypervisor, and a technician with a screwdriver are all locked out of [@zhu-hopper-benchmark-2024] [@nvidia-h100-cc-ga-2024].

Stop and notice how strange that is. A machine is computing on a model and data its own owner may not read -- at GPU speed. For four installments, this series asked one question: how do you compute on data the machine's owner cannot see? Every previous answer was mathematical. Fully homomorphic encryption evaluates a circuit on ciphertext. Zero-knowledge proofs convince without revealing. Secure multi-party computation splits a secret so no single party holds it. Private information retrieval reads a row without disclosing which row. All four buy confidentiality with a hardness assumption and, often, orders of magnitude of overhead.

This capstone follows the field's other answer, and it is almost rude in its simplicity: do not make the computation unreadable at all. Make the hardware itself refuse to reveal it to anyone but an authorized party you can cryptographically identify.

The protection of data *in use* -- during computation -- in a hardware-based, attested Trusted Execution Environment, against an adversary that explicitly includes privileged system software (the operating system, the hypervisor, the firmware) and the owner of the physical machine. It is the third leg of a stool whose other two legs, encryption at rest and encryption in transit, have existed for decades [@ccc-technical-analysis-v1-3].

Encryption at rest protects the disk. Encryption in transit protects the wire. Neither helps the instant the processor has to compute, because a CPU or GPU operates on plaintext -- values must be decrypted into registers and memory to be added, multiplied, or matrix-multiplied. That plaintext sits in DRAM, where the machine's owner can read it: a cloud operator, a compromised hypervisor, a malicious insider, or an attacker on the memory bus. That gap -- data in use -- is the entire reason this field exists.

A hardware-enforced environment that keeps the code and data running inside it *confidential and integrity-protected while executing*, even from privileged software and the physical machine owner. A TEE does not hide the computation the way homomorphic encryption does; it decrypts the data inside a boundary and relies on the silicon to refuse to leak it.

Here is the thesis of this final part, stated as a claim you should doubt until it is earned: the first four parts keep the secret with mathematics; a TEE keeps it with hardware plus attestation, trading a cryptographic trust model for a silicon one. Raluca Ada Popa named these two options exactly -- confidential computing or cryptographic computing -- and the honest version of the contrast is not "math versus no math," because a TEE is saturated with cryptography (AES memory encryption, digital-signature attestation). The difference is where trust is anchored [@popa-cc-vs-cryptographic-2024].

Key idea: A TEE moves the secret from a mathematical assumption to a silicon one -- and remote attestation is what makes that silicon trust verifiable instead of merely assumed. Read the entire field through one question: if this breaks, who or what did you have to trust? For the mathematics of Parts 1 to 4, the answer is a hardness assumption. For a TEE, the answer is a vendor, a die, and the assumption that no one has exploited a side channel.

That lens is the spine of everything that follows. Every mechanism in the story -- memory encryption, process enclaves, confidential VMs, GPU confidential computing -- exists to keep your data and model confidential from the machine's owner because you trust the chip and can prove which chip you are talking to. The rest of the article earns that generation by generation, and the conclusion sets it beside the math model and crowns no winner.

Note: Carry three things from the earlier parts into this one. First, that "compute on data the owner cannot read" is a real, recurring need, not a thought experiment. Second, that the mathematical schemes buy confidentiality with a hardness assumption and pay in overhead -- FHE most of all. Third, that a proof of correct computation (Part 2's zero-knowledge proofs) is a close cousin of what a TEE calls attestation. Those threads all reconverge here.

So if the answer is not mathematics, what is it -- and where, exactly, did the trust go? To answer that, we have to go back to a heretical question someone asked in the year 2000.

2. Trust Only the Chip

In 2000, most security architecture rested on a comfortable assumption: the operating system is on your side. Antivirus ran as a privileged process. Disk encryption trusted the kernel with the key. The threat was other users, or malware the OS had not yet caught. Then David Lie, Mark Horowitz, and their collaborators at Stanford and SRI asked a question that sounded almost paranoid: what if the operating system itself is the enemy? What if the person who owns the machine is exactly who you are hiding from?

Their answer, presented at ASPLOS 2000, was XOM -- eXecute-Only Memory. XOM declared the CPU package the sole trust boundary and treated all off-chip memory and every bus as hostile territory. Code and data lived encrypted in DRAM and were decrypted only inside the processor; the operating system was modeled explicitly as the adversary [@xom-asplos-2000]. This is the intellectual birth of the silicon trust anchor. Everything in this article is a descendant of that one move: shrink the circle of trust until it contains nothing but the chip.

The component a system trusts *by assumption*, because nothing else vouches for it -- the place where the regress of "but who verifies the verifier?" finally stops. For a TEE, the trust anchor is a key placed inside the silicon by the manufacturer. The remote-attestation standard RFC 9334 names this exactly: a verifier trusts "a manufacturer or the manufacturer's hardware" by storing the endorser's key as a trust anchor [@rfc-9334].

Three years later, G. Edward Suh, Srinivas Devadas, and colleagues at MIT built the design that every later TEE quietly inherits. AEGIS, presented at ICS 2003, was a single-chip secure processor that added the rigor XOM had only sketched. It gave tamper-evident execution by verifying off-chip memory with Merkle-style hash trees, private tamper-resistant execution through memory encryption, anti-replay freshness, and a secret rooted in a Physical Unclonable Function that even the manufacturer could not clone -- all while tolerating an untrusted operating system [@aegis-ics-2003].

Pay attention to that word freshness, because it seeds the irony that runs the length of this article. AEGIS insisted that memory protection needs three properties, not one: confidentiality (an attacker cannot read it), integrity (an attacker cannot silently alter it), and freshness (an attacker cannot replay a stale-but-valid value). Two decades later, the commercial TEEs that conquered the cloud would keep the first and quietly drop the third for speed -- and in 2025, a fifty-dollar device would pry open the exact gap AEGIS had closed in 2003.

AEGIS paid a real, quantifiable price for freshness: a hash or integrity tree costs $O(\log N)$ hash verifications on every protected memory access, where $N$ scales with the size of the protected region. That logarithmic tax on every load and store is precisely the overhead later server TEEs refused to pay at whole-VM scale -- the design decision that made them fast and made them breakable.

timeline title The silicon trust anchor moves outward, 2000 to 2025 2000 : XOM, the chip is the only trust boundary 2003 : AEGIS, memory encryption plus integrity and freshness 2004 : ARM TrustZone secure world : Direct Anonymous Attestation in the TPM 2013 : Intel SGX process enclaves plus remote attestation 2016 : AMD SEV, encrypt the whole VM 2020 : AMD SEV-SNP adds integrity and VCEK attestation 2021 : Intel TDX trust domains 2023 : RFC 9334 standardizes attestation : NVIDIA H100 GPU CC preview 2024 : H100 GPU CC general availability, confidential AI ships 2025 : Battering RAM, WireTap, TEE.Fail break attestation physically

AEGIS and XOM proved the model sound -- and, commercially, a dead letter in its original form. Both required new, non-commodity silicon; both imposed that logarithmic integrity-tree overhead on general workloads; and, most damning, neither shipped a usable software model or a way for a remote party to check that a genuine secure processor was running the expected code. They were a correct architecture with no product [@aegis-retrospective]. The chip-only boundary was right, but it had to reach mass-market silicon, with a workable programming model and a way to prove itself across the internet.

The last of those requirements was quietly being invented in parallel. In 2003 and 2004, the Trusted Computing Group standardized measured boot -- hashing each stage of the boot process into a tamper-resistant TPM register, so a machine could later attest "these are the exact bits that booted" [@tcg-tpm-main-1-2].

And in 2004, Ernie Brickell, Jan Camenisch, and Liqun Chen published Direct Anonymous Attestation, letting a TPM prove it was genuine to a remote verifier without revealing which TPM -- a zero-knowledge-style protocol adopted into TPM 1.2 [@daa-eprint-2004] [@daa-ibm-listing]. That is the seed of remote attestation: proving which code is running to someone who cannot see your datacenter.

Direct Anonymous Attestation put a zero-knowledge proof inside every compliant TPM two decades ago. The companion article in this series on DAA traces that lineage in full; the point to hold here is that "prove which chip and which code, without over-revealing" is old, and it is the exact primitive a TEE needs to convert local isolation into remote trust.

The same year measured boot and DAA were maturing, ARM shipped the first hardware isolation that would reach billions of devices [@genode-trustzone]. It answered "trust only the chip" for a phone. It would turn out to be the wrong shape for a cloud -- which is where the anchor has to move next.

3. Dual Worlds, Process Enclaves, and the First Cracks

The model shipped twice, in two very different shapes, and both started to crack.

ARM's TrustZone, introduced around 2003 to 2004, split the system-on-chip into two worlds -- a Secure World and a Normal World -- separated by a single processor-state bit propagated across the bus, so every memory and peripheral access is tagged secure or non-secure. One privileged Secure World, a small trusted OS and its apps, runs beside the rich Normal World, with a Secure Monitor Call the only gate [@genode-trustzone]. It was the first hardware isolation to ship in commodity silicon at scale, and it still guards the keys, biometrics, and payment secrets in billions of phones.

But a phone has one owner. A cloud has thousands of mutually distrusting tenants, and TrustZone offers exactly one coarse Secure World, owned by the platform operator [@trustzone-survey-2019]. You cannot hand each cloud customer an environment the provider itself cannot read, because the provider owns that single Secure World and holds its keys. There is no per-tenant confidential VM, and originally no per-tenant memory encryption at all -- isolation came from address-space partitioning, not an encryption engine.

ARM later admitted the gap, adding a separate confidential-VM world in its Confidential Compute Architecture to give each tenant an isolated domain [@sok-tz-cca-2024]. TrustZone was the right model for a device and the wrong one for a cloud.

Intel's SGX, defined in two companion papers at HASP 2013, answered with the opposite granularity: not one big world but many tiny ones.

A per-process, hardware-encrypted region of memory whose contents are protected from the operating system, the hypervisor, and the BIOS. Code and data inside an SGX enclave are decrypted only on-die; an enclave can be *remotely attested* (it can prove to a third party which code it is running) and can *seal* secrets to a CPU-derived key for storage. The trust base is minimal: your enclave and the CPU, and explicitly not the operating system.

SGX made "run a piece of code the OS cannot read" real at mass-market scale, and it shipped the first production remote attestation of application-enclave code, originally using EPID group signatures [@sgx-hasp-2013]. For one kind of workload -- a small, well-defined secret kernel -- it was exactly right. Signal's contact-discovery service, examined in this series' secure-multiparty-computation installment, still runs inside SGX enclaves [@signal-cdsi]. It is the natural bridge between the two trust models: a reminder that a TEE is often the practical way to deploy a cryptographic protocol.

Then the cracks. The first was a performance cliff. On client parts, the Enclave Page Cache was reserved at 128 MB with only about 90 to 96 MB usable; exceed it and SGX pages enclave memory out to normal RAM with encryption and integrity checks, at a 5 to 100 times slowdown once the working set spills over [@vault-asplos-2018]. The second was ergonomic: you had to refactor an application into trusted and untrusted halves, a punishing model compared with "run my existing program, but private."

The third crack was the one that mattered, and it kept widening. Starting in 2018, a stacking parade of attacks showed that both an enclave's contents and its attestation root were extractable.

An attack that recovers secrets not by breaking the cryptography but by observing a physical or microarchitectural byproduct of the computation -- timing, cache state, speculative execution, power, or the electrical signals on a memory bus. Two sub-classes recur throughout this article and must be kept distinct: *microarchitectural* side channels (speculative-execution and cache attacks such as Foreshadow, SgxPectre, and AEPIC) that need only code on the machine, and *physical* side channels (memory-bus interposers such as the 2025 attacks) that need a device between the chip and its DRAM.

Foreshadow, in 2018, used the L1 Terminal Fault speculative-execution flaw to transiently read SGX enclave memory out of the L1 cache -- including, critically, the machine's private attestation key [@foreshadow-l1tf]. SgxPectre brought Spectre-style speculative gadgets inside the enclave to leak its secrets [@sgxpectre-2018].

Then the attacks reached the root. SGAxe, in 2020, extracted the machine's SGX attestation key from the architectural enclaves, letting an attacker forge quotes indistinguishable from genuine ones and impersonate any SGX machine to a verifier [@sgaxe-2020]. AEPIC Leak, in 2022, was the first architectural (non-speculative) x86 data leak: an uninitialized read of APIC MMIO registers dumped stale physical-memory contents -- including enclave secrets -- bypassing every speculative-execution mitigation [@aepic-leak-2022].

Foreshadow demonstrated how speculative execution can be exploited for reading the contents of SGX-protected memory as well as extracting the machine's private attestation key.

That last clause is the whole game. Reading one enclave's data is a local break. Extracting the attestation key is a systemic one: it lets you forge the proof that any enclave is genuine. Hold that distinction; it returns in 2025 with a screwdriver instead of a speculative gadget.

Note: A TEE does not make the computation mathematically unreadable the way FHE does. It decrypts inside a boundary and depends on the chip to refuse to reveal it. The secret did not become unreadable; the trust moved -- from a hardness assumption to "trust this silicon, and prove which silicon." Once you feel that click, every remaining section is just a question of where the anchor moves next, and where it can be pried loose.

Two forces pushed the industry off the process-enclave model. The first was engineering cost: rewriting a large application into enclave-shaped trusted and untrusted halves, and living inside a tight encrypted page cache, was too expensive for general workloads. The second was operational: enterprises wanted to lift an *existing* virtual machine -- operating system, drivers, application, unchanged -- into a confidential environment for compliance, without touching the code. Process enclaves could not offer that. Whole-VM confidential computing could, and that is where the anchor went next.

If a process enclave is too small, too hard to port, and its attestation root is extractable, where does the anchor move? Outward again -- this time around the entire virtual machine.

4. The Anchor Moves Outward, Generation by Generation

Line up the five generations and one motion becomes visible: the trust anchor marches outward -- chip, to one world, to many enclaves, to a whole VM, to a whole VM plus its GPU -- and every step is forced by the previous generation's concrete failure.

flowchart LR G0["Gen 0: the chip (XOM, AEGIS)"] -->|"no product, no remote attestation"| G1["Gen 1: one secure world (TrustZone)"] G1 -->|"single operator-owned world, not multi-tenant"| G2["Gen 2: many enclaves (SGX)"] G2 -->|"tiny page cache, app rewrite, attestation-key leaks"| G3["Gen 3: whole VM (SEV-SNP, TDX)"] G3 -->|"the GPU where AI runs is outside the boundary"| G4["Gen 4: whole VM plus GPU (H100 CC)"]

Generations 0, 1, and 2 we have met: the academic secure processors that proved the model, TrustZone's single operator-owned world, and SGX's fragile fleet of enclaves. The generation that actually conquered the cloud is the third, and it has an internal story worth telling because it re-enacts, in miniature, the whole arc of the field.

A virtual machine whose entire memory is encrypted with a key held by an on-die security processor, and whose isolation is enforced against the hypervisor and the cloud operator -- so an *unmodified* guest operating system and its applications can be "lifted and shifted" into a confidential environment with no code changes. AMD SEV-SNP and Intel TDX are the two cloud-dominant confidential-VM technologies.

AMD's line began in 2016 with SME (whole-DRAM encryption via an inline AES engine in the memory controller) and SEV (Secure Encrypted Virtualization), which gave each VM a distinct key so a compromised hypervisor could not read guest memory. David Kaplan presented the architecture at USENIX Security that year [@amd-sme-sev-wp-2016] [@kaplan-usenixsec16]. It was the anchor jumping from a process to a whole machine.

But the first version leaked. Plain SEV left the guest's CPU registers in plaintext: on every VMEXIT, the hypervisor saved the register state -- the VMCB -- in the clear, exposing in-use secrets and permitting tampering. SEV-ES ("Encrypted State"), in 2017, closed that by encrypting the register state at VMEXIT [@amd-sev-overview] [@suse-sev-es-guide]. One leak found, one leak patched.

The deeper problem was structural, and it is the one AEGIS had warned about in 2003. SEV and SEV-ES encrypted memory deterministically and without authentication -- no integrity, no freshness.

The encryption of DRAM contents so that data is ciphertext outside the processor. Server TEEs key it on the physical address and make it *deterministic*: the same plaintext at the same location always yields the same ciphertext. Intel TDX uses AES-XTS; AMD SEV uses an XEX-mode tweak (XTS without the ciphertext-stealing step). Either way it is fast and free of per-write bookkeeping, but provides confidentiality only -- it leaks whether two ciphertexts are equal, and it cannot detect an attacker who records and later replays a valid ciphertext.

Deterministic, unauthenticated encryption is a seam, and researchers pried at it. CrossLine (2020) broke SEV's "security-by-crash" memory isolation [@crossline-2020]. CipherLeaks (2021) recovered secrets straight out of the deterministic ciphertext of the register-save area, through what its authors named the ciphertext side channel -- no speculation required [@cipherleaks-2021].

The vendors answered with integrity. AMD's SEV-SNP (2020) added rollback protection through the Reverse Map Table, which gives every physical page a validated owner, plus firmware-signed attestation rooted in a per-chip key, the VCEK [@amd-sev-snp-wp-2020]. Intel's TDX (2021) followed: Trust Domains isolated from the hypervisor by a CPU-attested TDX module in a new SEAM mode, with per-domain AES-XTS memory encryption and Intel-signed attestation [@intel-tdx-overview]. Both deliver near-native speed -- typically single-digit-percent overhead -- across a whole multi-gigabyte VM, with no tiny-cache cliff and no application rewrite [@kaplan-cacm-2023].

The internal mechanics of confidential VMs -- the Reverse Map Table's page-state machine, the full VCEK certificate chain up to AMD's Key Distribution Service, Intel's DCAP quoting flow, and the paravisor that lets an unmodified Windows or Linux guest run under SEV-SNP or TDX -- are dissected in the companion post on Azure Confidential VMs.

This article references that substrate rather than repeating it, because the capstone's budget belongs to the trust-anchor argument, the GPU frontier, and the honest contrast. Read that post for the CPU-VM plumbing; read this one for what the plumbing is for and where it breaks.

Notice what SEV-SNP restored and what it did not. It restored integrity through the Reverse Map Table. But the underlying memory encryption stayed deterministic and unauthenticated at the DRAM bus -- the freshness gap AEGIS closed in 2003 remained open, a design decision traded for whole-server speed. Remember that; Section 9 collects the bill.

The third generation was mature, deployed, and, for the workload that now defines the decade, insufficient. A CPU confidential VM protects data in CPU DRAM. But the moment a tensor crosses the PCIe bus to a GPU, it is plaintext in GPU VRAM -- readable by the operator, the hypervisor, or a DMA attack. And modern AI does not run on the CPU. It runs on the GPU. The whole-VM anchor, however polished, could not deliver confidential AI by itself, because the accelerator where the computation actually happens sat outside the boundary [@nvidia-h100-cc-preview-2023].

So the anchor took its final step. NVIDIA's H100, the Hopper generation, became the first GPU to support confidential computing -- private preview in July 2023, general availability with the CUDA 12.4 data-center driver in early 2024, in single-GPU passthrough mode [@nvidia-h100-cc-ga-2024]. It extends the encrypted, attested boundary across PCIe and into the GPU. VRAM is encrypted with keys held in an on-die root of trust and never exposed to host software; the only CPU-to-GPU data path is an AES-GCM-protected bounce buffer; and the link itself is established and protected with the SPDM device-security protocol [@nvidia-hcc-whitepaper] [@dmtf-spdm-dsp0274].

Composed with a CPU confidential VM, this keeps a proprietary model's weights and a user's data confidential through inference and training on the GPU. Blackwell extends it again, bringing GPU-to-GPU NVLink traffic inside the boundary through Protected PCIe and TEE-I/O, so an eight-GPU or rack-scale job runs as one confidential domain [@nvidia-secure-ai-blackwell-wp].

Here is the whole lineage on one axis.

Generation	Era	Trust boundary	Integrity or freshness at the DRAM bus	Attestation root	Status
Gen 0: XOM, AEGIS	2000, 2003	The chip package	Full integrity plus freshness trees	None (research)	Never shipped at scale
Gen 1: ARM TrustZone	2003 to 2004	One secure world	None originally	Platform-owner keys	Active in mobile
Gen 2: Intel SGX	2013	Process enclave	Integrity tree over a small cache	Intel EPID, later DCAP	Niche, minimal-TCB
Gen 3: SEV-SNP, TDX	2020, 2021	Whole VM	Integrity (RMP); deterministic, unauthenticated	AMD VCEK, Intel PCS	Active, cloud default
Gen 4: H100 Hopper CC	2023 to 2024	Whole VM plus GPU	AES-GCM on the link, vendor-protected VRAM	NVIDIA NRAS plus CPU root	Active, confidential AI

Read down the "attestation root" column and you can see the entire trust model at a glance: every generation, no matter how far outward the boundary moves, ultimately trusts a key placed in the silicon by a vendor. That invariant is the article's quiet drumbeat. But isolation inside the box is worthless to someone on the other side of the planet unless they can prove which box they are talking to. How?

5. Remote Attestation: The Linchpin

Everything so far is local. A chip encrypts its memory and isolates a workload from the operator. But picture yourself as the hospital in the opening scene, about to send an encrypted model key into a datacenter you do not control. From where you stand, a genuine confidential VM and an ordinary VM lying about being one look identical. Both accept your connection. Both claim to be secure. Isolation you cannot verify is worth nothing, because you cannot tell it apart from its absence.

The single idea that converts "trust me" into "verify me" is hardware-rooted remote attestation. It is the load-bearing move of the entire field, and it is what discharges the "plus attestation" in this article's thesis.

A procedure by which a TEE proves to a remote party what code and configuration it is running, rooted in a hardware-held key. The flow is always the same shape: the environment is *measured* (hashed), the measurement is packaged into a hardware-signed *quote*, a *verifier* checks that signature against a trusted vendor root, and only an environment that matches the expected measurement is treated as trustworthy [@rfc-9334].

The modern vocabulary is standardized by IETF RFC 9334, the Remote Attestation Procedures (RATS) architecture, which defines three roles: the Attester produces Evidence, the Verifier appraises that Evidence and produces Attestation Results, and the Relying Party acts on the results. Tellingly, RFC 9334 frames the whole model in the language this article has been using: the Verifier trusts "a manufacturer or the manufacturer's hardware" by storing the endorser's key as a trust anchor (Section 7.4). The standard itself names the thing that moves [@rfc-9334].

The hardware-signed report a TEE emits as proof of its state -- the measurement of its code and configuration, signed by a key that chains to the silicon vendor's root. In RATS terms it is *Evidence*; in AMD, Intel, and NVIDIA tooling it is usually called a *quote*. Its security rests entirely on the signing key staying secret: a quote is only as trustworthy as the key that signed it. sequenceDiagram participant A as Attester (the TEE) participant V as Verifier participant R as Relying Party (key service) A->>A: Measure code and configuration A->>V: Send signed Evidence (the quote) V->>V: Check signature against the vendor root V-->>R: Return Attestation Result, trustworthy or not R->>R: Compare the measurement to the expected value R-->>A: Release the secret only on a match

The final step -- release the secret only on a match -- has a name in production systems.

A policy that gates the release of a secret (for example, the key that decrypts model weights or patient data) on a *verified* attestation. The key-management service hands over the key only when the presented quote verifies against the correct vendor root and the measurement equals the expected, approved value. It is what turns an abstract "the environment is trustworthy" into a concrete "and therefore you may now have the key."

For ordinary confidential computing, one attestation suffices: the CPU confidential VM proves itself against its vendor root (AMD's VCEK for SEV-SNP, Intel's PCS/DCAP for TDX), and Secure Key Release hands over the key [@amd-sev-snp-wp-2020] [@intel-tdx-overview]. Confidential AI needs a decisive twist, because there are now two pieces of silicon in the boundary -- the CPU and the GPU -- provisioned by two different vendors, and each must prove itself against its own root.

In Azure's deployed confidential-AI pipeline, Microsoft Azure Attestation composes the AMD confidential-VM evidence and the NVIDIA GPU evidence into a single token -- but the GPU attestation is signed by NVIDIA's Remote Attestation Service (NRAS), not by Azure [@azure-attestation-overview] [@nvidia-nvtrust-docs]. Two signatures, two roots, one composed result.

The procurement-critical mistake -- and it is a real one -- is to verify the CPU VM and assume the GPU is covered. The trust boundary "spans confidential VM on the CPU and attached GPU," and each half has its own chain of custody back to a different manufacturer [@azure-gpu-options]. The NCCadsH100v5 virtual machine size, an AMD SEV-SNP EPYC Genoa VM with an in-boundary H100, is the reference implementation of exactly this pattern [@azure-nccadsh100v5].

{` // Illustrative logic, not a real crypto library. function verifyQuote(quote, expectedRoot, expectedMeasurement) { const rootOk = quote.signedBy === expectedRoot; const measurementOk = quote.measurement === expectedMeasurement; return rootOk && measurementOk; }

const cpuQuote = { signedBy: "AMD-VCEK", measurement: "cvm-image-v1" }; const gpuQuote = { signedBy: "NVIDIA-NRAS", measurement: "h100-cc-enabled" };

const cpuOk = verifyQuote(cpuQuote, "AMD-VCEK", "cvm-image-v1"); const gpuOk = verifyQuote(gpuQuote, "NVIDIA-NRAS", "h100-cc-enabled");

// Cardinal rule: release the secret ONLY when both roots verify. console.log(cpuOk && gpuOk ? "Both attestations valid -- releasing model and data keys" : "Attestation failed -- refusing to release keys");

// A quote signed by the wrong key must be rejected, even with a valid measurement: const forged = { signedBy: "attacker-key", measurement: "h100-cc-enabled" }; console.log("Forged GPU quote accepted? " + verifyQuote(forged, "NVIDIA-NRAS", "h100-cc-enabled")); `}

There is a family resemblance to Part 2 of this series. A zero-knowledge proof lets a prover convince a verifier a computation was done correctly without revealing the inputs; an attestation quote lets a chip convince a verifier the expected code is running without the verifier seeing the datacenter. Attestation is the silicon analogue of a verifiable claim -- a proof about which machine and which code, not which computation. The companion post on Apple Private Cloud Compute versus Azure confidential AI pushes this further, to attestation against a publicly logged build, which Section 6 reaches.

Key idea: Attestation, not encryption, is the load-bearing move. A remote party cannot distinguish a real confidential VM from an ordinary VM lying about it -- unless the hardware proves itself with a signed quote checked against a vendor root, and the secret is released only on success. And confidential AI needs two such proofs, against two roots. Without attestation, silicon isolation is unverifiable and you are back to trusting the operator's word.

Note: If you procure confidential AI, verify both halves. Check the CPU VM's quote against the correct CPU vendor root, check the GPU's quote against NVIDIA's root, and gate Secure Key Release on both. A pipeline that attests the CPU and trusts the GPU by assumption has a plaintext hole exactly where the model runs.

So the silicon works, and we can prove it works, to someone who cannot see the building. Is this the thing that finally makes confidential AI real at GPU speed? What does the state of the art actually ship in 2026?

6. Confidential AI in 2026

Return to the hospital. The model owner encrypts the weights; the hospital encrypts the scans; both keys are held by a key-management service that will release them only to an attested environment. A confidential VM boots on an AMD SEV-SNP host, an H100 in confidential-computing mode is attached to its trust boundary, and both halves attest -- the CPU against AMD's root, the GPU against NVIDIA's -- before either key is released. Now trace the data.

The single permitted data path between a CPU confidential VM and a GPU in confidential-computing mode. Because host software must never see plaintext, the CPU VM encrypts each transfer with AES-GCM into a shared buffer, and the GPU decrypts it only inside its own boundary (and vice versa on the way back). Data is never plaintext on the PCIe bus or in host memory [@nvidia-hcc-whitepaper]. A DMTF standard (DSP0274) for authenticating a hardware device and establishing an encrypted, integrity-protected session with it over a bus such as PCIe. NVIDIA H100 confidential computing uses SPDM to authenticate the GPU to the CPU confidential VM and secure the link between them [@nvidia-hcc-whitepaper] [@dmtf-spdm-dsp0274]. flowchart LR A["Tensors inside the CPU confidential VM"] -->|"AES-GCM encrypt"| BB["Encrypted bounce buffer on the PCIe bus"] BB -->|"SPDM-secured session"| G["Decrypt only inside the GPU TEE"] G --> VRAM["Compute on encrypted VRAM"] ROT["On-die GPU root of trust holds the keys"] --> G

The plaintext model and the plaintext scans exist in exactly two places: inside the CPU confidential VM's encrypted memory, and inside the H100's encrypted VRAM. On the wire between them they are AES-GCM ciphertext; to the operator, the hypervisor, and anyone with a bus analyzer, the whole pipeline is opaque. That is confidential AI, and the reason it matters is the number attached to it.

An empirical benchmark by Zhu and colleagues measured H100 confidential computing across many models and input sizes: the average throughput overhead is under nine percent versus the TEE disabled [@zhu-hopper-benchmark-2024]. This is the headline homomorphic encryption cannot touch. FHE on a 70-billion-parameter forward pass is orders of magnitude too slow for real time; a GPU TEE runs the same inference within a tenth of native speed.

Note: The counterintuitive finding is that the smallest model carries the highest overhead and the largest carries almost none: the study reports the overhead for Llama-3.1-70B on the H100 is negligible, close to zero. The residual cost is dominated by the encrypted CPU-to-GPU transfer, not by GPU computation -- so as a model gets bigger and compute-bound, the fixed encryption cost is amortized toward nothing [@zhu-hopper-benchmark-2024].

A consequence that surprises people: a faster GPU can show more relative confidential-computing overhead. The benchmark finds the H200 -- the same Hopper confidential-computing family as the H100, with faster HBM3e memory [@nvidia-hopper-arch-hub] -- exhibits a larger overhead percentage for the same model, because its quicker compute makes the fixed PCIe-encryption cost a bigger share of a smaller total [@zhu-hopper-benchmark-2024].

Set the shipping methods side by side. The axes are the ones a practitioner actually chooses between: how big is the protected boundary, how much does it cost, whose root do you trust, does it fit AI, and how has it been broken.

Dimension	Intel SGX	AMD SEV-SNP	Intel TDX	NVIDIA H100/H200 CC	Blackwell multi-GPU
Granularity	Process enclave	Whole VM	Whole VM	GPU plus CPU VM	Multi-GPU plus CPU VM
First shipped	2015	2021	2023	2024 GA	2024 to 2025
Overhead	Near-native in cache; 5 to 100 times on paging [@vault-asplos-2018]	Near-native (design)	Near-native (design)	Under 9% avg; near-zero for 70B [@zhu-hopper-benchmark-2024]	Vendor near-native
Boundary	About 90 to 96 MB usable cache	Whole VM	Whole VM	Full VRAM, single-GPU	8-GPU or rack domain
Attestation root	Intel EPID then DCAP	AMD VCEK	Intel PCS/DCAP	NVIDIA NRAS	NVIDIA NRAS plus CPU root
AI fit	Poor	CPU-only	CPU-only	Native, single-GPU	Native, multi-GPU
Representative break	WireTap, SGAxe, Foreshadow	Battering RAM, TEE.Fail	TEE.Fail forged quote	TEE.Fail keys reach GPU CC	Inherits the ceiling
Status	Niche	Cloud default	Intel lift-and-shift	Confidential AI	Emerging, frontier scale

Two more methods complete the 2026 picture. NVIDIA's Blackwell generation extends confidential computing across multiple GPUs -- bringing NVLink traffic inside the boundary via Protected PCIe and TEE-I/O, up to a 72-GPU rack as a single confidential domain -- which is the emerging answer for frontier-model training and inference that a single GPU cannot hold [@nvidia-secure-ai-blackwell-wp]. And Apple Private Cloud Compute, announced in 2024 for Apple Intelligence, raises a different bar entirely.

Apple PCC's distinguishing move is not the enclave but the verifiability of the entire fleet. Apple publishes every production server image to an append-only transparency log with a signed measurement, and a user's device sends data only to a node whose attestation matches a publicly logged build [@apple-pcc-blog] [@apple-pcc-source]. Plain attestation proves you are talking to an approved build; PCC's transparency proves that build is one the whole world can inspect -- closing the "the provider quietly changed the software and you could not tell" gap. The companion post on Apple PCC versus Azure confidential AI develops that contrast.

A 2025 systematic security analysis reverse-engineered the internals of NVIDIA GPU confidential computing -- the SEC2 bootstrap channel and the paired work-launch and launch-confirmation channels that carry signed, encrypted work into the protected region -- mapping exactly where the trusted and untrusted seams lie [@gpu-cc-security-analysis-2025].

One myth to retire while we are here. There was no "Confidential GPT-4" general-availability release in 2024, however often the phrase circulates; the publicly demonstrated confidential-inferencing workload was a speech-to-text model [@nvidia-azure-h100-cvm-ga-2024], and the shipping CPU-plus-GPU pipeline anyone can rent is NCCadsH100v5 [@azure-nccadsh100v5]. The reality is more impressive than the folklore, because it is real.

This is real, it ships, and it is fast. So is the silicon trust model simply better than the mathematics of Parts 1 to 4? Time for the honest accounting.

7. Two Trust Models, Side by Side

Raluca Ada Popa put the fork in the road into four words. The question a system designer faces when they must compute on sensitive data is: confidential computing or cryptographic computing? Hardware enclaves on one side, cryptography on the other -- and the honest framing of the choice is the intellectual core of this capstone [@popa-cc-vs-cryptographic-2024].

The field offers two options for computing on data you are not allowed to read: confidential computing, which anchors trust in hardware, or cryptographic computing, which anchors it in mathematics. -- after Raluca Ada Popa, Communications of the ACM, 2024

Start with the precision that everything else depends on, because it is the single most common error people make about TEEs. A TEE is not "math-free." It is saturated with cryptography: AES memory encryption on the DRAM bus, AES-GCM on the CPU-to-GPU link, and ECDSA or EPID digital signatures on every attestation quote [@amd-sev-snp-wp-2020] [@nvidia-hcc-whitepaper].

So the thesis is not "mathematics versus no mathematics." It is about where trust is anchored. In the mathematical schemes of Parts 1 to 4, confidentiality rests on a computational-hardness assumption -- breaking it means solving a problem believed to be intractable. In a TEE, confidentiality rests on a vendor, a die, and the assumption that no exploitable side channel exists. Both use math. They differ in what you trust when you rely on them.

Lay the two anchors on one axis.

Dimension	Silicon (TEEs, this article)	Mathematics (FHE, ZK, MPC, PIR -- Parts 1 to 4)
Trust anchored in	A vendor, a die, and "no exploitable side channel"	A computational-hardness assumption
Vendor in the trust base?	Yes -- attestation chains to a vendor-provisioned root key	No vendor root
Uses cryptography?	Yes (AES memory encryption plus signed attestation)	Yes (the computation itself is cryptography)
Overhead	Near-native to under 9% on a GPU	Roughly $10^3$ to $10^6$ times for FHE; scheme-dependent
Real-time large-model inference	Yes (H100/H200 CC)	No (too slow today)
Breakable by a physical adversary?	Yes -- a memory interposer (2025)	No hardware to interpose on an assumption
Standing weakness	Vendor plus side-channel plus physical bus	Cost; FHE gives confidentiality, not integrity
Best for	Native speed on an untrusted operator you can accept a vendor for	No-vendor-trust, high-assurance, or regulatory workloads

Read the table as two lists of virtues that are also two lists of costs. The silicon model runs unmodified workloads at near-native speed and is the only thing on this page that makes confidential AI real at GPU scale [@zhu-hopper-benchmark-2024] -- but you must trust the vendor, the silicon, and the unprovable premise that no side channel is being exploited.

The mathematical model removes the vendor from the trust base entirely -- no die to trust, no fab to audit -- but pays in orders of magnitude of overhead and, for FHE, in sharp workload limits and confidentiality without integrity.

Key idea: The two ceilings are mirror images. The silicon model cannot remove the vendor from the trust base and cannot prove the absence of side channels. The mathematical model has no vendor root but cannot yet reach real-time large-model speed. Neither anchor dominates the other; each one's floor is the other's ceiling. That symmetry is why this capstone crowns no winner.

The four earlier parts are the mathematical trust model in four flavors. Part 1, fully homomorphic encryption, computes on ciphertext and never decrypts -- maximum confidentiality, maximum cost. Part 2, zero-knowledge proofs, proves a computation was done correctly without revealing its inputs -- the integrity cousin of a TEE's attestation.

Part 3, secure multi-party computation, splits a secret so no single party ever holds it. Part 4, private information retrieval, reads a record without revealing which one. Every one anchors trust in mathematics rather than a vendor. This fifth part is their foil, not their successor -- the hardware answer to the same twenty-five-year question, with a different bill.

Because the anchors are complementary rather than competitive, the mature answer is often to use both. A hybrid places each part of a workload where its trust costs least and delivers most: a TEE for the high-throughput bulk and the orchestration around it, and a cryptographic kernel -- an MPC step, an FHE evaluation, a zero-knowledge proof -- for the single most sensitive operation where you refuse to trust any vendor.

Signal's contact discovery is a small, real instance of the two models meeting: a privacy protocol deployed inside an SGX enclave, hardware isolation carrying a cryptographic design [@signal-cdsi]. You do not have to pick a side for the whole system. You pick an anchor per workload.

And if neither anchor dominates, the interesting question is no longer "which is better." It is "where does each one fail?" What, precisely, can no TEE ever promise -- not as a bug to be patched, but as a matter of structure?

8. What No TEE Can Promise

The limits of the silicon model are not a list of unpatched bugs. They are structural, and the field states them about itself. There are two, and they are mirror images of each other.

The lower bound is that you cannot remove the vendor from the trust base. Remote attestation requires a root that some manufacturer vouches for; there is no attestation without an endorser. RFC 9334 says this in as many words: the Verifier trusts "a manufacturer or the manufacturer's hardware" by storing that endorser's key as a trust anchor, and the components vouched for this way -- because no evidence is generated about them -- are the roots of trust (Section 7.4) [@rfc-9334].

Follow any TEE's trust chain to its end and it terminates at a key provisioned by a vendor, in a fabrication process you did not audit, running microcode you cannot read. Trusting the silicon entails trusting the vendor's supply chain. That is a floor the mathematical model simply does not have -- there is no vendor in the trust base of a lattice assumption.

The remote-attestation standard does not merely permit a vendor root; it names it. RFC 9334 calls the manufacturer's endorsement key a "trust anchor." The specification that makes silicon trust verifiable is also the specification that documents its irreducible dependence on the vendor -- the very thing this article argues moves.

The upper bound is that a TEE's confidentiality is only as strong as two things: the secrecy of its attestation key, and the integrity of its memory encryption. This is not a theoretical ceiling; both conditions have been violated in practice, which turns "upper bound" from a claim into a demonstration.

Extract the attestation signing key -- as SGAxe did with EPID, as WireTap did by recording a memory bus, as TEE.Fail did with Intel's provisioning key -- and a forged quote becomes cryptographically indistinguishable from a genuine one; the entire chain of trust collapses at once, not one machine at a time [@sgaxe-2020] [@wiretap-2025] [@tee-fail-2025]. Break the memory encryption's integrity -- as the 2025 interposers do against deterministic, unauthenticated encryption -- and the confidentiality guarantee unravels from the DRAM side [@battering-ram-2025].

Between what the model assumes and what it can prove sits a gap the field names openly.

Note: The Confidential Computing Consortium's own technical analysis lists bus and cache monitoring, cold DRAM extraction, and plugging a device into an existing port as in-scope threats the model aims to defend, and places only long-term invasive attacks such as decapping and microprobing, fault injection, and power or electromagnetic side channels out of scope [@ccc-technical-analysis-v1-3]. That boundary is what makes the 2025 memory-bus interposers so serious: they broke an in-scope, claimed-defended threat, not a residual risk the model had already disclaimed. Intel, AMD, and NVIDIA scope their threat models the same way. So "no exploitable side channel" is an assumption the model makes. It is never a guarantee the model provides.

There is a real epistemic difference between "we assume no adversary can do X" and "we have proven no adversary can do X." A hardness assumption in cryptography is at least a *falsifiable, studied* conjecture that the whole field attacks in the open.

"No side channel exists in this microarchitecture" is a weaker kind of assumption: a statement about an artifact that was never designed to make it true and that has been falsified again and again -- Foreshadow, SgxPectre, AEPIC, CipherLeaks, then the interposer wave. Treat a TEE's side-channel freedom as a hopeful default, not a load-bearing guarantee, and you will size its trust correctly.

Notice the symmetry, because it is the whole point of the capstone. The silicon model's ceiling is a vendor root it cannot remove and a side-channel assumption it cannot prove. The mathematical model's ceiling is cost -- and, for FHE, integrity it does not by itself provide -- but with no vendor root at all. Each model's ceiling is exactly the other model's floor.

Engineering can narrow the gaps but not close them. Authenticated, fresh memory encryption could close the interposer gap, but it costs the $O(\log N)$ integrity-tree tax AEGIS paid in 2003 and the cloud dropped for speed [@aegis-ics-2003]. Formal verification could shrink the side-channel gap. But no amount of engineering removes the vendor from the trust base of a hardware root of trust; that dimension belongs, structurally, to mathematics.

These are the assumptions, stated plainly. In October 2025, three research groups put a device between the processor and its memory and turned the assumptions into demonstrations.

9. How the Silicon Model Breaks

In 2025, three groups, three interposers, one root cause. A device you can build for the price of a nice dinner forges an attestation that the vendor's own verifier rates at its highest trust level. This is the moment the article's third turn lands: attestation did not make the TEE unbreakable. It moved the whole guarantee onto the secrecy of a signing key and the integrity of memory encryption -- and both are physically reachable.

Producing a quote that a verifier accepts as genuine without running the genuine, expected environment. The practical route is *key extraction*: once an attacker recovers the hardware attestation signing key, the forged quote it produces is cryptographically indistinguishable from a real one, because it is signed by the real key. The break is the whole trust chain, not one machine [@tee-fail-2025].

The root cause is the freshness gap AEGIS warned about in 2003. Server memory encryption is deterministic and unauthenticated at the DRAM bus: keyed on the physical address (AES-XTS on Intel, an XEX-mode tweak on AMD), with no per-write nonce and no integrity tag. That has two consequences an attacker on the bus can use -- equal plaintext blocks produce equal ciphertext (a leak of equality), and a recorded ciphertext can be replayed later (a break of freshness).

{` // Toy deterministic keyed mapping (NOT real crypto) to show the property. function detEncrypt(block, key) { let h = 0; for (const ch of (block + key)) h = (h * 31 + ch.charCodeAt(0)) % 100000; return "CT" + h; }

const key = "vm-key"; const a = detEncrypt("balance-100", key); const b = detEncrypt("balance-100", key); const c = detEncrypt("balance-999", key);

console.log("Equal plaintext -> equal ciphertext? " + (a === b)); // true: leaks equality console.log("Different plaintext -> different ciphertext? " + (a !== c)); // true

// Add per-write randomization (a nonce). This restores semantic security: function randomizedEncrypt(block, key, nonce) { return detEncrypt(block + ":" + nonce, key); } const f1 = randomizedEncrypt("balance-100", key, "nonce-1"); const f2 = randomizedEncrypt("balance-100", key, "nonce-2"); console.log("With randomization, equal plaintext -> equal ciphertext? " + (f1 === f2)); // false

// IMPORTANT: this only hides equality. It does NOT stop replay -- an attacker // can replay the (ciphertext, nonce) pair together. Real anti-replay freshness // needs the nonce authenticated in an on-chip version tree, exactly as AEGIS did. `}

That toy is the whole vulnerability class in miniature. Here is what the 2025 wave did with the real thing.

flowchart TD DET["Deterministic, unauthenticated encryption on the DRAM bus"] --> INT["Physical interposer between CPU and DIMM"] INT --> ALIAS["Alias or replay physical addresses"] INT --> RECORD["Record deterministic ciphertext"] ALIAS --> KEY["Extract the attestation signing key"] RECORD --> KEY KEY --> FORGE["Forge a quote that verifies UpToDate"] FORGE --> BROKEN["The whole attestation chain collapses"]

WireTap used a passive DDR4 interposer -- it only records bus traffic -- and, exploiting the deterministic encryption, extracted an SGX attestation key from a machine in fully trusted status. It then forged quotes end to end against SGX-backed blockchains with multi-million-dollar market caps [@wiretap-2025].

Battering RAM built an interposer for a total bill of materials of $47.62, invisible at boot, that aliases physical addresses to grant arbitrary plaintext access to SGX memory and to break SEV-SNP attestation on fully patched systems [@battering-ram-2025] [@kuleuven-batteringram-news].

TEE.Fail was the first DDR5 memory-bus attack. It extracted Intel's provisioning-enclave ECDSA key and forged a TDX quote that verifies at Intel DCAP's highest trust level, "UpToDate," carrying a deliberately impossible measurement -- the value 0x1337 -- while also reaching AMD SEV-SNP and, through the extracted keys, NVIDIA GPU confidential computing [@tee-fail-2025].

Defending against Battering RAM would require a fundamental redesign of memory encryption itself. -- the Battering RAM disclosure, 2025

The word "patched" is doing dangerous work in most people's mental models here.

Note: Every 2025 interposer attack works on fully patched silicon, because the flaw is not a bug in the firmware -- it is the deterministic, unauthenticated design of the memory encryption itself. A software or microcode update cannot close it. A fresh attestation proves the expected build booted; it does not prove that no interposer sits on the DIMM. Treat attestation as necessary, never as sufficient [@tee-fail-2025].

These are the microarchitectural side channels' louder cousins, but the quieter class has not gone away either. Foreshadow, SgxPectre, AEPIC, and CipherLeaks all leak enclave or VM secrets without a screwdriver, and undervolting fault-injection attacks such as Plundervolt can corrupt an enclave's computation from software [@foreshadow-l1tf] [@sgxpectre-2018] [@aepic-leak-2022] [@cipherleaks-2021] [@plundervolt]. Two attack families, one lesson: silicon trust is breakable in ways a hardness assumption is not.

The research racing to close these gaps is real, and the leading direction is a revival. Memory encryption with integrity and freshness at server scale -- literally AEGIS's 2003 insistence, reborn -- is the fix for the interposer class, though it must somehow avoid the logarithmic integrity-tree cost the cloud dropped for speed [@aegis-ics-2003]. Formally verified, side-channel-resistant TEE designs would move "no side channel" from an assumption toward a proof; the scholarly threat-model work on SGX is the starting point [@sgx-explained-2016].

Two more fronts are open. Multi-GPU confidential AI needs independent third-party benchmarking to match its rapid deployment [@nvidia-secure-ai-blackwell-wp]. And shrinking or de-monopolizing the vendor root -- Apple's publicly logged, transparent fleet is the leading move -- can make the root accountable even though it cannot be removed [@apple-pcc-blog]. The internals of GPU confidential computing are only now being independently dissected, exactly the adversarial scrutiny a 2024-era technology still needs [@gpu-cc-security-analysis-2025].

Here is the whole break surface on one table.

Attack (year)	Class	Primary target	What it achieves	Works on patched systems?
Foreshadow (2018)	Microarchitectural	SGX	Reads enclave memory and the attestation key	Mitigated by microcode
SgxPectre (2018)	Microarchitectural	SGX	Leaks enclave secrets via speculation	Mitigated
CipherLeaks (2021)	Ciphertext side channel	SEV-ES, SEV-SNP	Recovers secrets from deterministic ciphertext	Forced the RMP
AEPIC (2022)	Architectural MMIO	SGX	Dumps stale enclave data, no speculation	Mitigated
WireTap (2025)	Physical, DDR4 (passive)	SGX	Extracts the attestation key, forges quotes	Yes
Battering RAM (2025)	Physical, DDR4	SGX and SEV-SNP	Arbitrary plaintext, breaks attestation	Yes, fully patched
TEE.Fail (2025)	Physical, DDR5	SGX, TDX, SEV-SNP, reaches GPU CC	Extracts keys, forges an "UpToDate" quote	Yes, fully patched

The capstone resolves here. Because the silicon anchor is undone by a physical or microarchitectural adversary, the mathematical trust model of Parts 1 to 4 remains the higher-assurance floor for any workload that cannot accept a vendor in its trust base or an unprovable "no side channel" assumption. The two models are complements, not rivals -- which is exactly why neither made the other obsolete.

So what should you actually do on Monday morning -- reach for silicon, for mathematics, or for both?

10. Choose Your Anchor by Workload

The practitioner's question is not "which technology wins." It is "which anchor fits this workload and this threat model." Popa's framing is the north star: confidential computing or cryptographic computing, chosen deliberately, not by default [@popa-cc-vs-cryptographic-2024].

flowchart TD START["Choose your trust anchor"] --> Q1{"GPU needed for confidential AI?"} Q1 -->|"Yes"| GPU["H100 or H200 CC plus a CPU CVM, and enforce double attestation"] Q1 -->|"No"| Q2{"Lift-and-shift a whole VM?"} Q2 -->|"Yes"| VM["SEV-SNP or TDX confidential VM"] Q2 -->|"No"| ENC["SGX minimal-TCB enclave"] GPU --> VERIFY["Verify every quote against the correct vendor root, then gate key release"] VM --> VERIFY ENC --> VERIFY VERIFY --> Q3{"Accept a vendor in your TCB and the no-side-channel assumption?"} Q3 -->|"Yes"| SHIP["Ship on the TEE"] Q3 -->|"No"| MATH["Reach for the mathematics of Parts 1 to 4, or a hybrid"]

Walk the flow. First: do you need the GPU inside the boundary? If you are running confidential AI, the answer is yes, and the shape is an H100 or H200 in confidential-computing mode composed with a CPU confidential VM (single-GPU today), or a Blackwell multi-GPU domain for frontier scale [@azure-gpu-options].

If the GPU is not in play, choose between VM-level and process-level isolation: SEV-SNP or TDX to lift an existing OS and application into a confidential VM with no code changes, and SGX when the sensitive kernel is small enough to justify the minimal trust base and the porting effort.

Second, the step no path skips: actually verify the attestation. A TEE that is never attested is just a virtual machine that claims to be private. Gate secret release on a quote checked against the correct vendor root or roots, enforce double attestation for CPU-plus-GPU pipelines, and release the model and data keys only on the expected measurement [@azure-attestation-overview]. The single most common and most damaging misconfiguration is to verify one half of a two-vendor pipeline and assume the other is covered.

Note: If your key-release policy ever hands a secret to an endpoint whose quote you did not verify against the right root and the right measurement, you have built confidential computing with the confidentiality switched off. Everything else in this article is downstream of getting this one control right.

Third, know when not to reach for a TEE. If you cannot accept a silicon vendor in your trust base, cannot accept the standing "no exploitable side channel" assumption, or face an adversary with physical access to the memory bus, the silicon anchor is the wrong tool. The right one is the mathematics of the earlier parts, or a hybrid that uses a TEE for throughput and a cryptographic kernel for the most sensitive step.

The deep mechanics of deploying the CPU confidential VMs themselves live in the companion post on Azure Confidential VMs; this section stays at the level of which anchor, not which command.

The verification is not hypothetical hand-waving -- it is tooling you run. NVIDIA's nvTrust and its NRAS verifier attest the GPU; AMD's snpguest and the virtee project, plus Intel's DCAP, verify CPU quotes; Microsoft Azure Attestation composed with Secure Key Release gates the key; and Apple's security-pcc release lets anyone inspect the logged builds a device will talk to [@nvidia-nvtrust-docs] [@apple-pcc-source].

On an NVIDIA confidential-computing host, `nvidia-smi conf-compute -f` reports whether the GPU is in CC mode, and the nvTrust tooling runs local and remote GPU attestation against NVIDIA's verifier; on an AMD host, the `snpguest` utility fetches and validates a SEV-SNP attestation report. None of these replaces the real control -- gating key release on the verified result -- but they are how you confirm the boundary is actually on before you trust it [@nvidia-nvtrust-docs].

The series began by asking how to compute on data you are not allowed to read. Five parts in, we can finally answer -- not with one method, but with a choice, and with the judgment to make it well.

11. Frequently Asked Questions

No, and this is the most common misconception. A TEE is saturated with cryptography: AES memory encryption on the DRAM bus, AES-GCM on the CPU-to-GPU link, and digital-signature attestation on every quote [@amd-sev-snp-wp-2020]. The thesis of this series is not "mathematics versus no mathematics." It is about where trust is *anchored* -- in a silicon vendor and an attestation chain, rather than in a computational-hardness assumption [@popa-cc-vs-cryptographic-2024]. No. Attestation is exactly as strong as the secrecy of the signing key. Once that key leaks -- as WireTap did by passively recording a DDR4 memory bus, and as TEE.Fail did by extracting Intel's provisioning key -- a forged quote is cryptographically indistinguishable from a genuine one, and TEE.Fail's forged quote verified at the vendor's highest trust level [@wiretap-2025] [@tee-fail-2025]. Attestation is necessary, not sufficient. No -- that is the point of it. You move trust *off* the cloud operator and *onto* the silicon vendor, and then you verify that the operator is locked out. In Azure's confidential-AI pipeline the trust boundary spans the CPU confidential VM and the attached GPU, and the operator has no path to the plaintext inside either [@azure-gpu-options]. You are not trusting the provider; you are trusting the chip and proving the provider cannot see in. No. GPU confidential computing reached general availability in 2024, so it has seen a fraction of the adversarial scrutiny that a decade of SGX and SEV research produced [@nvidia-h100-cc-ga-2024]. No full-boundary GPU-CC compromise has been published, but its internals are only now being independently dissected. Newer is not the same as broken -- but it is not the same as battle-hardened either. No, and the difference is the whole series in one sentence. Fully homomorphic encryption, from Part 1, keeps the data encrypted *during* the computation and never decrypts it -- the trust is in mathematics. A TEE *decrypts inside* a hardware boundary and relies on the chip to refuse to leak it -- the trust is in silicon and attestation. Same goal, opposite trust anchors, wildly different performance. Often, yes, though the boundary is narrower than it sounds. The confidential-computing threat model places only long-term invasive attacks (decapping, microprobing), fault injection, and power or electromagnetic side channels *out of scope*; bus monitoring, cold DRAM extraction, and port-plugging are listed as *in-scope* [@ccc-technical-analysis-v1-3]. So the 2025 breaks matter more, not less: a fifty-dollar memory interposer defeated SGX and SEV-SNP attestation on fully patched systems, an in-scope threat the model claimed to withstand [@battering-ram-2025]. That is the honest limit of the silicon anchor, and it is precisely why the mathematical schemes of the earlier parts still matter. No. There was no general-availability release of a "Confidential GPT-4" in 2024, however often the phrase is repeated. The publicly demonstrated confidential-inferencing workload was a speech-to-text model [@nvidia-azure-h100-cvm-ga-2024], and the shipping CPU-plus-GPU pipeline anyone can actually rent is the NCCadsH100v5 virtual machine, an AMD SEV-SNP VM with an in-boundary H100 [@azure-nccadsh100v5].

Where the Trust Went

Start where we started: a hospital runs a proprietary 70-billion-parameter model on private scans, inside a cloud nobody in the room trusts, at under ten percent overhead, where fully homomorphic encryption would be three to six orders of magnitude too slow [@zhu-hopper-benchmark-2024].

The paradox dissolves once you see the move. The machine is not computing on data it cannot read; it is decrypting the data inside a boundary its owner is locked out of, and proving which boundary it is with a signed quote checked against a vendor root. The secret is never mathematically hidden. The trust is relocated -- from a hardness assumption to a die, a vendor, and an attestation chain.

That relocation is real, and it ships. Confidential AI in 2026 is not a demo; it is a rentable virtual machine with double attestation and secret release gated on a verified measurement [@azure-nccadsh100v5]. It is the one thing on the shelf that keeps a model and its inputs confidential at GPU speed, in the exact regime where mathematics is still too slow. For that class of workload, the silicon anchor is not a compromise -- it is the answer.

But the trust did not vanish; it moved somewhere with a physical address. A TEE's guarantee is exactly as strong as the secrecy of one signing key and the integrity of its memory encryption, and in 2025 a device costing less than a dinner extracted the key and forged a quote the vendor's own verifier rated "UpToDate" [@tee-fail-2025].

You cannot remove the vendor from the trust base -- the attestation standard itself says so [@rfc-9334] -- and you cannot prove the absence of side channels; the field concedes both as residual risk [@ccc-technical-analysis-v1-3]. Those are not bugs awaiting a patch. They are the shape of the silicon anchor.

So the series closes where an honest capstone must: with a refusal to crown a winner. For twenty-five years the field answered one question -- how do you compute on data the machine's owner cannot read? -- two ways. Fully homomorphic encryption, zero-knowledge proofs, secure multi-party computation, and private information retrieval answered with mathematics and paid in overhead. Trusted Execution Environments answer with hardware and attestation, and pay in a vendor you must trust and an attack surface a physical adversary can reach. Each anchor's ceiling is the other's floor.

The mature engineer does not ask which is better; they ask where the trust should live for this workload -- and sometimes the answer is a hybrid that uses both. The secret was never decrypted where an adversary could reach it. Across all five parts, that was only ever the beginning of the question. The end of it is knowing what, and whom, you had to trust to keep it that way.

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.