Parag Mali - tag: side-channels

Correct, Constant-Time, and Still Owned: A Field Guide to Side Channels, Faults, and Key Custody

noreply@paragmali.com (Parag Mali) — Tue, 14 Jul 2026 01:57:15 GMT

**Correct algorithms still leak.** Timing, cache, power, electromagnetic, speculative-execution, and induced-fault channels hand attackers keys that the mathematical proof never modeled -- and constant-time coding closes only the channels you can name. But relative to those exotic breaks, and relative to breaking the ciphers themselves, deployed systems fail most often at the least glamorous layer: key and secret management. Put the root key in hardware, use it without exporting it, envelope-wrap and auto-rotate everything else, and keep no long-lived secret sitting in software.

1. The Algorithm Was Correct. The Key Left Anyway.

In early 2024, researchers pulled private keys out of Apple's newest laptops -- not from buggy code, but from OpenSSL's Diffie-Hellman, Go's RSA, and the freshly standardized post-quantum algorithms CRYSTALS-Kyber and CRYSTALS-Dilithium, every one of them written to run in constant time [@gofetch-2024]. Twenty-eight years earlier, Paul Kocher had recovered a different private key by doing nothing more exotic than watching how long the math took [@kocher-1996]. Same lesson, two eras: the proof modeled the algorithm; the attacker measured the machine.

This is the twenty-fifth and final part of a field guide that spent twenty-four installments proving, primitive by primitive, that the mathematics holds. Each of those proofs came with a silent condition attached. RSA is secure if you blind the exponent. Elliptic-curve signatures are unforgeable if the nonce is uniform and the scalar multiplication is data-independent. AES-GCM is authenticated if you never reuse a nonce and you compare tags in constant time. Twenty-four times, the phrase "if the caller does X" carried the whole argument. This part is about what happens when that "if" meets a physical machine and a running organization.

Key idea: The math held; the machine and the operations handed the secret away. A cryptographic proof reasons about an algorithm -- an input/output relation. An attack happens to an implementation -- a physical, timed, power-drawing, speculating, operated process. The distance between those two things is the entire subject of this article.

That distance has a name, the abstraction gap, and it opens onto five surfaces where a correct algorithm sheds its secret. The first four are the exotic ones that make headlines: timing and cache channels, power and electromagnetic emanations, microarchitectural and transient-execution leaks, and induced faults. The fifth is the unglamorous one that ends most real incidents: the operational handling of keys and secrets themselves. The first four are where clever attackers earn conference papers. The fifth is where ordinary systems quietly die.

So this is not an encyclopedia of channels. It is an argument, backed by a catalog: every famous break in the record violates exactly one of four invariants -- a secret touched time, a secret touched an address, a fault skipped a check, or a key outlived or escaped its custody. Seen through those four invariants, the sprawling zoo of attacks collapses into a map that tells you where to spend your defensive budget.

To see why a correct algorithm leaks, though, you first have to see the gap the proofs never modeled. And it has a birthday.

2. Naming the Gap

Ask a cryptographer from 1990 what it means for a cryptosystem to be secure and you would get a clean answer: an adversary who sees only the inputs and outputs -- the ciphertexts, the signatures, the public keys -- cannot do better than guessing. The whole edifice of provable security, the IND-CPA and EUF-CMA definitions this series has used throughout, rests on that framing. The adversary is a mathematical object that submits queries and reads replies. It has no stopwatch, no oscilloscope, and no physical access to the box doing the computing.

That framing quietly omitted an entire dimension. A real computer does not merely map inputs to outputs. It takes time. It draws power. It radiates. It caches. It speculates. It can be made to stumble. None of those behaviors appears in the security definition, which means none of them was ever proven absent. The proof was silent about them not because they were safe, but because the model could not see them.

Information leaked by a computation's physical or microarchitectural behavior -- its running time, power draw, electromagnetic emanation, or cache state -- rather than by its defined input/output relation. A side channel is real even when the algorithm is mathematically perfect, because it lives in the machine, not the math.

There was already a Cold-War counterexample sitting in the open literature. In 1985, Wim van Eck published the first unclassified demonstration that a video display's electromagnetic emanations could be intercepted from a distance and its screen contents reconstructed with modest equipment [@van-eck-1985]. Militaries had worried about "compromising emanations" under the codename TEMPEST for decades; van Eck moved the problem into public view. The lesson was blunt: computation emits exploitable physical signals whether or not the theory chooses to look.Van Eck's result is not itself a cryptographic attack -- it reconstructs a screen, not a key -- but it is the moment compromising emanations entered the open scientific record, which is why it anchors the side-channel lineage [@van-eck-1985].

flowchart TD A["Algorithm: an input/output relation the proof reasons about"] -->|realized as| B["Implementation: a physical, timed, operated process"] A --> H["Output the proof models: ciphertext or signature"] B --> C["Leak channel: time and cache addresses"] B --> D["Leak channel: power and EM"] B --> E["Leak channel: speculation and prefetch"] B --> F["Leak channel: induced faults"] B --> G["Leak channel: key custody and secret handling"]

The eureka: time is an output

The gap got its name in 1996. Paul Kocher, then an independent cryptographer, made a single almost impudent observation: if the running time of a correct RSA or Diffie-Hellman exponentiation depends on the bits of the secret exponent, then merely timing the operation leaks the key [@kocher-1996]. No implementation bug is required. The code can be a flawless transcription of the textbook algorithm. The leak is in the fact that textbook modular exponentiation does more work for a one bit than for a zero bit.

The distance between an algorithm -- an input/output relation a proof reasons about -- and an implementation, which is a physical, timed, power-drawing, speculating, operated process. Every side-channel and key-management break in this article is a way of falling through that gap.

The canonical exponentiation loop makes the leak concrete. Square-and-multiply walks the secret exponent bit by bit: it squares at every step, and it performs an extra multiplication only when the current bit is one. The total running time therefore tracks the number of one bits, and finer measurements over chosen inputs recover the bits individually.

sequenceDiagram participant E as Exponent bit participant C as CPU participant T as Wall-clock time E->>C: current bit is 0 C->>C: square only C->>T: short step E->>C: current bit is 1 C->>C: square then multiply C->>T: longer step Note over C,T: total time tracks the number of one bits in the secret exponent

Kocher's insight was not a new algorithm. It was the naming of a missing dimension. And once you accept that wall-clock time is an output the proof forgot to model, the same argument applies to every other physical observable: power, electromagnetic field, cache occupancy, speculative footprint, the very correctness of the result. The defensive program for the next thirty years becomes a single sentence: find each channel and remove the secret's influence over it.Paul Kocher bookends this whole field. He named the timing channel in 1996, co-invented Differential Power Analysis in 1999, and two decades later was a lead author of Spectre in 2018 [@kocher-1996][@dpa-1999][@spectre-2019]. One researcher's career traces the arc from a stopwatch to speculative execution.

That program organizes the rest of this article around those four invariants -- time, address, fault, custody. Hold them in mind. If time was an output the proof ignored, so was every other physical observable, and the attackers were only getting started.

3. The First Defenses, and Their First Breaks

Here is a fact that ought to feel counterintuitive: within one year of Kocher showing you could learn a key by measuring a correct machine, two teams showed you did not even need the machine to be correct. You could make it compute wrong on purpose and read the key out of the error.

The first generation of defenses was a scramble of point countermeasures, one patch per channel. Against timing, Kocher himself proposed blinding: before the secret operation, randomize the input so its running time carries no information about the true message. For RSA decryption you pick a random $r$, multiply the ciphertext by $r^e$, decrypt, and divide out $r$. The identity that makes it work is

$$(m \cdot r^e)^d \equiv m^d \cdot r^{ed} \equiv m^d \cdot r \pmod{n},$$

so multiplying the result by $r^{-1} \bmod n$ recovers $m^d$ while the timing now depends on the random blind, not the secret. Blinding was a proposal in 1996; it became a default only after David Brumley and Dan Boneh showed in 2003 that an OpenSSL RSA key could be recovered over a network by timing decryptions, ending the comfortable assumption that timing attacks needed a local probe [@brumley-boneh-2003]. OpenSSL turned blinding on by default in response: a theoretical nicety became a shipped mitigation the moment someone proved the threat was remote.

Breaking the machine on purpose

While the timing people were blinding, the fault people arrived. In 1997, Dan Boneh, Richard DeMillo, and Richard Lipton at Bellcore showed that a single faulty RSA signature computed with the Chinese Remainder Theorem optimization lets an attacker factor the modulus with one greatest-common-divisor computation [@bellcore-1997]. The RSA-CRT speedup computes the signature modulo each prime separately and recombines the halves; corrupt just one half-computation -- a voltage glitch, a clock spike, a stray cosmic ray -- and the faulty signature $s'$ comes out right modulo one prime but wrong modulo the other. Raising it to the public exponent should return the message $m$; instead $s'^e - m$ shares exactly one of the two prime factors with $n$, so $\gcd(s'^e - m \bmod n, n)$ hands you that factor. One bad signature, and the private key falls out.

An attack that induces a computational error -- through a voltage or clock glitch, an electromagnetic or laser pulse, or a software-triggered disturbance like Rowhammer -- so that the faulty output reveals the secret. The Bellcore result is the archetype: one incorrect RSA-CRT signature factors the modulus.

The same year, Eli Biham and Adi Shamir extended the idea from public-key to symmetric ciphers with Differential Fault Analysis: inject faults during a DES computation, difference the correct and faulty ciphertexts, and the secret key emerges [@biham-shamir-1997]. The countermeasures wrote themselves in principle -- verify before you output a CRT signature, add redundancy and recompute, sense the glitch and refuse -- but each one added cost and each one had gaps.

Then, in 1999, Kocher returned with Joshua Jaffe and Benjamin Jun and opened the power rail. Simple and Differential Power Analysis showed that a device's instantaneous power draw depends on the data it switches, and that correlating power traces across many operations extracts a key even when the per-trace signal is buried in noise [@dpa-1999]. A smartcard running AES or RSA was leaking its key through its power pins to anyone with an oscilloscope and patience.

A statistical attack that correlates a device's measured power consumption across many operations with a hypothesized intermediate value, extracting the key even under heavy noise. Its countermeasures are masking (split secrets into random shares) and hiding (flatten or randomize the power signal).

The pattern is the argument. Each attack bred a defense -- blinding, verify-before-output, masking and hiding -- and each defense's gaps bred the next attack. This is whack-a-mole, and playing it one mole at a time was already visibly losing. Three structural cracks doomed the patch-by-patch approach: the channels were multiplying faster than the patches, each patch protected one primitive rather than the class, and the deepest crack was about to open -- the leak was preparing to jump from the value of the secret to the addresses the secret makes the processor touch.

There is a third way implementations betray correct algorithms that this article names but does not re-derive: the [random-number generator](/blog/predictable-or-repeated-the-only-two-ways-cryptographic-rand/). The 2008 Debian OpenSSL disaster (a commented-out line collapsed key entropy to a few thousand possibilities) [@debian-openssl-2008], the 2010 PlayStation 3 ECDSA break (a reused signing nonce) [@ps3-ecdsa-2010], and 2017's ROCA (a structured-prime library flaw) [@roca-2017] are all implementation and operational failures, not broken math. They belong to the randomness and [nonce-reuse](/blog/one-number-used-twice-how-a-repeated-nonce-hands-over-your-p/) story told in Parts 2 and 8 of this series. Keep them in view as a fourth failure family; we return to their operational cousin -- key custody -- as this article's payoff.

4. The Channels Multiply

The next twenty years were a single sentence repeated in new dialects: the secret leaked through a channel the proof never modeled. What changed each time was the channel. Here is the whole family tree, and the timeline that carries it.

timeline title Thirty years of the abstraction gap 1985 : van Eck EM emanations 1996 : Kocher timing attack 1997 : Bellcore RSA-CRT fault : Biham-Shamir DFA 1999 : Kocher-Jaffe-Jun DPA 2003 : Brumley-Boneh remote timing 2005 : Bernstein AES cache : Percival hyperthreading 2013 : Lucky Thirteen breaks TLS 2014 : Yarom-Falkner Flush and Reload : Rowhammer 2018 : Meltdown and Spectre 2020 : Minerva : TPM-Fail 2022 : Hertzbleed via DVFS 2024 : GoFetch : KyberSlash

From the value to the address

The deepest move in the whole story is the one that happened between 2005 and 2014: the leak stopped being about the value of the secret and became about the addresses the secret makes the processor touch. Daniel Bernstein's 2005 cache-timing attack on AES showed that software using secret-dependent table lookups -- the standard fast AES implementation, indexing precomputed T-tables by key-dependent bytes -- leaks the key through cache timing, because which table entries end up cached depends on which ones the victim accessed [@bernstein-2005].

The same year, Colin Percival showed that Intel Hyper-Threading's shared L1 cache lets one thread spy on a co-resident thread's access pattern, recovering RSA key bits from a concurrent OpenSSL process [@percival-2005]. In 2006, Dag Arne Osvik, Adi Shamir, and Eran Tromer named and formalized the reusable primitives the field still uses [@osvik-shamir-tromer-2006]: Prime+Probe fills (primes) a cache set with the attacker's own lines, lets the victim run, then re-accesses (probes) those lines and times its own reload -- a slow reload reveals the victim evicted a line, so it needs no shared memory, while Evict+Time measures the victim directly.

A leak that recovers which memory addresses a victim touched by measuring shared-cache timing -- a hit is fast, a miss is slow. Flush+Reload is the sharpest variant: an attacker flushes a shared line, waits, then times the reload to learn whether the victim accessed it in the interval.

The technique reached its high-resolution form in 2014, when Yuval Yarom and Katrina Falkner delivered Flush+Reload: flush a shared cache line with clflush, wait, then time the reload to learn whether the victim touched it, all through the last-level cache shared across cores [@flush-reload-2014]. It recovered GnuPG RSA keys across cores and became the workhorse primitive behind the transient-execution attacks that followed. The countermeasure had crystallized into a principle, not a patch: never let a secret decide which address you touch.

From local to remote, and a flaw in the spec

Parallel to the address story ran the reach story. Brumley and Boneh had already made timing a network threat in 2003. Then, in 2013, Nadhem AlFardan and Kenneth Paterson published Lucky Thirteen, and it stung in a new way: the non-constant-time MAC-and-padding check in TLS and DTLS CBC-mode record processing is a timing oracle, and a man-in-the-middle can recover plaintext from it [@lucky13-2013]. The wound was not one library's bug. The TLS specification mandated a MAC-then-pad-then-encrypt construction whose safe verification is genuinely hard to do in constant time. This was a spec-level flaw -- a reminder that "write it in constant time" is sometimes fighting the protocol design itself.

Below the instruction set

For a decade the discipline looked like it might be enough. Then, on 3 January 2018, the floor gave way. Meltdown and Spectre showed that transient execution -- the out-of-order and speculative machinery every fast CPU uses -- runs secret-dependent code paths that the architectural program never takes, and leaks their traces through the cache [@meltdown-2018][@spectre-2019][@projectzero-2018]. Meltdown let an unprivileged process transiently read kernel memory. Spectre poisoned branch prediction so that even correct, constant-time code speculatively executed a secret-dependent path and left it in the cache for a Flush+Reload probe to recover.

Instructions a CPU runs speculatively or out of order and then discards architecturally, so they never affect the program's official result -- but whose microarchitectural traces, chiefly cache state, survive and leak. Spectre and Meltdown proved that constant-time source code can be defeated by what the silicon does beneath it.

This was the qualitative break. Constant-time is a property of the instruction stream the programmer wrote. Speculation executes an instruction stream the programmer did not write, chosen by a branch predictor the attacker can train. The abstraction did not spring a leak; it was breached from underneath.Minerva (2020) is the miniature of the whole pattern: many ECDSA implementations leak the bit-length of the per-signature nonce during a non-constant-time scalar multiplication. Gather a couple thousand signatures, feed the tiny leaks to a lattice attack, and the long-term key falls out. On an Athena IDProtect smartcard the team needed about 2,100 signatures and recovered a P-256 key in minutes [@minerva-2020].

The machine keeps inventing channels

If Spectre broke constant-time from below through speculation, the next wave broke it from the side, through physics the instruction set never promised to hold still. In 2022, Yingchen Wang, Riccardo Paccagnella, and colleagues published Hertzbleed: modern x86 dynamic voltage and frequency scaling makes the CPU's clock frequency depend on the data being processed, so a program's wall-clock time depends on its data values -- turning a power side channel into a remote timing channel with no power measurement at all [@hertzbleed-2022]. They extracted a full key from a constant-time implementation of the post-quantum candidate SIKE, remotely.SIKE died twice. Hertzbleed broke its constant-time implementation in 2022 through frequency scaling [@hertzbleed-2022]. Weeks later, Wouter Castryck and Thomas Decru broke the mathematics of SIDH outright with a classical key-recovery attack, and SIKE was withdrawn [@castryck-decru-2023]. The math break is out of this article's implementation scope, but the coincidence is a useful reminder that a primitive can fall from either direction.

Then, in 2024, came the break that opens this article. Apple's M-series CPUs contain a Data Memory-dependent Prefetcher (DMP) that inspects values loaded from memory and, when one "looks like" a pointer, dereferences it speculatively to prefetch what it points to [@gofetch-2024]. That behavior is precisely the data-to-address coupling constant-time forbids. By crafting chosen inputs so that an intermediate value looks like a pointer only when a guess about a key bit is correct, the GoFetch team achieved end-to-end key extraction from constant-time OpenSSL Diffie-Hellman, Go RSA, and -- the part that should worry every protocol designer -- the post-quantum CRYSTALS-Kyber and CRYSTALS-Dilithium.

sequenceDiagram participant A as Attacker participant M as Victim memory participant DMP as Data-memory prefetcher participant Cache as Cache state A->>M: craft input so a value looks pointer-like only when the key-bit guess is right M->>DMP: value flows through a constant-time load DMP->>DMP: value resembles a pointer, so dereference it DMP->>Cache: prefetch pulls the pointed-to line into the cache A->>Cache: time the reload to confirm the guess Note over A,Cache: data influenced an address, the exact coupling constant-time forbids

The same year, KyberSlash showed the discipline is unfinished in a humbler way. Several Kyber implementations contained a single line that divides a secret numerator by a public denominator; because integer division takes a data-dependent number of cycles on many CPUs, that one statement leaks ML-KEM secret bits into timing, sometimes exploitably [@kyberslash-2024]. Not an exotic prefetcher -- just a division, in a freshly standardized algorithm, that no one flagged.

The fault lineage, in parallel

Running alongside the leakage story the whole time was the fault story, and it too grew more remote. Classical fault injection meant physically glitching a chip with voltage, clock, electromagnetic, or laser pulses. In 2014, Rowhammer changed the threat model: repeatedly activating one DRAM row flips bits in physically adjacent rows without accessing them, a hardware fault triggered entirely in software [@rowhammer-2014]. Plundervolt then showed you could undervolt an Intel CPU from software to induce faults inside an SGX enclave, corrupting cryptographic computations from the operating system [@plundervolt-2019]. The fault, like the leak, had escaped the need for physical possession.

One lens for the whole catalog

Set every named break side by side and re-read each as exactly one violated invariant. The zoo becomes a table.

Break (year)	Surface / channel	Root cause	Violated invariant	Lesson
Kocher timing (1996) [@kocher-1996]	Timing	Secret-dependent modular-exponentiation time	secret touched time	time is an unmodeled output; blind the operand
Bellcore RSA-CRT (1997) [@bellcore-1997]	Fault	One faulty CRT signature, then a single GCD factors n	fault skipped a check	verify before output
DFA (1997) [@biham-shamir-1997]	Fault	Fault plus differencing recovers the DES key	fault skipped a check	redundancy and verification
DPA (1999) [@dpa-1999]	Power	Data-dependent power draw over many traces	secret touched power	masking and hiding
Brumley-Boneh (2003) [@brumley-boneh-2003]	Remote timing	OpenSSL RSA decryption timing over a network	secret touched time, remotely	blinding on by default
Bernstein AES cache (2005) [@bernstein-2005]	Cache	Secret-indexed T-table lookups	secret touched an address	constant-time, AES-NI, bitslicing
Percival (2005) [@percival-2005]	Cache under SMT	Shared L1 under Hyper-Threading	secret touched an address	co-residency threat model
Lucky Thirteen (2013) [@lucky13-2013]	Timing	Non-constant-time MAC-and-pad check in TLS CBC	secret touched time	constant-time MAC verification, a spec fix
Flush+Reload (2014) [@flush-reload-2014]	Cache	Flush plus reload on shared last-level cache	secret touched an address	high-resolution shared-cache primitive
Rowhammer (2014) [@rowhammer-2014]	Fault, software-triggered	DRAM disturbance flips adjacent-row bits	fault skipped a check, no physical access	software can induce hardware faults
Meltdown and Spectre (2018) [@meltdown-2018][@spectre-2019]	Transient execution	Speculation runs secret-dependent paths, leaks via cache	secret touched an address below the ISA	constant-time broken beneath the ISA
Minerva (2020) [@minerva-2020]	Timing	Non-constant-time ECDSA nonce bit-length plus lattice	secret touched time	constant-time scalar multiplication
TPM-Fail (2020) [@tpm-fail-2020]	Timing	Secret-dependent ECDSA time in a certified TPM	secret touched time	certified is not side-channel-safe
Hertzbleed (2022) [@hertzbleed-2022]	Power to remote timing via DVFS	Frequency scaling makes wall-time data-dependent	secret touched time, remotely	power channels can go remote
GoFetch (2024) [@gofetch-2024]	Cache via DMP prefetcher	Prefetcher dereferences pointer-like data	secret touched an address below the ISA	constant-time unfinished, reaches PQC
KyberSlash (2024) [@kyberslash-2024]	Timing via division	Secret numerator over public denominator, variable-time divide	secret touched time	constant-time incompletely applied to ML-KEM
Storm-0558 (2023) [@csrb-storm0558]	Operational key custody	Unrotated, software-resident 2016 signing key	a key outlived and escaped its custody	custody, not math

Note: Every row above reduces to one of four sentences. A secret touched time. A secret touched an address. A fault skipped a check. A key outlived or escaped its custody. This is not a mnemonic; it is the map. Each invariant names both the break and the defense that closes it, and the last one -- custody -- is where the whole article is heading.

You can only close the channels you model, and the machine keeps inventing new ones.

Read the catalog through those four invariants and the pattern snaps into focus. Three of the four -- time, address, fault -- are the exotic surfaces, and they share one defense strategy. The fourth is different in kind, and it is where deployed systems actually break. That split is the breakthrough.

5. Two Breakthroughs That Arrive Together

After a decade of one-patch-per-channel, the field found the single rule that closes an entire family of channels at the source. And in almost the same breath, it learned the rule was necessary but not sufficient -- which forced a second, operational breakthrough to sit beside the first. The two arrive together because each is the other's admission of limits.

The software breakthrough: constant-time as a discipline

State it precisely, because the precision is the whole point. Constant-time code has no secret-dependent branches, no secret-dependent memory indices, and no data-dependent variable-time instructions. That is it. Crucially -- and this is the single most misunderstood idea in the field -- constant-time does not mean fixed-duration execution. It means data-independent execution: the same instruction stream and the same sequence of memory addresses regardless of the secret's value. A routine can finish in wildly different absolute times on different inputs and still be constant-time, so long as the variation never depends on a secret.

Code whose instruction sequence and memory-address trace do not depend on secret values. It is NOT fixed-duration execution. The rule has three clauses: no branch on a secret, no memory index computed from a secret, and no variable-latency instruction (early-exit compare, data-dependent division) applied to a secret.

In practice the discipline replaces three forbidden patterns. A secret-dependent if becomes a branchless select computed with masks and arithmetic. A secret-indexed table lookup, table[secret], becomes a full scan of the table with a constant-time select, or is dissolved entirely by bitslicing the algorithm into boolean operations that touch no data-dependent address [@bernstein-2005]. A variable-time operation on a secret -- an early-exit memcmp on a MAC, a division with a secret numerator -- is banned outright. Whole primitives were redesigned to make the discipline natural: Curve25519's Montgomery ladder runs the identical steps for every bit of the scalar, so there is no secret-dependent path left to leak.

The comparison case is worth seeing in code, because it is the exact mistake behind Lucky Thirteen and a hundred MAC-verification bugs.

{` // Early-exit compare: returns as soon as two bytes differ. // The iteration count reveals how long a prefix matched -- a timing leak. function earlyExitEqual(a, b) { if (a.length !== b.length) return false; for (let i = 0; i < a.length; i++) { if (a[i] !== b[i]) return false; // stops at the first difference } return true; }

// Constant-time compare: always scans every byte, accumulating differences. // Running time depends only on length, never on the secret contents. function constantTimeEqual(a, b) { if (a.length !== b.length) return false; let diff = 0; for (let i = 0; i < a.length; i++) { diff |= a[i] ^ b[i]; // no early exit, no branch on the data } return diff === 0; }

const tag = [1, 2, 3, 4, 5, 6, 7, 8]; const nearMiss = [1, 2, 3, 4, 5, 6, 7, 9]; // matches 7 of 8 bytes const farMiss = [9, 2, 3, 4, 5, 6, 7, 8]; // differs at the very first byte // earlyExitEqual iterates 8 times for nearMiss but only once for farMiss: // that difference is the leak an attacker times to forge a tag byte by byte. console.log('constant-time, near miss:', constantTimeEqual(tag, nearMiss)); console.log('constant-time, far miss :', constantTimeEqual(tag, farMiss)); `}

The other half of the breakthrough is that the property became checkable, and even provable. Oscar Reparaz and colleagues built dudect, which runs a routine on fixed-versus-random secret inputs and applies a Welch t-test: a stable t-statistic past the usual threshold flags a data-dependent timing leak, while a genuinely constant-time routine stays flat [@dudect-2017]. On the formal side, ct-verif encodes constant-timeness as a property over pairs of executions differing only in secrets and discharges it mechanically [@ct-verif-2016]. Constant-time stopped being a matter of the author's vigilance and became something a machine could test in CI or prove outright.

For the physical surface -- power, electromagnetic, glitch -- the corresponding discipline is masking, and it too became principled rather than ad hoc.

Masking splits every secret intermediate into $d+1$ random shares so that any $d$ probed values are statistically independent of the secret; the computation runs on shares. Threshold implementations add non-completeness and uniformity so the construction stays secure even under hardware glitches, which transiently leak the unmasked value [@threshold-impl-2006].

But masking closes only the physical channel, and constant-time closes only the modeled ISA-level channels. Spectre, Hertzbleed, GoFetch, and KyberSlash all live below the abstraction the discipline reasons about. You can be perfectly constant-time in the instruction stream you wrote and still leak, because the silicon runs an instruction stream you did not write. That is the wall the software breakthrough hits -- and it is the reason for the second breakthrough.

The operational breakthrough: key custody as an architecture

If you can never prove the whole machine leak-free, stop trying to eliminate leakage and instead bound what a leak can cost. That is the pivot. Concretely: put the root key inside a hardware boundary that generates and uses it without ever exporting it, and reach your data through an envelope.

A tamper-resistant boundary -- a dedicated appliance, a cloud Managed HSM, a TPM, or an embedded secure element -- that generates and uses keys without releasing them in plaintext. Software sends in a request (sign this, unwrap that) and gets back a result, never the key bytes. FIPS 140-3 validates such modules, including some non-invasive side-channel requirements. A pattern in which a cheap Data-Encryption Key (DEK) encrypts the bulk data, and a Key-Encryption Key (KEK) that never leaves the HSM or KMS wraps the DEK. The wrapped DEK is stored right beside the ciphertext; only the KMS can unwrap it. Standardized authenticated key wrapping (NIST SP 800-38F) supplies the wrap operation [@nist-sp800-38f].

The economics are what make it deployable. A hardware module is slow and expensive, so you do not run all your data through it -- you run one small wrap and unwrap through it, and let a cheap symmetric DEK do the bulk work. A leaked DEK exposes only the data it wrapped; the KEK, and therefore every other DEK, stays safe inside the boundary. Rotation becomes automatic and its blast radius bounded. This is the move from "make the code not leak" to "make a leak not matter," and it maps directly onto how NIST SP 800-57 tells you to think about key lifecycles and crypto-periods [@nist-sp800-57].

The junction

The two breakthroughs are two chains of the same story, and they meet at one move. Chain A drives the code toward not leaking, generation by generation, until it hits the microarchitectural wall. Chain B accepts that wall and shrinks what any residual leak is worth. The thesis of this whole series is the junction of the two: the math held; Chain A closes the channels you can model, and Chain B bounds the cost of the ones you cannot.

flowchart TD A0["A0: correctness is enough"] --> A1["A1: point patches, blinding, verify, masking"] A1 --> A2["A2: constant-time discipline"] A2 --> A3["A3: verified plus hardware-assisted constant-time"] B0["B0: keys as data, hardcoded or in config"] --> B1["B1: OS or software keystore"] B1 --> B2["B2: TPM, HSM, secure element"] B2 --> B3["B3: cloud KMS, envelope, automatic rotation"] A3 --> T["Thesis: the math held. Close the modeled channels, bound the cost of the rest"] B3 --> T

Key idea: Defense evolves from "make the code not leak" to "make a leak not matter." The first is Chain A and it is necessary. The second is Chain B and it is what saves you when Chain A inevitably has a gap the machine invented last week.

Both breakthroughs are engineering realities you can deploy today: verified constant-time libraries on one side, cloud KMS with envelope encryption and automatic rotation on the other. So what does the 2024 to 2026 state of the art actually look like when you ship both at once -- and where is it still losing?

6. The State of the Art, 2024 to 2026

There is no single best implementation. There are two parallel frontiers, and the 2024-to-2026 practitioner ships both at once. Call them Chain A, leakage defense, and Chain B, key custody.

Chain A: the leakage-defense frontier

At the base sits the constant-time-by-construction library. libsodium, Google's BoringSSL, Thomas Pornin's BearSSL, and Rust's ring obey the three-clause rule everywhere a secret is touched. This is table stakes now, not a differentiator -- if a general-purpose crypto library is not constant-time by default in 2026, it is not a serious library.

Above that sits the highest-assurance floor: formally verified constant-time crypto, where a machine-checked proof replaces human review.

Cryptographic code whose secret-independence is established by a machine-checked mathematical proof, not by review or testing. HACL* and EverCrypt (written in a subset of F*) and the Jasmin and libjade toolchain (with EasyCrypt) are the two production lineages; the proof itself is the constant-time argument, discharged once and re-checked automatically [@hacl-star].

This is not a laboratory curiosity. HACL* ships verified Curve25519 in Mozilla Firefox through NSS, and a formally verified Curve25519 rode into the Linux kernel alongside WireGuard; verified SHA-3 and HMAC from the same project ship inside CPython [@hacl-star]. Proof-carrying crypto is in the browser and the operating system you are reading this on.

Verifying and testing the property is its own layered toolchain, and no single tool dominates. A 2023 systematic evaluation quantified the trade-offs across real libraries [@sidetool-eval-2023]; the shape of the field is a ladder from cheap-and-empirical to expensive-and-proven.

Tool	Technique	Level analyzed	Guarantee	Catches compiler-introduced leaks	Effort	Microarchitecture
dudect [@dudect-2017]	Welch t-test on timing	Black-box, runtime	Empirical, tested paths	Only if exercised	Very low, CI drop-in	Not modeled
ctgrind / TIMECOP	Dynamic taint over Valgrind	Binary, dynamic	Empirical, executed paths	Yes, when observed	Low	Not modeled
ct-verif [@ct-verif-2016]	Formal self-composition	LLVM IR	All paths at the IR	No, runs before compilation	Medium, needs annotations	Not modeled
Binsec/Rel [@binsec-rel]	Relational symbolic execution	Final binary	All paths, bounded depth	Yes	High, setup and path explosion	Not modeled
HACL* / Jasmin [@hacl-star]	Proof in F* or EasyCrypt	Source down to C or assembly	Whole-program theorem	Verified assembly, yes	Very high, proof engineering	Not modeled

Read the last column: every tool shares the same blind spot. None models the microarchitecture, because none can -- a limit we return to in Section 8. The empirical tools like dudect are the ones you actually gate CI with, and the Welch t-test at their heart is simple enough to see in a few lines.

{// Simulate timing samples for two input classes: a "fixed" secret and "random" secrets. // A variable-time operation reacts differently to the two classes; a constant-time one does not. function mean(xs) { return xs.reduce((s, x) => s + x, 0) / xs.length; } function variance(xs, m) { return xs.reduce((s, x) => s + (x - m) * (x - m), 0) / (xs.length - 1); } // Welch t-statistic for two samples with unequal variance. function welchT(a, b) { const ma = mean(a), mb = mean(b); const va = variance(a, ma), vb = variance(b, mb); return (ma - mb) / Math.sqrt(va / a.length + vb / b.length); } function samples(n, base, classShift) { const out = []; for (let i = 0; i < n; i++) out.push(base + Math.random() * 5 + classShift); return out; } const N = 5000; // Variable-time op: the random class runs a few units longer on average, a real leak. const leakFixed = samples(N, 100, 0), leakRandom = samples(N, 100, 8); // Constant-time op: both classes share one distribution, no leak. const ctFixed = samples(N, 100, 0), ctRandom = samples(N, 100, 0); console.log('variable-time absolute t:', Math.abs(welchT(leakFixed, leakRandom)).toFixed(1), 'past 4.5 threshold, flagged'); console.log('constant-time absolute t:', Math.abs(welchT(ctFixed, ctRandom)).toFixed(1), 'below 4.5, clean');}

Beneath the software sits hardware backing. Intel's Data Operand Independent Timing Mode (DOITM) and Arm's Data Independent Timing (DIT) bit promise that an enumerated set of instructions runs with data-independent latency, re-establishing at the silicon level the guarantee the source could only assert [@intel-doitm][@arm-dit]. But their coverage is exactly their limit. The lists are vendor-specific and enumerated, and they pointedly exclude integer and floating-point division and square root -- which is why KyberSlash's secret division leaks -- and they do not model the prefetcher or frequency scaling, which is why GoFetch and Hertzbleed operate outside their guarantee entirely [@kyberslash-2024][@gofetch-2024].

For the physical surface -- power, electromagnetic, glitch -- masking and threshold implementations plus on-die fault sensors remain the answer, and the live research frontier is masking the post-quantum algorithms at practical cost.

Note: Reach for a verified or constant-time-first library -- libsodium, BoringSSL, BearSSL, ring, or the verified HACL* and libcrux -- and gate it in CI with dudect or TIMECOP [@hacl-star][@dudect-2017]. Home-rolled constant-time code is wrong until a tool says otherwise, and even expert-written code needs re-checking after every compiler upgrade, because optimizers reintroduce the branches you removed.

Chain B: the key-custody frontier

The operational state of the art is cloud KMS plus envelope encryption plus automatic rotation. AWS KMS, Azure Key Vault and Managed HSM, and Google Cloud KMS all keep a small number of Key-Encryption Keys inside a hardware boundary and wrap an unbounded number of cheap Data-Encryption Keys under them, using the authenticated key-wrapping of NIST SP 800-38F and the lifecycle discipline of NIST SP 800-57 [@nist-sp800-38f][@nist-sp800-57].AWS puts a concrete number on the crypto-period: keys that AWS manages rotate on a required schedule of every year, approximately 365 days, and customer-managed keys support optional automatic rotation on a period you choose [@aws-kms]. Rotation is O(1) to request; the hard part is re-wrapping and inventorying what each key protects.

For root keys -- certificate authorities, code-signing, payment keys -- the anchor is a FIPS 140-3 validated module.

The current U.S. standard for validating cryptographic modules, superseding FIPS 140-2. Unlike its predecessor's reputation, FIPS 140-3 explicitly addresses non-invasive security -- that is, side-channel resistance -- among its requirements, across four ascending security levels with increasing physical tamper response [@fips-140-3].

The third pillar is the least technical and the most often fatal: secrets management and non-human-identity hygiene. Application secrets -- API keys, database credentials, tokens, signing keys -- must stay out of code, config files, container images, and CI logs. OWASP made cryptographic-usage and keying failures the number-two web-application risk in 2021, and the 2025 OWASP Non-Human Identities Top 10 put improper offboarding (NHI1) and secret leakage (NHI2) at the very top of the list, with long-lived secrets also named (NHI7) [@owasp-a02-2021][@owasp-nhi-2025]. The tooling exists -- secrets managers that issue short-lived attested credentials, CI secret-scanning, workload federation -- but it demands organizational discipline no library can supply.

The concrete arc: Storm-0558 to Managed HSM

The clearest picture of Chain B's state of the art is the failure that forced it and the remedy that answered it. In 2023, the threat actor Storm-0558 forged Microsoft consumer authentication tokens using a 2016 signing key that was software-resident, held outside any HSM, and had never been rotated; a token-validation flaw let that consumer key mint enterprise tokens, and the actor downloaded roughly 60,000 State Department emails (about ten accounts), part of an intrusion that reached around two dozen organizations [@csrb-storm0558][@msrc-storm0558]. The U.S. Cyber Safety Review Board judged the intrusion preventable. No cipher was broken. A key simply outlived and escaped its custody.

Microsoft's remedy, under its Secure Future Initiative, is the Chain B playbook made concrete: the MSA and Entra ID signing keys moved into Azure Managed HSM with automatic rotation, and the signing service itself moved into confidential-computing VMs [@microsoft-sfi-2024]. Put the root key in hardware, use it without exporting it, rotate it automatically. That is the entire prescription, and it is exactly what was missing in 2016.

The honest caveat closes the section. Hardware custody is not a magic floor. A 2025 taxonomy catalogs how cloud HSM and TPM custody actually fails in practice, and TPM-Fail already showed that certified modules leak keys through timing [@hsm-tpm-failures-2025][@tpm-fail-2020]. Hardware moves the trust boundary; it does not remove it.

A few commands turn the abstract advice into an audit. Confirm a KMS key actually rotates with `aws kms get-key-rotation-status --key-id KEY_ID`. List which principals can call decrypt on it by reading the key policy with `aws kms get-key-policy --key-id KEY_ID --policy-name default`. Scan a repository's history for committed secrets with `gitleaks detect --source .` or `trufflehog filesystem .`. Gate a C library's tag comparison in CI by building it under `valgrind` with the TIMECOP macros, or by wiring a dudect harness around the routine. None of these is exotic; all of them catch the mistakes that end real incidents.

You now know the tools on both frontiers. The hard part is the two decisions nobody hands you: where do you put the defense, and where do you put the key?

7. Where Do You Put the Defense, and Where the Key?

Every choice in this field trades assurance against cost, portability, and threat model. Two decision axes organize the whole thing, and the good news is that within each axis the options mostly compose rather than compete.

Axis one: defense placement

The four leakage defenses are not rivals fighting for one slot. They stack. Ship verified constant-time as the floor, enable hardware data-independent-timing as backing, and add masking only when the adversary can physically hold and instrument the device.

Approach	Assurance	Runtime cost	Portability	Defends against	Blind to	Best suited for
Software constant-time	Review-level	Near-constant factor	High, any CPU	Timing and cache	Microarchitecture: Spectre, DVFS, DMP	Every deployment, the floor
Verified constant-time [@hacl-star]	Machine-checked proof	Same as software	High, generated C	Timing and cache, proven	Below the verified boundary; microarchitecture	Long-lived high-assurance primitives
Hardware DIT / DOITM [@intel-doitm][@arm-dit]	Vendor guarantee, listed instructions	Near zero for covered instructions	Low, vendor-specific	Operand timing of listed instructions	Prefetcher, frequency scaling, division	Defense-in-depth beneath software
Masking / threshold [@isw-2003]	Provable order-d in the probing model	Quadratic in the order	Hardware-oriented, costly in software	Power, EM, glitch faults	Higher-order analysis; cost	Physical-possession adversary

The table's lesson is the composition, not any single winner. Each defense covers what the one above it cannot; masking, in particular, is the only thing that helps once an attacker owns the silicon, and you pay for it by the square of the order. None of them closes the microarchitectural channels alone -- which is the structural reason Chain B has to exist.

Axis two: the key-custody spectrum

Custody is a ladder, and the single most useful skill in this whole article is matching the rung to the adversary and the asset value.

Rung	Key location	Exportable?	Blast radius on host compromise	Cost / latency	Use when	Anchor
0	Hardcoded, config, env var, repo	Yes, in plaintext	Total, the key is the leak	None	Never, an anti-pattern	Storm-0558 [@csrb-storm0558]
1	OS or software keystore	Yes, to root or admin	High	Low	Low-value single-host secrets	OWASP A02 [@owasp-a02-2021]
2	TPM or secure element	No, use without export	Low, but see TPM-Fail	Low to medium	Device-bound keys, measured boot	TPM-Fail [@tpm-fail-2020]
3	Cloud KMS plus envelope	KEK no, DEK wrapped	Bounded to unwrapped DEKs	One KMS round-trip per DEK	Data at rest at scale	AWS KMS [@aws-kms]
4	Dedicated or Managed HSM	No	Very low	Higher	Root, CA, code-signing, payment keys	FIPS 140-3 [@fips-140-3]
5	Threshold or MPC custody	No single holder	Requires several compromises	Highest, protocol rounds	No single point of trust, see Part 22	NIST SP 800-57 [@nist-sp800-57]

Here is the capstone's punchline, sitting in one table. The exotic Chain-A attacks -- a timing leak against a certified TPM at rung 2, say -- are real but rare. The overwhelming majority of real-world breaks cluster at rungs 0 and 1: keys hardcoded, sprawled across config and CI logs, software-resident, and never rotated. Storm-0558 was a rung-0 failure with a nation-state on the other end. The state-of-the-art move for almost everyone is simply to climb to rung 3 or 4 with automatic rotation, and to accept the custody regress that waits at the top.

Note: A key in source, in a config file, in an environment variable baked into an image, or in a repository is not "low assurance." It is the leak, waiting for any code, log, or memory disclosure to complete it. There is no asset value low enough to justify rung 0. Move to a secrets manager and rotate.

It is tempting to read a Common Criteria or FIPS certificate as "side-channel-proof." It is not. TPM-Fail recovered 256-bit ECDSA keys from an Intel firmware TPM and from a Common Criteria EAL4+ and FIPS 140-2 Level 2 certified STMicroelectronics chip, in minutes locally and about five hours across a network [@tpm-fail-2020]. Minerva broke FIPS-certified smartcards from a couple thousand signatures [@minerva-2020]. Certification validates a *modeled* threat surface against a defined protection profile; it bounds process, not physics. When the modeled surface omits the channel the attacker uses, the certificate is silent. "Certification has failed to protect the product against an attack that is considered by the protection profile." -- Moghimi et al., the TPM-Fail disclosure [@tpm-fail-2020]

These tables tell you what to reach for. But can leakage ever be eliminated, or are we only ever bounding its cost? The honest answer is uncomfortable, and it comes in two parts.

8. Can Leakage Be Eliminated?

The field owes you two very different answers. One is a clean, provable bound. The other is an honest impossibility that is not a theorem at all but a structural fact about how computers are specified.

The masking cost curve is a real bound, and it is not a wall

For the physical channel, the mathematics is unusually crisp. In the Ishai-Sahai-Wagner probing model, protecting a secret against an adversary who can observe up to $d$ internal wires requires at least $d+1$ random shares, and that bound is tight -- you cannot buy order-$d$ security with fewer [@isw-2003]. Securely masking a single multiplication in that model costs $O(d^2)$ in circuit size and randomness. So security grows linearly in the order while cost grows quadratically: doubling your resistance roughly quadruples the work.

Under a physically realistic noisy-leakage model, the picture gets better in one specific way. Duc, Dziembowski, and Faust proved that masking's security amplifies exponentially in the number of shares, provided each share carries enough noise, by reducing noisy leakage back to the clean probing model [@ddf-2014]. Put the two results together and you get the defining shape of the whole physical-defense story: leakage is a cost curve, not a wall. You can push the attacker's required number of traces arbitrarily high by paying $O(d^2)$ and ensuring noise. You can never push it to zero.

Whole-machine constant-time is an impossibility, not a theorem

For the timing and cache channels, there is no comparable happy bound, and the reason is almost embarrassingly simple. Constant-time cannot be guaranteed at the microarchitectural level because the instruction set architecture does not specify timing. A constant-time proof is a statement about ISA-visible behavior. The silicon underneath is free to introduce data-dependence the ISA never promised to forbid, and it repeatedly does.

Key idea: The ISA does not specify timing, so a constant-time proof only constrains architecture-visible behavior. You can only close the channels you model, and the set of channels is open-ended and adversary-discovered. Speculation, frequency scaling, and data-memory-dependent prefetching each reopened it after the proof was done.

This is why Spectre, Hertzbleed, GoFetch, and KyberSlash are not a series of fixable bugs but a series of demonstrations of the same structural gap. Each exploited a microarchitectural behavior -- speculation, DVFS, a prefetcher, variable-time division -- that no source-level or even ISA-level guarantee covered. There is no proof that a real machine leaks nothing through timing, and, because the ISA is silent on timing, none is possible with today's hardware contracts. The gap is not small and closing. It is structurally open until a complete, cross-vendor data-independent-timing contract exists, which DIT and DOITM only partially provide.

The custody regress

The operational half has its own impossibility, and it is the reason this article lands on key custody rather than on some final leak-proof coprocessor. Someone must ultimately hold a root secret. Hardware roots -- HSMs, TPMs, Managed HSMs -- move the trust boundary inward and defend it far better, but they do not remove it, and that smaller boundary has its own documented failure modes, from TPM-Fail's timing leak to the 2025 taxonomy of cloud HSM and TPM failures [@tpm-fail-2020][@hsm-tpm-failures-2025]. There is no keyless bottom. There is only a smaller, better-defended custodian, and certification of that custodian is necessary but never sufficient.

Hardware moves the trust boundary; it does not remove it.

So perfection is off the table on both halves. What replaces it is not despair but a different target.

Note: The honest goal is not zero leakage and not an unbreakable key. It is cost-optimality: make leakage so expensive to exploit, and each secret so short-lived and tightly bounded, that no leak is worth the attacker's effort. Masking raises the price of a power trace; short key lifetimes shrink the value of any single leaked bit; envelope encryption bounds the blast radius. You are not building a wall. You are pricing the attacker out.

The purely theoretical program of leakage-resilient cryptography pushes on the same questions from the model side, but relative to deployed masking and hardware custody it remains largely academic. If perfection is unreachable, the frontier turns into a list of concrete engineering fights -- and, refreshingly, they are winnable one channel at a time.

9. The 2026 Frontier

Name the open problems precisely and the field stops looking like whack-a-mole and starts looking like a research agenda. Each of these is calibrated engineering, not undetectable magic.

A complete microarchitectural timing contract. DIT and DOITM enumerate data-independent instructions, but they are vendor-specific and exclude division, square root, the prefetcher, and frequency scaling [@intel-doitm][@arm-dit]. Every constant-time proof is therefore conditional on an unmodeled microarchitecture, which is exactly the seam GoFetch and Hertzbleed pried open. The open problem is an ISA-level guarantee that extends a constant-time proof below the ISA, across vendors.

Speculative constant-time at scale. Spectre-class transient execution breaks architecturally constant-time code from beneath [@spectre-2019]. Retpoline, LFENCE barriers, and Speculative Load Hardening are point defenses with real, often double-digit-percent overhead [@llvm-slh]. A scalable, low-cost compiler that guarantees data-independence even under speculation, for whole libraries, does not yet exist.The community conjecture is that without hardware speculation-taint tracking, a software-only speculative-constant-time pass cannot be both complete and cheap. You either pay in overhead or accept coverage gaps.

Whole-library verification through the compiler. Compiler lowering reintroduces leaks that IR-level proofs miss, which is the entire motivation for binary-level tools like Binsec/Rel [@binsec-rel]. Today we have per-primitive proofs and per-binary bounded checks; 2024 work such as CT-Prover targets the scalability wall, and benchmarks map the tool terrain [@ct-prover-2024][@sidetool-eval-2023]. A push-button, whole-library, binary-level verifier usable by non-experts remains out of reach -- and usability studies show even experts misconfigure the current tools.

Constant-time and fault-resistant post-quantum code. KyberSlash and GoFetch proved the discipline is unfinished for the freshly standardized lattice schemes [@kyberslash-2024][@gofetch-2024]. Shipping ML-KEM and ML-DSA implementations that are simultaneously constant-time, masked against physical attack, and fast across diverse CPUs -- and proving it -- is an active frontier, because the arithmetic-heavy PQC code has larger, fresher leakage surfaces than classical crypto.

Secretless architectures and minimal key lifetimes. The dominant real-world failure surface is long-lived, sprawled, unrotated secrets [@owasp-nhi-2025]. Rotation, workload attestation, and short-lived derived credentials shrink the custody surface, but the custody regress forbids a truly secretless bottom. The open question is quantitative: how small can the irreducible custodian be made?

Post-quantum key management at fleet scale. Larger keys, hybrid classical-and-PQ modes, and harvest-now-decrypt-later urgency make the key lifecycle harder precisely as it becomes critical. Zero-downtime migration across a whole estate, with a cryptographic bill of materials for inventory, anchored on the lifecycle discipline of NIST SP 800-57, is an open operational problem handed off to the crypto-agility part of this series [@nist-sp800-57].

Note: Every item above is a bounded engineering fight with measurable partial results, not a wish for undetectable magic. That framing matters: it tells you which problems to fund and which "solutions" to distrust. Anyone selling a complete, cheap, whole-machine leak-free implementation today is selling the impossibility from Section 8.

This capstone deliberately defers depth to its siblings. Randomness and RNG failures live in Part 2; padding oracles and the Lucky Thirteen mechanics in Part 6; nonce reuse and the Minerva and PS3 stories in Part 8; RSA-CRT and Bleichenbacher detail in Part 14; scalar-multiplication leakage of the nonce in Part 15; deterministic-versus-hedged signing and its fault risk in Part 17; threshold and MPC custody, the top rung of the spectrum, in Part 22; ML-KEM and ML-DSA internals in Part 23; and rotation-at-fleet-scale, crypto-agility, and the cryptographic bill of materials in Part 24. Read as a set, the twenty-five parts are one argument.

The research agenda is clear. The deployment agenda is clearer still. Here is what to do on Monday.

10. What To Do on Monday

Everything above collapses into a handful of rules you can apply without a research budget.

The constant-time checklist

Anything that touches a secret gets three prohibitions: no branch on it, no memory index computed from it, no variable-time operation applied to it -- and "variable-time" specifically includes integer division and early-exit comparison. Test the result with dudect or TIMECOP in CI, prefer a verified library over your own code, and re-check after every toolchain upgrade, because compilers betray branchless code back into branches. That single decision rule fits in a diagram.

flowchart TD S["A value in your code"] --> Q{"Does it touch a secret?"} Q -->|no| OK["Ordinary code is fine"] Q -->|yes| R["Forbid all three"] R --> B["No branch on it"] R --> M["No memory index from it"] R --> V["No variable-time op: no divide, no early-exit compare"]

Threat-model routing for leakage defense

Match the defense to the adversary. Everyone starts from the same floor and adds as the threat model widens.

Adversary	Add to the floor	Because
Remote network	Verified or constant-time crypto, constant-time MAC checks, no padding oracles	This is the floor for everyone; it closes Lucky Thirteen and the timing family
Co-tenant, shared cache (cloud)	Cache-hardening, per-tenant isolation, hardware CT where honored	Prime+Probe and Flush+Reload cross tenant boundaries
Physical possession (smartcard, wallet, IoT)	Masking or threshold implementations, fault sensors, a secure element	The attacker owns and can instrument the silicon
Assume speculation, DVFS, DMP exist	Treat CT as necessary-not-sufficient; isolate secrets across process and VM boundaries; keep key lifetimes short	These channels live below the ISA and cannot be closed in source

The key-management playbook

The custody decision is a lookup table keyed on asset and threat. A low-value single-host secret belongs in the OS keystore. A device-bound key with measured boot belongs in a TPM or secure element. Lots of data at rest belongs behind cloud KMS with envelope encryption and automatic rotation [@aws-kms]. A root, certificate-authority, code-signing, or payment key belongs in a dedicated or Managed FIPS 140-3 HSM [@fips-140-3].

A key that must survive with no single point of trust belongs in threshold or MPC custody, the subject of Part 22. And any application secret belongs in a secrets manager issuing short-lived attested credentials, with CI secret-scanning behind it -- never hardcoded, always rotated, and stale non-human identities always offboarded [@owasp-nhi-2025][@nist-sp800-57].

One caution about rotation, because it is oversold. Rotation bounds the blast radius of a leaked key -- it caps how much a single compromised key is worth and for how long -- but it is not a substitute for custody. Storm-0558's key was both never rotated and software-resident; rotation alone would have shortened the exposure window, but keeping the key in an HSM is what stops the export in the first place. Rotate and custody; the two do different jobs.

The common-misuse catalog

Most real leaks are not exotic. They are the same dozen mistakes, made again.One misuse deserves special note because the fix for a different problem creates it: deterministic ECDSA (RFC 6979) removes the nonce-RNG risk [@rfc6979], but a fault during signing then yields two signatures on the same nonce, which recovers the key [@poddebniak-2018]. Hedged signing -- mixing in fresh randomness -- restores fault resistance without reopening the RNG risk. Part 17 treats this trade in full.

Misuse	Why it leaks	Fix
`memcmp` on a MAC or tag	Early-exit timing oracle, the Lucky Thirteen class [@lucky13-2013]	Constant-time compare (CRYPTO_memcmp, sodium_memcmp)
Secret-indexed table lookup	Cache-timing leak of the accessed address [@bernstein-2005]	AES-NI or bitslicing
Secret-dependent division or branch	Variable-time; division is not a data-independent instruction [@kyberslash-2024]	Replace with multiply, mask, or branchless select
Compiler betrayal	Optimizer restores a branch, or elides a memset that scrubs a secret	Verify the binary, use secure-zero intrinsics, re-check after upgrades
Skipping RSA-CRT verification	Reopens the Bellcore fault; one bad signature factors n [@bellcore-1997]	Verify the signature before releasing it
Home-rolled constant-time	Assume it is not constant-time until a tool proves otherwise	dudect or TIMECOP, plus a verified library
Hardcoded or sprawled secrets	Rung 0; the key is the leak [@csrb-storm0558]	Secrets manager, rotation, offboarding
Reusing a KEK as a DEK	Couples bulk data directly to the root key	Keep DEK and KEK distinct; wrap, do not encrypt with the KEK
Non-constant-time post-quantum code	Fresh, unhardened leakage surface [@gofetch-2024]	Patched, verified PQC libraries

The envelope pattern at the bottom of the custody advice is worth seeing in code, because the blast-radius argument is the whole point.

{` // Illustrative only. Real systems use AES-GCM to encrypt and AES-KW to wrap, // and the KEK lives inside an HSM or cloud KMS that performs wrap and unwrap on request. function xorCrypt(bytes, key) { return bytes.map((b, i) => b ^ key[i % key.length]); } function randomKey(n) { return Array.from({ length: n }, () => Math.floor(Math.random() * 256)); }

// The KEK never leaves this boundary; software only sends wrap and unwrap requests. const KEK = randomKey(16); function wrap(dek) { return xorCrypt(dek, KEK); } // stands in for a KMS wrap call function unwrap(wd) { return xorCrypt(wd, KEK); } // stands in for a KMS unwrap call

// Encrypt: fresh DEK per object, encrypt the data, wrap the DEK, store the wrapped DEK beside it. const data = [72, 105, 33]; const dek = randomKey(16); const ciphertext = xorCrypt(data, dek); const wrappedDek = wrap(dek); // this, not the plaintext DEK, is stored with the ciphertext

// Decrypt: ask the boundary to unwrap the DEK, use it, discard it. const plaintext = xorCrypt(ciphertext, unwrap(wrappedDek)); console.log('round-trips:', plaintext.join(',') === data.join(',')); // Blast radius: a leaked wrappedDek without the KEK reveals nothing; a leaked DEK exposes only its one object. `}

Note: Print the table above and run it against any code that touches a key. Every row has ended a real system. The first three are the constant-time family, the next four are custody, and the last two are the modern frontier. If your review cannot rule out all nine, you have not finished reviewing.

Note: Ship verified constant-time as the floor, back it with hardware timing modes and, for physical adversaries, masking -- then spend the rest of your budget where systems actually break, on key custody. Close the channels you can model; bound the cost of the ones you cannot.

11. Seven Beliefs That Ship to Production and Get People Owned

No, and this is the single most consequential misunderstanding in the field. Constant-time means *data-independent* execution: the same instruction stream and the same memory-address trace regardless of the secret's value. It does not mean fixed duration. A routine can run for different absolute times on different inputs and still be constant-time, as long as the variation never depends on a secret. Conversely, padding a function to a fixed wall-clock time does not make it constant-time if it still branches on a secret underneath. No. Certification validates a modeled threat surface, not physics. TPM-Fail recovered 256-bit ECDSA keys from an Intel firmware TPM and a Common Criteria EAL4+ and FIPS-certified STMicroelectronics chip via a timing-and-lattice attack -- minutes locally, hours remotely [@tpm-fail-2020]. A certificate tells you the module passed a defined evaluation; it does not tell you the evaluation covered the channel your attacker will use. Necessary, not sufficient. Constant-time is a property of the instruction stream you wrote; the silicon runs one you did not. Spectre executes secret-dependent paths speculatively, Hertzbleed turns data-dependent frequency into remote timing, GoFetch's prefetcher dereferences pointer-like secrets, and KyberSlash leaks through a variable-time division -- all beneath the constant-time abstraction [@spectre-2019][@hertzbleed-2022][@gofetch-2024][@kyberslash-2024]. Constant-time is the floor, not the ceiling. Mostly true, and you should threat-model it honestly: if no adversary can hold or instrument your device, the classical power and EM channels are lower priority than the remote ones. But the boundary is not absolute. Hertzbleed turned a power side channel into a *remote* timing attack by exploiting dynamic frequency scaling, extracting a key from constant-time SIKE over a network with no physical probe at all [@hertzbleed-2022]. Rotation bounds the blast radius of a leak; it does not prevent the leak. It caps how long a compromised key stays valid and how much it protects, which is real and valuable. But it is not custody. Storm-0558's key was never rotated *and* software-resident; rotation would have shortened the window, while hardware custody would have stopped the export that started the whole incident [@csrb-storm0558]. Do both. No. It is custody plus performance, not redundancy. A cheap Data-Encryption Key does the bulk work while the Key-Encryption Key that wraps it never leaves the HSM or KMS, using standardized key wrapping [@nist-sp800-38f]. The payoff is a bounded blast radius: a leaked DEK exposes only the one object it encrypted, and the root key stays in hardware. Double encryption gives you two layers of the same risk; envelope encryption gives you a small, cheap, disposable key over a small, protected, permanent one. No -- they are broken implementations and mismanaged keys. Scope the claim carefully: relative to breaking the primitives and relative to the exotic side channels this article catalogs, operational key and secret management is the dominant failure surface, evidenced by cryptographic failures ranking as the number-two web risk and by Storm-0558's uncracked-but-stolen key [@owasp-a02-2021][@csrb-storm0558]. It is *not* a claim that key management outranks every software vulnerability class -- memory-safety bugs lead by raw count. The math almost never breaks. The handling of the math does.

The Proof Was Conditional

Twenty-four times, this series proved that the mathematics holds. Every one of those proofs carried a silent condition: supply a fresh nonce, validate the point, derive a uniform key, compare tags in constant time, keep the secret in its custody. This final part is the condition, standing alone and made visible. The math held. The machine and the operations are what handed the secret away.

You now have the lens to read any future break the same way, without waiting for someone to explain it. When the next headline attack lands, ask which of four invariants it violated. Did a secret touch time -- a branch, a division, a data-dependent frequency? Did a secret touch an address -- a table index, a cache line, a prefetched pointer? Did a fault skip a check -- a glitch, a hammered row, an undervolted enclave? Or did a key outlive or escape its custody -- hardcoded, sprawled, unrotated, software-resident? Kocher's stopwatch in 1996 and Apple's prefetcher in 2024 are the same sentence in two dialects, and Storm-0558 is the fourth invariant in its purest form: no cipher broken, a key simply gone.

This article has claimed that key and secret management is where deployed systems most often break, and that claim needs its fences. It is scoped: *relative to breaking the primitives, and relative to the exotic side channels catalogued here*, operational custody is the dominant failure surface -- supported by cryptographic failures ranking as the number-two web-application risk and by nation-state incidents like Storm-0558 that cracked no math [@owasp-a02-2021][@csrb-storm0558]. It is *not* a measured majority over all software vulnerability classes; memory-safety bugs lead by raw count. The umbrella term is "key and secret management," and the honest version of the thesis never says "most of all breaches" -- it says "the dominant *operational* failure surface for cryptographic systems."

So end the series where the evidence points. Spend real effort on the exotic channels, because verified constant-time and hardware timing modes are now deployable and the microarchitecture will keep testing them. But spend the larger share of your budget on the unglamorous layer, because that is where the incidents actually cluster: put the root key in hardware, use it without exporting it, envelope-wrap and auto-rotate everything else, and keep no long-lived secret sitting in software. The twenty-five parts of this guide are one argument, and this is its last line.

The math held. Make sure the machine, and the people running it, do not hand the secret away.

The Doorway Into the Group: A Field Guide to Hashing a String Onto an Elliptic Curve (RFC 9380)

noreply@paragmali.com (Parag Mali) — Sun, 12 Jul 2026 15:35:47 GMT

**Turning a string into an elliptic-curve point is a two-decade research problem hiding behind a one-line API.** A safe map must produce a point whose discrete log is unknown, in time that does not depend on the input, with a distribution a proof can treat as a random oracle. The two obvious shortcuts each fail one of those tests: $H(m)\cdot G$ publishes the discrete log (forge BLS, break OPRFs), and try-and-increment leaks the input through timing (the Dragonblood attack read WPA3 passwords) [@rfc9380] [@vr20]. RFC 9380 (2023) finally delivers all three at once by hashing to two field elements, mapping each with a per-curve function, and adding the points [@rfc9380]. The standard is now quietly load-bearing under BLS on Ethereum, every elliptic-curve OPRF, OPAQUE, Privacy Pass, and WPA3's constant-time fix. This guide shows you why the naive maps fail, how the standard works, and exactly which suite to use for your curve and protocol.

1. They Timed the Handshake and Read the Wi-Fi Password

In April 2019, two researchers announced they could recover your Wi-Fi password without guessing it, phishing it, or breaking any cipher. They simply timed how long WPA3 took to turn the password into a point on an elliptic curve, and the clock spelled out the secret [@vr20] [@dragonblood-site]. The flaw was not in the encryption or the key exchange. It lived in a single, overlooked step that nearly every discrete-log protocol quietly leans on: the map that carries an arbitrary string into the group.

Get that one step wrong in the other obvious way, computing the point as $H(m)\cdot G$, and you leak a different secret entirely. Now anyone can forge the signatures that map was supposed to protect [@rfc9380] [@bls01]. Two shortcuts, two spilled secrets, one primitive. This is the field guide to getting it right.

A function that maps an arbitrary byte string to a point on an elliptic curve, such that the point's discrete logarithm (its relationship to the group generator) is unknown even to the party computing it. RFC 9380 standardizes the interface as `hash_to_curve` and `encode_to_curve` [@rfc9380].

The primitive looks trivial. Hash the input, get a point, move on. But "get a point" hides a genuine algorithm, because on an elliptic curve only about half of the field elements are valid $x$-coordinates. The two things every engineer tries first are the two things you must never ship, and each betrays a different secret. So before you write a single line, ask three questions.

Key idea: When you turn a string into a curve point, ask: (1) do you know the point's discrete log; (2) does your running time depend on the input; and (3) is the output distribution one your protocol's proof can treat as a random oracle? Every safe construction answers no, no, yes. Every named failure in this article is a wrong answer to exactly one of these.

WPA3-Personal answered the second question wrong. Its handshake, Simultaneous Authentication of Equals (SAE), derives a "password element" by hunt-and-peck: hash the password with a counter, test whether the result is a valid coordinate, and increment until it is [@rfc7664]. The number of iterations depends on the password, so the time the handshake takes is a function of the secret. Mathy Vanhoef and Eyal Ronen showed that an attacker within range can measure that timing and mount an offline dictionary attack, recovering the password without ever seeing a valid login [@vr20] [@dragonblood-site].

sequenceDiagram participant STA as Client (victim) participant AP as Access point participant Atk as Attacker (passive) Note over STA,AP: WPA3-SAE, password shared by both sides STA->>STA: Derive password element by hunt-and-peck Note over STA: Iteration count depends on the password STA->>AP: Send SAE Commit after the loop finishes Atk-->>STA: Measure time from trigger to Commit Note over Atk: Timing reveals the iteration count Atk->>Atk: Offline dictionary attack narrows candidates

RFC 9380, the standard that finally settled this primitive, is blunt about why try-and-increment is unsafe.

"The running time of this method, which is generally referred to as a probabilistic try-and-increment algorithm, depends on the input string. As such, it is not safe to use in protocols sensitive to timing side channels, as was exemplified by the Dragonblood attack." -- RFC 9380, Appendix A [@rfc9380]

The story got worse before it got better. The Wi-Fi Alliance's first attempt at a fix switched SAE to Brainpool curves, which reintroduced a leak: the encoder now had to loop to find a hash smaller than the prime, and the number of iterations depended on the password and the client's MAC address [@dragonblood-site].This second act is the whole lesson in miniature: constant time cannot be patched in curve by curve. The disclosure site concludes that "implementing Dragonfly and WPA3 without side-channel leaks is surprisingly hard" [@dragonblood-site]. Two rounds of the same class of bug, in the handshake now standard across WPA3 Wi-Fi.

Now hold that failure next to its mirror image. Suppose BLS signatures had mapped a message the naive way, $H(m) = H_n(m)\cdot G$ for a public hash $H_n$. A BLS signature is $\sigma = [sk]\cdot H(m)$, so it would equal $[sk]\cdot H_n(m)\cdot G = H_n(m)\cdot([sk]\cdot G) = H_n(m)\cdot PK$, where $PK$ is the public key [@rfc9380] [@bls01]. Every term on the right is public. Anyone forges any signature with no secret key at all. One shortcut leaked a low-entropy password through the clock; the other would hand out the signing key's power to the entire world. The primitive that sits between them is where the security of BLS, every elliptic-curve OPRF, and every password PAKE is actually won or lost.

This is the sibling of a claim Part 15 made about the curve itself: the elliptic-curve discrete-log problem was hard; the danger was the soft gap around it. Here the gap has a name and a shape. It is the doorway, the map that carries untrusted strings into the group. Get the doorway wrong and you publish the discrete log, leak the password through the clock, or hand your proof a distribution it never agreed to. To see why "hash to a point" is an algorithm and not a one-liner, we have to go back to the moment it stopped being free.

2. When Hashing to a Group Stopped Being Free

For a generation of cryptographers, "hash into the group" was not a problem worth naming. In a prime field $\mathbb{F}_p^$, the discrete-log setting Diffie and Hellman worked in, you hash your input to an integer and reduce it modulo $p$, and you are already inside the group. Every nonzero residue is a group element, so the map is a single modular reduction with nothing to prove.This is the free lunch elliptic curves took away. In $\mathbb{F}_p^$ the group is the set of nonzero field elements, so any nonzero hash output is already a valid element. On a curve, the group is a sparse subset of the plane, and most field elements are not on it.

Elliptic curves broke the deal. When Victor Miller and Neal Koblitz independently proposed elliptic-curve cryptography in 1985 and 1987, they replaced $\mathbb{F}_p^*$ with the points of a curve $y^2 = x^3 + ax + b$ [@miller85] [@koblitz87]. That change bought smaller keys and harder discrete logs, but it quietly created a new problem: for a random field element $x$, the quantity $x^3 + ax + b$ is a perfect square only about half the time, and only then is $x$ the coordinate of an actual point. "Hash to a group element" stopped being a reduction and became a search.

Nobody worried, because for a decade nobody needed to hash to a point. Ordinary ECDSA and ECDH hash to a scalar and multiply a fixed generator, which never leaves the safe world of exponents.Hashing to a scalar is trivial and always safe: any integer modulo the group order is a valid exponent. Hashing to a point is the hard problem, because most field elements are not on the curve.

Then, around the turn of the millennium, the demand arrived from two directions at once, and both directions needed a point.

A signature scheme by Boneh, Lynn, and Shacham built on a bilinear pairing. The signature on a message $m$ is $\sigma = [sk]\cdot H(m)$, where $H(m)$ is the message hashed *to a curve point* and $sk$ is the secret key. Verification checks a pairing equation. Security requires that $H(m)$ have unknown discrete log, or signatures become forgeable [@bls01].

The first direction was pairing-based cryptography. In 2001 Boneh, Lynn, and Shacham introduced BLS short signatures, whose entire construction rests on hashing the message to a curve point of unknown discrete log, because the signature is that point scaled by the secret key [@bls01]. The same year, Boneh and Franklin built identity-based encryption on the identical primitive, hashing an identity string to a point [@bf01]. BLS shipped with the first answer anyone reaches for: MapToGroup, a try-and-increment loop [@bls01]. Boneh and Franklin instead gave a deterministic map, but only for certain supersingular curves over fields of characteristic $p \equiv 2 \pmod 3$, too narrow a class to serve as general infrastructure [@bf01].

The second direction was password-authenticated key exchange. In 2008 Dan Harkins proposed Simultaneous Authentication of Equals, a balanced PAKE that maps a password to a group element and then runs a zero-knowledge proof of it [@sae08]. To do the mapping it introduced hunt-and-peck, the same try-and-increment idea aimed at a secret input. SAE was standardized as RFC 7664 in 2015, including its "Hunting and Pecking with ECC Groups" derivation, and then shipped to consumers in 2018 as the core of WPA3-Personal [@rfc7664] [@vr20].

Note: Pairing signatures and password PAKEs look unrelated, but both need the same thing: a hash whose output is a curve point of unknown discrete log. Pairing crypto needs it so a signature can be that point; a PAKE needs it so the password element hides the password. The primitive was born load-bearing under two families of protocols in the same decade [@bls01] [@sae08].

A scoping note worth keeping honest: not every PAKE maps a password to a curve point. SPAKE2 uses fixed, independently generated group elements $M$ and $N$ rather than hashing the password onto the curve, and SRP works in an integer group, not on an elliptic curve at all. The "everything depends on hash-to-curve" claim is precise, not universal, and it applies to the named constructions in this article: SAE, CPace, OPAQUE's OPRF, the RFC 9497 OPRFs, and BLS.The lesson for a field guide: SPAKE2 and SRP are the counterexamples that keep "all PAKEs need hash-to-curve" from being true, and they stop you hunting for the primitive where it is not.

So by 2008 the problem was named and both naive answers were on the table, shipped in real systems: $H(m)\cdot G$ carried the finite-field intuition onto curves, and try-and-increment searched for a valid coordinate. Each was correct in the sense that it produced a usable point. Each was also a disaster, and for opposite reasons. To see exactly what each one leaks, we have to look at the two shortcuts side by side.

3. Two Shortcuts, Two Spilled Secrets

Both obvious maps are correct in the ordinary sense: they produce a point on the curve, quickly, with a few lines of code. That is exactly what makes them dangerous. Each satisfies most of the three properties and fails precisely one, and the property each fails is different, which is why they leak different secrets.

Shortcut A: compute the point as a known multiple of the generator

Hash the message to an integer $H_n(m)$ and scalar-multiply the generator: $P = H_n(m)\cdot G$. The output is uniform on the group, costs one scalar multiplication, and is trivially constant-time. It assumes nothing about the curve. It is the finite-field intuition carried straight onto the curve, and it violates Property 1: whoever computed $P$ knows its discrete log, because they chose it.

RFC 9380 does not hedge about the consequence.

"The resulting point has a known discrete log relationship to $P$. Thus, except in cases where this method is specified by the protocol, it must not be used; doing so risks catastrophic security failures." -- RFC 9380, Appendix A [@rfc9380]

"Catastrophic" is exact, not rhetorical. Take BLS. The public key is $PK = [sk]\cdot G$, and a signature is $\sigma = [sk]\cdot H(m)$. If the map were $H(m) = [H_n(m)]\cdot G$ for a public hash $H_n$, then

$$\sigma = [sk]\cdot H(m) = [sk]\cdot[H_n(m)]\cdot G = [H_n(m)]\cdot([sk]\cdot G) = [H_n(m)]\cdot PK.$$

Every quantity on the right -- $H_n(m)$ from the public message, $PK$ from the wire -- is public. Anyone computes the valid signature on any message directly, with no access to $sk$ [@rfc9380] [@bls01]. This is not an edge case or a timing quirk. It is total, structural forgeability on every input. The same knife cuts elsewhere: for an OPRF, knowing the discrete log of the mapped input breaks obliviousness; for a PAKE, a password element with known discrete log no longer hides the password.

{` // ILLUSTRATION, NOT AN IMPLEMENTATION. // We model the group as integers mod a small prime order n, with // "scalar mult" [k]*P written as (k * P) mod n. Discrete log is trivial // here on purpose -- the point is the STRUCTURE of the forgery, not hardness. function scalarMul(k, P, n) { return ((k % n) * (P % n)) % n; }

const n = 97; // toy prime group order const G = 1; // generator const sk = 42; // signer's SECRET key const PK = scalarMul(sk, G, n); // public key = [sk]*G

// The UNSAFE map: H(m) = [Hn(m)]*G, so its discrete log Hn(m) is public. const Hn_m = 7; // public hash of the message const Hm = scalarMul(Hn_m, G, n); // the mapped point (known DL!)

// Honest signer computes sigma = [sk]*H(m) const legitSig = scalarMul(sk, Hm, n);

// Attacker never sees sk. Uses only Hn(m) and PK: const forgedSig = scalarMul(Hn_m, PK, n); // [Hn(m)]*PK

console.log("legit signature :", legitSig); console.log("forged signature:", forgedSig, "(computed with NO secret key)"); console.log("forgery succeeds:", legitSig === forgedSig); `}

Shortcut B: search for a valid coordinate

The other reflex fixes Property 1 and breaks Property 2. Hash the input together with a counter, test whether the candidate is a valid $x$-coordinate, and loop until it is.

A map that hashes the input with a counter to a candidate $x$, tests whether $x^3 + ax + b$ is a quadratic residue (a valid coordinate), and increments the counter until it is. A random $x$ works about half the time, so the expected number of tries is two [@rfc9380]. The output has *unknown* discrete log, but the number of iterations depends on the input.

Because nobody chose the output as a multiple of $G$, its discrete log is genuinely unknown, so Property 1 holds. That is exactly why BLS and SAE could ship with it and be functionally correct. The flaw is Property 2: the loop count is a function of the input, so the running time is too. When the input is a secret -- a password, a pre-shared key -- the clock becomes an oracle. That is Dragonblood [@vr20] [@rfc9380].

{` // ILLUSTRATION, NOT AN IMPLEMENTATION. // Count hunt-and-peck iterations for several secret inputs over a toy field. // A constant-time map would take the SAME work for every input; this does not. const p = 103; // toy prime, p = 3 mod 4 const a = 2, b = 3; // toy curve y^2 = x^3 + a x + b

// A stand-in for H(input || ctr): deterministic, input-dependent pseudo-x. function candidateX(seed, ctr, p) { return ((seed * 131 + ctr * 419 + 17) % p + p) % p; }

function iterations(seed) { for (let ctr = 1; ctr < 200; ctr++) { const x = candidateX(seed, ctr, p); const g = (((x * x % p) * x % p) + a * x + b) % p; if (isSquare(g, p)) return ctr; } return -1; }

for (const pw of [11, 23, 37, 58, 71, 90]) { console.log("secret input " + pw + " -> " + iterations(pw) + " iterations"); } console.log("Different inputs, different work: that difference is the leak."); `}

Here is the table that makes the whole article click. Two maps, three properties, and each map fails a different one.

Map	Unknown discrete log (Prop 1)	Constant time (Prop 2)	Right distribution (Prop 3)	The secret it spills
$H(m)\cdot G$	Violated (DL is $H_n(m)$)	Satisfied	Satisfied (uniform)	The signing key's power -- universal forgery [@rfc9380] [@bls01]
Try-and-increment	Satisfied	Violated (loop depends on input)	Roughly satisfied	The secret input -- via handshake timing [@rfc9380] [@vr20]

Try-and-increment is only a *vulnerability* when the mapped input is secret. A BLS signature over a *public* message runs the same variable-time loop, but the message is public, so the timing reveals nothing an attacker did not already have. The Dragonblood break works because a Wi-Fi password is a low-entropy secret. This is why the accuracy-critical phrasing is "variable time is dangerous when the input is secret," never "variable time is always dangerous" [@rfc9380] [@vr20].

Note: If the input to your map is a password, a PSK, or any low-entropy secret, a data-dependent loop over it is a timing oracle. Use a constant-time map. RFC 9380 declines to even specify try-and-increment "because the goal is to specify algorithms that can plausibly be computed in constant time" [@rfc9380].

So the requirement is now sharp, and it looks almost contradictory. You need a map whose output has unknown discrete log, like try-and-increment, but whose running time is fixed, unlike try-and-increment. You need the safety of the search without the search. For a few years it was not obvious such a thing existed. The story of how the field built it, one property at a time, is the evolution of the primitive itself.

4. Moving Each Property Into the Curve

The next thirteen years read like a chain of defenses in which the defenders keep advancing. Each generation takes one property that used to depend on the implementer's care and locks it into the construction, where it holds by mathematics rather than by discipline. Three of those steps are true property wins. The rest are the engineering that made the winning map cheap enough and general enough to run on every curve real protocols use. Being honest about which is which is the difference between a clean story and a true one.

The first constant-time map: Shallue-van de Woestijne (2006)

The contradiction from the last section -- unknown discrete log without a search -- was resolved in 2006 by Andrew Shallue and Christiaan van de Woestijne. Their map is the "SW" in "SSWU." Given a field element $u$, algebraic identities guarantee that among a small fixed set of candidate $x$-values derived from $u$, at least one is a valid coordinate [@sw06]. So you compute the candidates, test them in a fixed order with a constant number of operations, and select a valid one. There is no rejection loop, which means no data-dependent branch, which means constant time by construction [@sw06] [@rfc9380]. The discrete log stays unknown. For the first time, a single map was simultaneously unknown-DL and constant-time on almost any curve with characteristic other than 2 or 3.

The idea had roots. Schinzel and Skalba had constructed curve points deterministically for a restricted class of curves in 2004, and Skalba generalized it in 2005; Shallue and van de Woestijne further generalized and simplified that line [@ss04] [@s05] [@rfc9380]. Boneh and Franklin's 2001 supersingular map was a deterministic co-origin, but too narrow to be general infrastructure [@bf01]. SvdW survives today in RFC 9380 as the universal fallback for any curve the specialized maps do not cover [@rfc9380].

But SvdW carried a flaw that every deterministic map after it would share, and it is the one no amount of cleverness in a single map can dodge.

The wall every single map hits

RFC 9380 states the obstacle plainly: the deterministic maps "map to some fraction of the points" on the curve, "not the entire curve," which "means that they cannot be used directly to construct a random oracle that outputs points on the curve" [@rfc9380]. A single SvdW map hits only a constant fraction of the points and is statistically distinguishable from uniform. Any proof that models the map as a random oracle -- BLS's unforgeability, an OPRF's pseudorandomness, a password mapping -- does not go through. This is Property 3, and it is missing.

A formal criterion, defined by Maurer, Renner, and Holenstein in 2004, for when a constructed function can safely stand in for an ideal object such as a random oracle inside a security proof. A hash-to-curve construction is "indifferentiable from a random oracle" when no efficient distinguisher can separate it from a true random oracle, even given access to the underlying building blocks [@mrh04].

Before that wall was scaled, the field spent a few years making the map cheaper.

Cheaper maps: Ulas, Icart, Simplified SWU (2007-2010)

Ulas simplified SvdW in 2007 (the "U" in SWU) [@u07]. Icart gave an independent closed-form map in 2009 for fields with $p \equiv 2 \pmod 3$, built on a single cube root [@icart09]. Brier and coauthors published the "Simplified SWU" map in 2010 for fields with $p \equiv 3 \pmod 4$ [@bcimrt10]. Each is a fixed rational formula costing roughly one field exponentiation plus a few multiplications and one inversion -- cheaper and easier to implement in constant time than SvdW's heavier parameterization.

A closed-form rational map from a field element to a short-Weierstrass curve point $y^2 = x^3 + Ax + B$, descended from the Shallue-van de Woestijne map via Ulas and Brier et al. In its base form it applies when $p \equiv 3 \pmod 4$ and $A\cdot B \neq 0$, and costs about one square root plus constant-time conditional selects [@u07] [@bcimrt10] [@rfc9380].

This was progress, but not on Property 3. Cheaper did not mean uniform: each remained a single map hitting a fraction of the curve, still unusable as a random oracle [@rfc9380]. And the modular conditions left gaps. Icart needs $p \equiv 2 \pmod 3$; Simplified SWU needs $p \equiv 3 \pmod 4$; neither covers curves with $A = 0$ such as secp256k1 and BLS12-381. The deeper question was sharper and universal: could you build something provably indifferentiable out of these non-uniform pieces? The answer arrived, remarkably, in the very same 2010 paper that gave Simplified SWU.

The breakthrough: add two maps (2010)

Here is the shift the whole standard turns on. A single deterministic map cannot be a random oracle. But the sum of two independent maps can be. Hash the message to two field elements, map each to a point, and add the points:

$$H(m) = f\big(H_0(m)\big) + f\big(H_1(m)\big).$$

Brier, Coron, Icart, Madore, Randriam, and Tibouchi proved this construction indifferentiable from a random oracle, and it recovers Property 3 while keeping Properties 1 and 2 [@bcimrt10] [@mrh04]. All three properties, at last, guaranteed at once.

Key idea: A single deterministic map can never be a random oracle: it reaches only a fraction of the curve and is distinguishable from uniform. The fix is structural, not a cleverer single map. Hash to two field elements, map each, and add the two points. The sum is indifferentiable from a random oracle. This is exactly why hash_to_curve (the _RO_ suites) costs twice what encode_to_curve (the _NU_ suites) costs: the second map is not waste, it is what buys the distribution [@bcimrt10] [@ffstv13] [@rfc9380].

flowchart TD M["msg and DST"] --> HF["hash_to_field to two elements"] HF --> Q0["map_to_curve of u0 gives Q0"] HF --> Q1["map_to_curve of u1 gives Q1"] Q0 --> ADD["add points: Q0 plus Q1"] Q1 --> ADD ADD --> RO["sum is indifferentiable from a random oracle"] RO --> CC["clear_cofactor"] CC --> P["point in the prime-order subgroup"]

Precision matters here, because it is easy to over-credit. Brier et al. proved the sum-of-two construction indifferentiable specifically for Icart's map. The general result -- that summing two copies of essentially any deterministic map yields a random oracle -- is due to Farashahi, Fouque, Shparlinski, Tibouchi, and Voloch in 2013.Attribute the general theorem to FFSTV13, not to BCIMRT. RFC 9380's Appendix A is careful about this: BCIMRT proved it for Icart's method; FFSTV13 "improve the analysis, showing that it applies to essentially all deterministic mappings" [@rfc9380] [@ffstv13]. After 2010, nothing about Property 3 was left to invent. What remained was coverage: the sum-of-two construction needs a concrete constant-time inner map for your curve family, and two families were still uncovered.

Covering the remaining curves: Elligator 2 (2013) and isogeny SSWU (2019)

The Montgomery and twisted-Edwards curves -- Curve25519, Curve448, and the Edwards forms behind modern signature and OPRF suites -- needed their own map, because SSWU targets short-Weierstrass curves. Elligator 2 supplied it.

An efficient, invertible map from a field element to a point on any curve that has a point of order 2 (Montgomery or twisted-Edwards form), introduced by Bernstein, Hamburg, Krasnova, and Lange in 2013. RFC 9380 uses it for the Curve25519/448 and edwards25519/448 families and the ristretto255/decaf448 groups [@bhkl13] [@rfc9380].

Elligator's origin is a small marvel. It was built for censorship resistance, a way to make a public key look like uniform random bytes so a network censor cannot even tell a key exchange is happening.The elligator.org site records the pivot in its own words: a number of protocols "need a way to map an arbitrary input to an elliptic curve point whose factorisation is unknown ('hashing to an elliptic curve'), such as verifiable random functions (VRFs) and oblivious pseudorandom functions (OPRFs)." A steganography tool became hash-to-curve infrastructure [@elligator-site]. The tool built to hide a key exchange became the constant-time inner map for an entire curve family's hashing.

The last gap was the pairing-friendly curve BLS needs. BLS12-381 has $A = 0$, exactly where Simplified SWU does not apply. In 2019 Riad Wahby and Dan Boneh closed it: map with SSWU onto an isogenous curve where the parameters are admissible, then push the point back to the target curve through a fixed isogeny of small degree [@wb19] [@rfc9380]. The result is constant-time and works in any characteristic, and it is what made constant-time hashing to BLS12-381 practical at blockchain scale. Their headline measurement is the number that ends an old excuse: the constant-time functions run "within 9% of the fastest, non-constant-time alternatives" [@wb19].

Generation	Year	Key idea	Time	What it secured	Status
$H(m)\cdot G$	~2001	scalar-mult the generator	constant	nothing (DL is known)	never safe as a map [@rfc9380]
Try-and-increment	2001-2008	search for a valid coordinate	variable	unknown discrete log	deprecated for secret inputs [@bls01] [@rfc9380]
SvdW	2006	rational parameterization, no loop	constant	constant time by construction	general fallback [@sw06]
Ulas / Icart / Simplified SWU	2007-2010	cheaper closed-form maps	constant	efficiency, per-curve forms	inner maps [@u07] [@icart09] [@bcimrt10]
BCIMRT sum-of-two	2010	add two mapped points	constant	random-oracle distribution	the `_RO_` core [@bcimrt10] [@ffstv13]
Elligator 2	2013	invertible map for order-2 curves	constant	Montgomery/Edwards coverage	active [@bhkl13]
Isogeny SSWU	2019	map via an isogenous curve	constant	$A=0$ pairing-curve coverage	active [@wb19]

Every curve family that deployed protocols use now has a constant-time, unknown-DL inner map, and the sum-of-two construction wraps any of them into a random oracle. All three properties are achievable everywhere. But an implementer still has to assemble the hashing, the map, the cofactor clearing, the domain separation, and the choice of variant, by hand, and any one of those is a place to slip. What packages the whole lineage so you cannot get it wrong?

5. RFC 9380: All Three Properties at Once

In August 2023 the CFRG published RFC 9380, "Hashing to Elliptic Curves," by Armando Faz-Hernandez, Sam Scott, Nick Sullivan, Riad Wahby, and Christopher Wood [@rfc9380]. It invents no new map. It does something more useful: it folds two decades of maps into a single interface an ordinary engineer cannot easily misuse, and it makes every security-relevant choice legible in the name.

The pipeline has three stages [@rfc9380]:

hash_to_field turns the input and a domain tag into one or more field elements, using expand_message_xmd for fixed-output hashes like SHA-256 and expand_message_xof for extendable-output functions like SHAKE.
map_to_curve sends each field element to a curve point using the map that fits the curve: Simplified SWU for short-Weierstrass curves, isogeny-SSWU for the $A = 0$ pairing curves, Elligator 2 for Montgomery and Edwards curves, and SvdW as the general fallback.
clear_cofactor forces the result into the prime-order subgroup.

flowchart TD IN["input msg and DST"] --> HF["hash_to_field"] HF --> BR{"which variant"} BR -->|"_RO_ hash_to_curve"| TWO["two field elements, two maps, add"] BR -->|"_NU_ encode_to_curve"| ONE["one field element, one map"] TWO --> CC["clear_cofactor"] ONE --> CC CC --> OUT["point in the prime-order subgroup"]

The two-element margin is a proven bound

The first stage hides a subtlety worth pausing on. Reducing a uniformly random integer modulo $p$ is not exactly uniform, because the top of the range wraps around. RFC 9380 fixes this by oversampling.

The first pipeline stage: expand the input and the domain tag into field elements. It draws $L = \lceil(\lceil\log_2 p\rceil + k)/8\rceil$ bytes per element and reduces modulo $p$, so each element is within statistical distance $2^{-k}$ of uniform. The standard suites set $k = 128$, giving a $2^{-128}$ margin [@rfc9380].

That $2^{-128}$ is a proven statistical bound, not a hopeful heuristic, and it is exactly why the byte-length formula is what it is [@rfc9380].

The variant is in the name

The choice between a uniform, proof-usable point and a cheaper nonuniform one is encoded directly in the suite name. hash_to_curve, the _RO_ family, runs the two-element sum-of-two construction and is indifferentiable from a random oracle. encode_to_curve, the _NU_ family, runs a single map at about half the cost and produces a nonuniform distribution [@rfc9380]. The trailing tag is not decoration; it tells you whether the output is safe to feed a proof that assumes a random oracle.

RFC 9380 suite identifiers follow the pattern CURVE_XMD:HASH_MAP_VARIANT_. Once you can read one, you can read them all.

Field	In `BLS12381G2_XMD:SHA-256_SSWU_RO_`	What it fixes
Curve / group	`BLS12381G2`	the target group: BLS12-381, subgroup G2
Expander	`XMD`	`expand_message_xmd` (a fixed-output hash)
Hash	`SHA-256`	the underlying hash function
Inner map	`SSWU`	Simplified SWU (isogeny variant here, since $A=0$)
Variant	`RO`	`_RO_`: uniform, indifferentiable from a random oracle

Read edwards25519_XMD:SHA-512_ELL2_RO_ the same way and it decodes itself: the edwards25519 group, XMD expansion over SHA-512, the Elligator 2 map, uniform variant [@rfc9380]. The name is the spec.

{` // Decompose an RFC 9380 suite ID: CURVE_EXPANDER:HASH_MAP_VARIANT_ function parseSuite(id) { const [left, right] = id.split(":"); const leftParts = left.split(""); const expander = leftParts.pop(); // XMD or XOF const curve = leftParts.join(""); // e.g. BLS12381G2, edwards25519 const rp = right.split("").filter(function (s) { return s.length > 0; }); const hash = rp[0]; // SHA-256, SHA-512, SHAKE256 const variant = rp[rp.length - 1]; // RO or NU const map = rp.slice(1, rp.length - 1).join(""); // SSWU, ELL2, SVDW return { curve: curve, expander: expander, hash: hash, map: map, variant: variant, uniform: variant === "RO" ? "uniform (random oracle)" : "nonuniform" }; }

["BLS12381G2_XMD:SHA-256_SSWU_RO_", "edwards25519_XMD:SHA-512_ELL2_RO_", "P256_XMD:SHA-256_SSWU_NU_"].forEach(function (id) { console.log(id); console.log(" ", JSON.stringify(parseSuite(id))); }); `}

The two steps you must not skip

Two pipeline stages are easy to forget and dangerous to omit. The first is the domain tag.

A byte string, unique to a protocol and its version, mixed into `hash_to_field` so the same input maps to different points in different protocols. RFC 9380 makes it mandatory; DSTs longer than 255 bytes are themselves hashed before use. Without a unique DST, two protocols that share a curve can be driven to collide [@rfc9380].

The second is cofactor clearing, the final stage that lands the point where the group arithmetic is safe.

The final pipeline stage: multiply the mapped point (or apply a faster endomorphism-based equivalent) by the curve's cofactor to force it into the prime-order subgroup, closing off small-subgroup attacks. edwards25519 has cofactor 8; BLS12-381's G1 and G2 have large cofactors with fast clearing methods [@rfc9380].

Note: The everyday act is now tiny: name a suite. The suite ID fixes the curve, the expander, the hash, the inner map, and the distribution variant, and a vetted library does the rest. You are not choosing a construction. You are declaring your curve and your distribution need, and RFC 9380 has already made the safe choice for each [@rfc9380].

Step back and the three properties resolve into one sentence. The mapped point had to be a stranger -- its discrete log unknown, or forgery follows. It had to arrive on time -- in work independent of the input, or the clock leaks the secret. And it had to look the part -- drawn from a distribution the proof can treat as a random oracle, or the proof does not hold.

The point had to be a stranger, arrive on time, and look the part. RFC 9380 is the standard that guarantees all three, and encodes which ones you asked for in a single suite name.

That framing also closes the loop this article opened. WPA3's answer to Dragonblood is Hash-to-Element, or H2E.

After Dragonblood, WPA3-Personal replaced hunt-and-peck with H2E, a constant-time, SSWU-based derivation of the SAE password element, and the Wi-Fi standard was updated to compute the password element "in constant time" [@dragonblood-site]. RFC 9380 supplies the governing principle: a constant-time map is required when the input is secret [@rfc9380]. The hostap and w1.fi advisories track the corresponding constant-time SAE patches shipped to real deployments [@w1fi-security]. The precise IEEE 802.11 clause is not reproduced here; the point is that the fix is exactly the constant-time approach this standard consolidates.

The doorway is finally built to spec. The natural next question is who is actually walking through it, because the answer is: far more of your daily software than you would guess.

6. Who Quietly Depends on This Today

You have almost certainly relied on hash-to-curve this week without noticing. It sits under signatures that finalize blockchains, under the private authentication that hides your browsing from a token issuer, under the password login protocol that never sees your password, and under WPA3. None of these advertise the primitive. All of them break if it is wrong.

flowchart TD BLS["BLS signatures on Ethereum"] --> H2C["RFC 9380 hash-to-curve"] OPRF["OPRF and VOPRF (RFC 9497)"] -->|"one HashToGroup call"| H2C OPAQUE["OPAQUE aPAKE (RFC 9807)"] -->|"indirect"| OPRF PP["Privacy Pass (RFC 9578)"] --> OPRF CPace["CPace PAKE (draft)"] --> H2C SAE["WPA3-Personal SAE"] -->|"H2E"| H2C

BLS signatures and Ethereum consensus

The highest-volume deployment, by signature-verification throughput, is BLS. Every BLS signature hashes its message to a point in G2 and scales it by the secret key, so hash_to_point is not an accessory but the heart of the scheme [@draft-bls-signature-07]. Ethereum's consensus specification fixes this for validator signatures: it adopts the suite BLS12381G2_XMD:SHA-256_SSWU_RO_ -- the isogeny-SSWU map wrapped in the _RO_ construction -- so every consensus client hashes exactly this way [@eth-consensus-specs] [@draft-bls-signature-07] [@rfc9380]. The _RO_ variant is not optional here: the unforgeability proof models the map as a random oracle, so a nonuniform _NU_ map would void the guarantee. Notably, the scheme the entire Ethereum validator set relies on is still specified only by an Internet-Draft, which the consensus spec references directly [@eth-consensus-specs] [@draft-bls-signature-07].Unlike ECDSA, BLS is deterministic and uses no per-signature nonce, so it sidesteps the nonce-reuse failures that have repeatedly broken ECDSA deployments (Part 8). Its one hash-to-curve call becomes the security-critical primitive in place of the nonce [@draft-bls-signature-07].

OPRFs, and everything built on them

The second large consumer is the oblivious pseudorandom function and its verifiable and partially-oblivious variants, standardized in RFC 9497 [@rfc9497].

A two-party protocol in which a client learns $F(k, x)$ for its input $x$ and the server's key $k$, while the server learns neither $x$ nor the result. The client's first step hashes $x$ to a curve point and blinds it; that single `HashToGroup` call is the protocol's entire hash-to-curve surface [@rfc9497].

The dependency is remarkably concentrated. The client's Blind(input) computes HashToGroup(input) and then blinds the point; every other message is scalar arithmetic and proofs. So the whole hash-to-curve exposure of an OPRF is one call, instantiated with Elligator 2 for ristretto255 and SSWU for the P-256, P-384, and P-521 suites [@rfc9497].

Note: For an OPRF, the entire hash-to-curve attack surface is the single HashToGroup call in the client's Blind step. Get that one call right -- correct suite, correct DST, identity element rejected on the wire -- and the primitive is handled. Get it wrong and obliviousness or correctness collapses [@rfc9497].

Because OPRFs are a building block, their hash-to-curve dependency propagates. OPAQUE, the augmented PAKE standardized as RFC 9807 in July 2025, lets a server authenticate a user by password without ever learning the password, and it does so by running an OPRF; its hash-to-curve dependency is indirect but real, flowing through RFC 9497 [@rfc9807] [@rfc9497]. Privacy Pass, standardized across RFC 9576, RFC 9577, and RFC 9578 in June 2024, issues anonymous authentication tokens; its privately verifiable issuance is "based on the Oblivious Pseudorandom Function," with token type 0x0001 being a VOPRF over P-384, which is the SSWU path [@rfc9578] [@rfc9576] [@rfc9577].

PAKEs and Wi-Fi

Two more consumers map a secret rather than a public message. CPace, a balanced PAKE still in CFRG draft with datatracker status "Waiting for IRTF Chair," maps the password to a session generator using SSWU or Elligator 2 depending on the group [@draft-cpace]. And WPA3-Personal's SAE now derives its password element with the constant-time H2E map, the fix that closed Dragonblood [@dragonblood-site].

The whole deployed picture fits in one adoption map.

Consumer	Where hash-to-curve is called	Suite / map	Standard status
BLS / Ethereum consensus	`hash_to_point(msg)` into G2	`BLS12381G2_XMD:SHA-256_SSWU_RO_` [@draft-bls-signature-07]	Internet-Draft [@draft-bls-signature-07]
OPRF / VOPRF / POPRF	`Blind` calls `HashToGroup`	ristretto255 to Elligator 2; P-curves to SSWU [@rfc9497]	RFC 9497 (2023) [@rfc9497]
OPAQUE (aPAKE)	indirect, via its OPRF	inherits the OPRF suite [@rfc9807]	RFC 9807 (2025) [@rfc9807]
Privacy Pass	VOPRF token issuance	P-384 VOPRF to SSWU [@rfc9578]	RFC 9576/9577/9578 (2024) [@rfc9578]
CPace (balanced PAKE)	password to session generator	SSWU or Elligator 2 by group [@draft-cpace]	draft, "Waiting for IRTF Chair" [@draft-cpace]
WPA3-Personal (SAE)	password element (PWE)	H2E, constant-time SSWU [@dragonblood-site]	IEEE 802.11

What actually ships

Under all of this sit a few load-bearing libraries. The blst library implements BLS12-381 hash-to-curve in C and assembly, is compliant with RFC 9380, was audited by NCC Group in January 2021, and is the subject of an ongoing Galois formal-verification effort [@blst] [@blst-verification]. Cloudflare's CIRCL provides RFC 9380 hash-to-curve and RFC 9497 OPRFs in Go, though it labels itself experimental and cautions against production use of parts of it [@circl]. In Rust, curve25519-dalek exposes an Elligator-based one-way map through RistrettoPoint::from_uniform_bytes [@curve25519-dalek].

The headline is quiet by design: the primitive is standardized and load-bearing under a stack of shipping protocols, and almost nobody who depends on it has to think about it. That is what a well-built doorway looks like. Which raises a fair question: if every consumer just names a suite, is there ever a real choice to make, or has the standard decided everything for you?

7. The Decision Matrix

There is no "best" hash-to-curve, and that is a feature. Almost every knob is set for you by something structural: the curve you already committed to, or the distribution your proof already assumes. The value of a field guide is naming which axis governs which choice, and where a wrong turn is a vulnerability rather than a mere preference.

Distribution need decides the variant

The _RO_ versus _NU_ choice is governed by one question: does your proof need a random oracle? For BLS, OPRFs, and password mapping, it does, so _RO_ is the default. The _NU_ variant is an optimization you reach for only with a specific proof that non-uniformity is acceptable, because its output is measurably not uniform.

Dimension	`hash_to_curve` (`_RO_`)	`encode_to_curve` (`_NU_`)
Field elements and maps	2 elements, 2 maps, 1 addition	1 element, 1 map
Relative cost	about twice `_NU_`	baseline, about half of `_RO_`
Output distribution	indifferentiable from a random oracle [@rfc9380]	nonuniform: at least one eighth of G, weights vary by up to a factor of four [@rfc9380]
Proof compatibility	usable where a proof assumes a random oracle	only where non-uniformity is provably sufficient
Decision rule	default for BLS, OPRF, PAKE mapping	optimization only, with a proof

Getting this backward is a shippable misuse: a _NU_ map where the proof assumed _RO_ produces a point from a distribution the proof never agreed to, which is the third of our three failures made concrete [@rfc9380].

Curve family decides the map

The choice among the inner maps is not a matter of taste at all. It is fixed by the shape of your curve.

flowchart TD Q{"what curve do you have"} Q -->|"short Weierstrass, p is 3 mod 4"| SSWU["Simplified SWU"] Q -->|"A is zero: secp256k1, BLS12-381"| ISO["Isogeny SSWU"] Q -->|"Montgomery or Edwards"| ELL["Elligator 2"] Q -->|"none of the above"| SVDW["SvdW fallback"]

Map	Curve condition	Curves in RFC 9380	Dominant cost
Simplified SWU	short-Weierstrass, $p \equiv 3 \pmod 4$, $AB \neq 0$	P-256, P-384, P-521	about one square root plus selects
Isogeny SSWU	$A = 0$ Weierstrass	secp256k1, BLS12-381 G1/G2	SSWU on $E'$ plus one isogeny evaluation
Elligator 2	curve with a point of order 2	curve25519/448, edwards25519/448, ristretto255/decaf448	about one exponentiation
SvdW	any curve, characteristic other than 2 or 3	fallback when none of the above fit	a few exponentiations and inversions

Note: If you find yourself deliberating between SSWU and Elligator 2, stop: your curve has already decided. SSWU serves short-Weierstrass curves, isogeny-SSWU serves the $A=0$ pairing curves, and Elligator 2 serves Montgomery and Edwards curves. The only choice genuinely left to you is the variant, _RO_ or _NU_, and the default is _RO_ [@rfc9380].

The two knobs that are real, but small

Two remaining choices are genuine but low-stakes. The expander, expand_message_xmd versus expand_message_xof, follows your hash family: XMD for SHA-2, XOF for SHAKE, and neither dominates on security, so you pick the hash you already have [@rfc9380]. And within BLS, you can hash to either pairing group.

BLS can hash to either pairing group. Hashing to G2 is more expensive, because G2 lives over the larger field $\mathbb{F}_{p^2}$ and has a larger cofactor, but the minimal-pubkey-size setting Ethereum uses signs in G2. Minimal-signature-size deployments hash to the cheaper G1 instead. This is a real cost-versus-size trade-off, not a security decision, and it is why fast G2 hashing has its own literature [@rfc9380] [@sbcdk09].

The number that ends an old argument

For years, the excuse for variable-time hunt-and-peck was that constant-time maps were too slow. Wahby and Boneh's nine-percent measurement retired it: constant time is essentially free here, and simpler to implement correctly, which is why RFC 9380 can require it without asking anyone to pay for the safety [@wb19].

It is worth remembering how strange this matrix would look to a cryptographer of 1995. In a finite field, hashing into the group is a single modular reduction with no decision matrix at all [@miller85]. Elliptic curves bought hard discrete logs and small keys, and the bill came due as this exact table: a real algorithm, with real parameters, that you must get right. Two maps, an oversampling margin, a distribution that is deliberately "almost uniform": none of it is arbitrary. The next section proves they are the right choices, not just good ones.

8. Why Two Maps, and How Uniform Is "Uniform"

The two-map construction can feel like a clever hack. It is not. It is the provable optimum, and the theory that says so also explains the oversampling margin and the one caveat you must respect.

The lower bound that forces two maps

Start with what a single map cannot do. No efficient deterministic map to a general elliptic curve is both surjective and uniform. Its image is only a constant fraction of the curve, with some points weighted more heavily than others. RFC 9380 quantifies the residual for the single-map case exactly: the output distribution "includes at least one eighth of the points in G," and the probability of points "varies by at most a factor of four" [@rfc9380]. Those bounds descend from the analyses of the individual maps [@sw06] [@bhkl13] [@ft12]. A distribution that misses seven-eighths of the group in the worst case and re-weights the rest simply cannot be indifferentiable from a uniform random oracle. One map is not enough, and this is why.

The matching upper bound

Now the other side. Hashing to two field elements, mapping each, and adding the points is indifferentiable from a random oracle, proven for Icart's map by Brier et al. and generalized to essentially all maps by Farashahi et al. [@bcimrt10] [@ffstv13] [@mrh04]. The lower bound says one map cannot suffice; the upper bound says two do. The gap is closed. The _RO_ construction is the tight, achievable answer to "produce a uniform, proof-usable point," and RFC 9380 standardizes precisely that optimum, no more and no less [@rfc9380].

Why the oversampling margin is what it is

The same "prove it, do not hope it" discipline governs hash_to_field. Reducing a uniform $L$-byte integer modulo $p$ leaves a small bias from the wrap-around at the top of the range. Oversampling by $k$ bits, with

$$L = \left\lceil \frac{\lceil \log_2 p \rceil + k}{8} \right\rceil,$$

drives the statistical distance from uniform below $2^{-k}$. RFC 9380 fixes $k = 128$, so every field element is within $2^{-128}$ of uniform [@rfc9380]. That is a proven bound, which is why truncating the byte length is not a harmless optimization but a real weakening of the margin.

The one caveat that survives all of this

Here the humility arrives. "Indifferentiable from a random oracle" does not mean "safe to drop into any random-oracle proof."

RFC 9380 cites Ristenpart, Shacham, and Shrimpton for the sharpest limit on the whole approach: "not all security proofs that rely on random oracles continue to hold when those oracles are replaced by indifferentiable functionalities" [@rfc9380]. So `_RO_` is the right default, but a protocol's proof still has to be the composable kind that survives the substitution. Indifferentiability is a strong guarantee, not an unconditional one.

There is a smaller but instructive caveat in the same spirit. Either encoding can, with probability roughly $1/r$ for a random input, output the identity element.That probability is negligible and it is infeasible to find such an input deliberately, so RFC 9380 says protocols "SHOULD NOT add a special case to detect and 'fix' the identity element." The special case is itself a bug surface, more likely to introduce a flaw than to prevent one [@rfc9380]. The right move is to do nothing special, which is counterintuitive enough that people get it wrong by trying too hard.

Note: For classical elliptic curves the core problem is solved in the strongest sense available: a single map provably cannot be a uniform random oracle, the two-map sum provably is, and RFC 9380 standardizes exactly that optimum. What is left is not the classical mathematics. It is implementation assurance and the post-quantum question [@rfc9380] [@ffstv13].

One boundary is worth stating precisely, because it sets up everything still open. The "unknown discrete log" property adds no new hardness assumption: it inherits the elliptic-curve discrete-log hardness of the target group, the same assumption Part 15 examined [@rfc9380]. And so, like all elliptic-curve cryptography, it falls to Shor's algorithm on a fault-tolerant quantum computer. Post-quantum signatures sidestep the primitive entirely, because they use no curve. But the consumers that specifically need a point of unknown discrete log -- OPRFs and VRFs -- have no such escape. That is where the frontier actually is.

9. Where It Is Still Moving

A solved primitive with live frontiers sounds like a contradiction, but hash-to-curve is exactly that. The classical mathematics is settled; the engineering, the assurance, and the post-quantum future are not.

Constant time, all the way down

RFC 9380 guarantees constant time at the interface: no data-dependent loop. The guarantee has to hold much further down, though, through the field primitives the map calls -- the square root, the sign function sgn0, the zero-guarded inversion inv0, general inversion, and the conditional selects -- each of which can leak through timing, cache, or micro-architecture if written naively [@rfc9380]. And the map runs on secrets: passwords in SAE and CPace, blinded inputs in OPRFs. A leak in one field routine re-opens the exact class of attack Dragonblood exploited.

Note: Constant time must be structural in the map and then verified down to the field primitives, not patched in after the fact. Dragonblood's second act (Section 1) is the standing proof: fixing timing curve by curve is how you get burned twice [@rfc9380] [@dragonblood-site].

The expensive curves

Hashing to G2 of BLS12-381, over the field $\mathbb{F}_{p^2}$ and with a large cofactor, is markedly costlier than hashing to G1. Faster maps and faster cofactor clearing are open engineering targets, and they matter because Ethereum verifies huge volumes of signatures, so every millisecond of G2 hashing multiplies across the network. Wahby and Boneh brought constant-time hashing within nine percent of variable-time, and the fast-G2 cofactor-clearing line descends from work like Scott and coauthors' "Fast Hashing to G2," but G2 remains the expensive path, and each new pairing-friendly curve keeps the problem alive [@wb19] [@sbcdk09].

Machine-checked implementations

Because constant time is hard to get right, the field increasingly wants implementations proven correct by machine, not just audited by eye. The leading edge is visible in blst, the highest-volume hash-to-G2 implementation: it was audited by NCC Group in January 2021, and its formal verification by Galois is, in the project's own words, ongoing [@blst] [@blst-verification]. That is the honest status: verification of a deployed hash-to-curve path is in progress, not finished. Full end-to-end machine-checked hash-to-curve -- map, cofactor clearing, and constant time, across curve families -- remains open.

The genuinely open frontier: post-quantum

The deepest gap is post-quantum. Signatures have a post-quantum future without curves, so they abandon hash-to-curve. The unknown-DL consumers do not have that luxury. OPRFs and VRFs -- and therefore OPAQUE, Privacy Pass, and anonymous-credential systems built on them -- rest on the hardness of the elliptic-curve discrete log, and a quantum adversary breaks that foundation.Lattice- and isogeny-based OPRF and VRF constructions exist in the research literature, but none is competitive with the elliptic-curve versions in bandwidth or round complexity, and none is standardized. This guide states the frontier without pinning a specific paper, holding to the same citation standard as the rest of the series. There is no drop-in "post-quantum hash-to-curve," because the whole unknown-DL abstraction has to be rebuilt on different assumptions, and the competitive replacement does not yet exist.

Steady-state engineering

Finally, the everyday work: as deployments adopt new pairing-friendly curves (BLS12-377 and BW6 are recent examples) and new prime-order abstractions, each needs its admissible map and cofactor-clearing constants worked out and folded into the suite registry [@rfc9380]. This keeps the "which map for which curve" table a living document rather than a finished one. Given all of it, the practical question remains: what should you actually do on Monday?

10. The Decision Rules, Made Operational

Here is the spine turned into something you can apply to a code review this afternoon. The rules are short because the standard did the hard part; your job is to name the right suite and not undo its work.

Use a vetted suite, never a hand-rolled map. Always call a RFC 9380 suite from a constant-time library for your curve. Never compute $H(m)\cdot G$, and never write your own map. The two most catastrophic errors in this whole area are the two shortcuts from Section 3 [@rfc9380].

Default to _RO_. Use hash_to_curve (_RO_) unless you hold a specific proof that non-uniformity is acceptable, in which case encode_to_curve (_NU_) halves the cost [@rfc9380].

Always set a unique DST. Make the domain-separation tag specific to your protocol and version, hash it if it exceeds 255 bytes, and never share one across protocols. This is domain separation, the same discipline Part 13 develops for keys [@rfc9380].

Map by curve, not by taste. Short-Weierstrass with $p \equiv 3 \pmod 4$ uses SSWU; $A = 0$ uses isogeny-SSWU; Montgomery and Edwards use Elligator 2; anything else uses SvdW [@rfc9380].

Then the per-protocol specifics:

BLS: use BLS12381G2_XMD:SHA-256_SSWU_RO_ for minimal-pubkey-size, or the G1 suite for minimal-signature-size; _RO_ is required for the unforgeability proof; clear the cofactor [@draft-bls-signature-07].
OPRF, VOPRF, OPAQUE: call RFC 9497's HashToGroup and HashToScalar at the ciphersuite's suite; do not substitute your own map; reject the identity element on the wire [@rfc9497].
PAKE mapping a password (SAE, CPace): use a constant-time map only, never hunt-and-peck a secret, and pre-hash the password with a slow KDF such as PBKDF2, scrypt, or Argon2 before mapping, so an adversary who sees an intermediate value still faces a slow dictionary attack [@rfc9380]. Part 12's password-entropy argument is exactly why this matters.

Key idea: Pick the suite for your curve, default to _RO_, set a unique DST, and clear the cofactor. Four decisions, each with a safe default, and RFC 9380 has already made three of them for you the moment you name the suite [@rfc9380].

The mirror image of the rules is the list of things that never belong in a diff. Each is a real, shippable bug that maps to exactly one of the three properties, or to the two guardrails around them.

Misuse	What it violates	The fix
$P = H(m)\cdot G$ instead of a map	Unknown discrete log	use a real RFC 9380 map [@rfc9380]
Hunt-and-peck over a secret	Constant time	constant-time suite; H2E for SAE [@rfc9380] [@dragonblood-site]
`_NU_` where the proof needs `_RO_`	Random-oracle distribution	default to `_RO_` [@rfc9380]
Missing or shared DST	Domain separation	unique per-protocol, per-version DST [@rfc9380]
Skipped cofactor clearing	Subgroup safety	clear the cofactor; check the subgroup [@rfc9380]
Truncated `hash_to_field` output	Uniformity margin	use the full $L$ bytes [@rfc9380]
Raw password without a slow KDF	Offline-guessing resistance	PBKDF2, scrypt, or Argon2 first [@rfc9380]

Note: Vetted RFC 9380 suite for the curve. _RO_ unless a proof licenses _NU_. Unique, versioned DST, hashed if over 255 bytes. Cofactor cleared and subgroup confirmed. Full L-byte hash_to_field. For secrets, a constant-time map and a slow KDF first. For OPRFs, identity rejected on the wire. Anything else is a finding [@rfc9380] [@rfc9497].

RFC 9380 ships official test vectors for every suite. Before you trust an implementation, feed it the standard's sample inputs and DSTs and confirm the output points match byte for byte. A library that reproduces the vectors implements the pipeline correctly; one that does not should never touch a secret [@rfc9380].

A checklist answers "what to do." The last thing to handle is the set of "but why can't I just..." questions that every reviewer and implementer keeps asking, because the answers are where the understanding finally sets.

11. FAQ and Common Misuse

Because its discrete log is $H_n(m)$, which is public, so the point is not a stranger to anyone. In BLS this is fatal: a signature $[sk]\cdot H(m)$ becomes $[H_n(m)]\cdot PK$, which anyone computes from the public message and public key with no secret key. The same known-discrete-log flaw breaks OPRF obliviousness and a PAKE's password element [@rfc9380] [@bls01]. Only when the input is public and you need neither constant time nor a random-oracle distribution. Over a secret input the loop count is a function of the secret, so the running time leaks it. That is precisely the Dragonblood attack that recovered WPA3 passwords, and it is why RFC 9380 declines to specify the method [@rfc9380] [@vr20]. Yes. The `_NU_` output is provably not a random oracle: it covers at least one eighth of the group with weights varying by up to a factor of four [@rfc9380]. If your proof assumes a random oracle -- as the BLS, OPRF, and PAKE proofs do -- you need `_RO_`. Use `_NU_` only with a specific proof that non-uniformity is acceptable [@rfc9380]. Always. The DST is domain separation, not decoration: without a unique, protocol-and-version-specific tag, two protocols sharing a curve can be driven to collide. RFC 9380 makes it mandatory and hashes tags longer than 255 bytes [@rfc9380]. You don't; the curve decides. Curve25519 and edwards25519 use Elligator 2, because they have a point of order 2. BLS12-381 uses isogeny-SSWU, because $A = 0$. The map is a structural consequence of the curve, not a preference [@rfc9380]. No. It is bound to elliptic-curve cryptography and falls to Shor's algorithm. Post-quantum signatures avoid the primitive entirely because they use no curve, but the consumers that need a point of unknown discrete log -- OPRFs and VRFs, and the systems built on them -- have no settled, efficient post-quantum replacement yet [@rfc9380]. No. `encode_to_curve` (`_NU_`) runs one map and produces a nonuniform point at about half the cost. `hash_to_curve` (`_RO_`) hashes to two field elements, maps each, and adds the points, which is indifferentiable from a random oracle. The extra map is what buys the distribution [@rfc9380].

The Point Had to Be a Stranger, Arrive on Time, and Look the Part

Look back at the failures with the whole picture in hand, and they line up with eerie precision. Each was a wrong answer to exactly one of the three questions. Computing $H(m)\cdot G$ published the discrete log: the point was not a stranger, and universal forgery followed [@rfc9380] [@bls01]. Hunt-and-peck leaked the password through the clock: the point did not arrive on time, and Dragonblood read it off the handshake [@vr20]. Reaching for _NU_ where a proof needs _RO_ handed the proof a distribution it never agreed to: the point did not look the part [@rfc9380]. Three questions, three ways to fail, three real systems that failed them.

That is the sibling claim to the one Part 15 made about the curve itself. The elliptic-curve arithmetic was sound; the danger was the soft gap around it. Here the gap has a name and a shape. It is the doorway, the single step that carries an untrusted string into the group, and getting it right means answering all three questions at once: unknown discrete log, constant time, and a proof-usable distribution. RFC 9380 is the standard that guarantees all three and encodes which ones you asked for in a suite name you can read at a glance.

For classical curves, the doorway is finally built to spec. The two-map construction is the provable optimum, the oversampling margin is a proven bound, and a handful of audited libraries carry the whole load quietly under BLS, OPRFs, OPAQUE, Privacy Pass, and WPA3. The open frontier has moved elsewhere: to machine-checked implementations of what already ships, to the stubbornly expensive pairing curves, and above all to a post-quantum world where the unknown-DL consumers have no settled replacement.

So the next time you call a one-line hash-to-curve API, you will know to ask the three questions it answers for you. Do you know the point's discrete log? Does your running time depend on the input? Can your proof model the output as a random oracle? For any construction worth shipping, the answers are the same three words this whole field spent two decades earning: no, no, yes.