Parag Mali - tag: oprf

The Server Helped, and Never Saw: A Field Guide to Oblivious Pseudorandom Functions

noreply@paragmali.com (Parag Mali) — Mon, 13 Jul 2026 10:23:11 GMT

**An oblivious pseudorandom function (OPRF) lets a server apply its secret key to your secret input so that it learns neither the input nor the output.** That single move is the engine under OPAQUE logins, Privacy Pass tokens, and private password-breach checks [@rfc9497]. The trick is David Chaum's 1982 blinding transplanted from RSA into a Diffie-Hellman group [@chaum82]: hash your input to a curve point, multiply by a fresh random blind, let the server multiply by its key, then divide the blind back out. RFC 9497 (2023) pins this down as three modes -- OPRF, VOPRF, and POPRF -- that answer three questions: is it blind, which key produced the answer, and how many times can one key be asked before it bleeds out [@rfc9497]. This is the field guide to that engine: every generation that built it, every real break that shaped it, and every way it still gets misused in production code.

1. The Server Hardened Your Password Without Ever Seeing It

You want to make a stolen password database worthless. The standard defense is to key every stored password with a secret the attacker cannot exfiltrate -- a "pepper" that lives only in your server's memory -- so a dumped hash is uncrackable without also breaking the keyholder. This is the logic behind server-assisted password hardening, and it is exactly what OPAQUE was designed to formalize [@opaque-paper].

But look closely at the obvious way to apply that key. To hash a password under the pepper, the server has to be handed the password. That is the one thing you were trying not to do. The service that hardens your secret must first be shown your secret. It feels like a law of nature: to key a value, you have to see the value.

It is not a law of nature. Here is the whole resolution, and it fits in four lines.

The client hashes its password to a point on an elliptic curve, $P = H(pw)$. It picks a fresh uniformly random scalar $r$ and sends not $P$ but $r \cdot P$, a uniformly random point. The server multiplies by its secret key: $k \cdot (r \cdot P)$. The client divides the blind back out to get $k \cdot P$, and hashes that: $F(k, pw) = H_2(pw,, k \cdot H(pw))$.

Now state exactly what the server saw. It saw $r \cdot P$: a uniformly random point on the curve, and nothing else. It never saw the password. It never saw the output. It applied its key to a value it could not read, and handed back a value it could not read either.

A two-party protocol that computes $F(k, x)$ where the server holds the key $k$, the client holds the input $x$, and when the protocol finishes the server has learned neither $x$ nor the output, while the client has learned only $F(k, x)$ and nothing about $k$ [@rfc9497]. A keyed function $F(k, x)$ whose outputs are indistinguishable from those of a truly random function to anyone who does not hold $k$. It is the "keyed lock": only the keyholder can compute it, and its outputs reveal nothing about the key [@rfc9497]. The fresh, uniformly random scalar $r$ that the client multiplies into $H(x)$ before sending it. Because $r$ is uniform and independent of the input, the transmitted point $r \cdot H(x)$ is itself uniform and carries no information about $x$ [@rfc9497]. sequenceDiagram participant C as Client (holds input x) participant S as Server (holds key k) Note over C: P holds HashToGroup(x) Note over C: pick fresh random blind r Note over C: blindedElement holds r times P C->>S: send blindedElement, a uniform random point Note over S: evaluatedElement holds k times blindedElement S->>C: return evaluatedElement Note over C: divide out r to recover k times P Note over C: output holds Hash of x with that point

Key idea: The oblivious PRF applies a secret key to a secret input so that neither party learns the other's secret. Everything else in this guide is a variation on that one move, or a story about what happens when one half of it is done wrong.

That two-line trick is not a party piece. The same two lines are how Privacy Pass hands you a token that a server can validate but cannot link back to you [@dgstv18]; how Google's Password Checkup tells you a credential appears in a breach corpus without Google learning the credential [@thomas19]; and how two organizations compute the intersection of their customer lists without either revealing its list [@fipr05]. Replace "the component that used to have to see the secret" with a blind, verifiable, rate-limited oracle that does not, and you have described every one of these systems at once.

Because the move is always the same, you can interrogate any deployment with the same three questions. Is it blind? Does the server ever see the input, or link two evaluations of it? Which key? Can the client prove the answer was produced by the one key the server committed to? How many asks? How many blind evaluations can one key answer before an attacker can reconstruct it? Hold onto those three questions. They are the spine of this article, and by the end you will see that every named failure in the primitive's history is one of them answered wrong.

The 2HashDH shape $F(k, x) = H_2(x,, H_1(x)^k)$ we just wrote by hand is the actual construction that ships today [@jkk14]. If it feels like Diffie-Hellman run one-sided, that is exactly right: Part 18 argued that nobody has broken the discrete logarithm, and this is its constructive twin -- the same group structure, run so that a server applies a secret rather than agreeing on one. If you are wondering why we harden passwords at all, Part 12 is the prerequisite. Here we take the hardening as given and ask how a server can perform it blind.

{` // STRUCTURAL MODEL, NOT REAL CRYPTO. It shows only the SHAPE of blind/evaluate/unblind. // Model an elliptic-curve group of prime order q: a "point" is an integer mod q, // and "scalar multiplication" scalar*point is multiplication mod q. BigInt avoids overflow. const q = 2147483647n; // a prime group order (toy) const mod = (a) => ((a % q) + q) % q; const scalarMul = (s, point) => mod(s * point); function invScalar(a) { // inverse of a scalar mod q (q prime), via Fermat let r = 1n, b = mod(a), e = q - 2n; while (e > 0n) { if (e & 1n) r = mod(r * b); b = mod(b * b); e >>= 1n; } return r; }

const k = 1337n; // SERVER secret key (client never learns it) const Hx = 991n; // H(x): the hashed input, as a group element const r = 42424243n; // CLIENT fresh random blind

const blinded = scalarMul(r, Hx); // client SENDS rH(x): looks uniformly random const evaluated = scalarMul(k, blinded); // server returns k(rH(x)) const unblinded = scalarMul(invScalar(r), evaluated); // client removes r: recovers kH(x) const direct = scalarMul(k, Hx); // what F would be if the server had seen x

console.log('server saw = ' + blinded.toString() + ' (independent of H(x)=' + Hx.toString() + ')'); console.log('client recovered = ' + unblinded.toString()); console.log('equals direct k*H(x) = ' + (unblinded === direct)); `}

That trick is forty years old, and for its first two decades it did not even have a name. To understand why it is secure, and why there turned out to be three versions of it, we have to start where the blinding started: in 1982, with digital cash.

2. Blinding, Before It Had a Name

The move is older than the problem it now solves. In 1982, David Chaum wanted untraceable digital cash: a way for a bank to sign a coin without learning which coin it signed, so the coin could later be spent without the bank linking it back to the withdrawal. His solution was blinding [@chaum82]. The client multiplies its message by a random factor, the bank signs the blinded message under its RSA key, and the client divides the factor out to recover a valid signature on the original. Blind, let the keyholder act, unblind. Structurally, that is the exact template an OPRF runs on.Chaum's 1982 construction used multiplicative blinding in an RSA group, and its output was a publicly verifiable signature. The OPRF performs the same blind-act-unblind dance in a Diffie-Hellman group, and its output is a pseudorandom value only the querier can read. Part 14 covers the RSA lineage in full.

So if the trick existed in 1982, why did the OPRF take until 2005 to be named and 2023 to be standardized? Because Chaum's version produced the wrong kind of output, and the right kind needed a second ingredient that did not exist yet.

Watch the shape of what Chaum built. A blind signature is public: anyone with the bank's public key can verify it. That is perfect for a coin you want a merchant to check, and exactly wrong for a pepper you want no one to be able to reproduce. To harden a password, you do not want a verifiable signature on it; you want a pseudorandom value that only the keyholder could have produced and only the querier can read.

Chaum had the blinding. He did not have a pseudorandom thing to blind. This is why "Blind RSA," standardized decades later as RFC 9474, is not an OPRF but its publicly verifiable cousin -- a distinction that will matter enormously when we reach Privacy Pass [@rfc9474].

The second ingredient arrived in 1997. Moni Naor and Omer Reingold built a pseudorandom function out of pure number theory: $F_k(x)$ computed as a single group exponentiation whose exponent is a subset-product of the key, $g^{\prod a_i^{x_i}}$, provably secure under the Decisional Diffie-Hellman assumption [@naorreingold97]. What mattered was not the security proof but the shape. Because the function was built from group exponentiations, it had enough algebraic structure that a blinded input could pass through it and come out blinded -- the homomorphic property that makes oblivious evaluation possible at all. A random hash function scrambles its input beyond recovery; an algebraically structured PRF lets the blind survive the trip.

Now the two ingredients were on the table. In 2005, Michael Freedman, Yuval Ishai, Benny Pinkas, and Omer Reingold fused them, gave first constructions, and coined the term: the Oblivious Pseudorandom Function [@fipr05]. They were not thinking about passwords. They wanted private keyword search and private set intersection -- letting one party query another's database, or intersect two sets, without either side revealing its contents.

The abstraction they named is the one we still use: transplant Chaum's blinding out of RSA, point it at a Diffie-Hellman-structured PRF, and you get a value that is pseudorandom rather than a signature, and blind rather than seen.RFC 9497 standardizes multiplicative blinding, the variant described here: its Blind step computes blindedElement = blind * inputElement, and that multiplicative form is what ships.

flowchart LR A["1982 Chaum blinding in RSA"] --> B["1986 Fiat-Shamir transform"] B --> C["1992 Chaum-Pedersen DLEQ proof"] C --> D["1997 Naor-Reingold algebraic PRF"] D --> E["2005 FIPR names the OPRF"] E --> F["2009 Jarecki-Liu efficient DH OPRF"] F --> G["2014 2HashDH, the workhorse"] G --> H["2018 Privacy Pass VOPRF"] H --> I["2022 3HashSDHI POPRF"] I --> J["2023 RFC 9497 standard"] J --> K["2025 RFC 9807 OPAQUE"]

Two other pieces on that timeline were quietly waiting to become load-bearing. In 1986, Fiat and Shamir showed how to turn an interactive proof into a one-shot, non-interactive one by replacing the verifier's random challenge with a hash of the transcript [@fiatshamir86]. In 1992, Chaum and Pedersen gave a zero-knowledge proof that two discrete logarithms are equal [@chaumped92]. Neither was about OPRFs. Both become the machinery of verifiability when, twenty-six years later, Privacy Pass needs a client to check which key the server used. Keep them in view; they return in Section 5.

The problem was defined and it had a name. What it did not have was a construction cheap enough to ship. And the first one that looked practical turned out to have a slow poison built into it.

3. The First Construction That Got Weaker With Use

Naming a primitive is not the same as having a recipe worth shipping. The constructions that came with the 2005 definition were general and powerful and, for a deployed service, awkward. The oblivious-transfer and oblivious-polynomial-evaluation approaches were round-heavy. The Naor-Reingold-based ones inherited the PRF's per-bit structure: they consumed the input one bit at a time, so their cost scaled with the input length rather than staying flat.The linear-in-input-length cost of the early Naor-Reingold-style OPRFs is an inference from that PRF's per-bit construction rather than a benchmark quoted from the 2005 paper; treat it as a structural signpost, not a measured figure. For private set intersection in a research prototype, fine. For a server answering millions of blind queries a second, not yet.

The efficient turn came in 2009. Stanislaw Jarecki and Xiaomin Liu built the first OPRF that was both fast and committed -- verifiable -- in a prime-order group [@jareckiliu09]. Instead of the exponentiation-per-bit structure, it used a Dodis-Yampolskiy-style PRF of the form $g^{1/(k+x)}$: the server inverts $k + x$ in the exponent, so evaluation is a single group operation regardless of input length.

And because the construction committed to the key, the client got assurance not just that some key was applied but that it was the server's key. In the language of our three questions, this one answered Q1 and Q2 at once. It looked like the deployable OPRF.

Then look at the assumption it rested on. Security of the $g^{1/(k+x)}$ family reduces to a q-strong-Diffie-Hellman assumption: hardness holds as long as the attacker cannot exploit a growing collection of key-dependent samples. And three years earlier, in 2006, Jung Hee Cheon had shown precisely how to exploit them. Cheon's analysis proved that the strong-Diffie-Hellman family weakens as the attacker obtains more samples tied to the same secret -- security degrades with the number of queries [@cheon06].

Sit with what that means for an OPRF specifically. An OPRF's entire job is to be offered as a service: to answer blind query after blind query, indefinitely. But every answer this construction gave was another key-dependent sample, and Cheon's result said each sample chipped away at the secret. The primitive got weaker the more it was used. A lock that loosens every time you turn the key is a strange thing to install on a vault you intend to open a billion times.

Note: Most cryptographic primitives are static: a hash function is exactly as strong after a trillion evaluations as after one. The 2009 Jarecki-Liu OPRF was not. Its security was a budget that the act of answering queries spent down, because each blind evaluation handed the attacker another sample against the strong-Diffie-Hellman assumption it relied on [@cheon06]. For a primitive whose whole purpose is to be queried without limit, that is a design-level contradiction, not a tuning problem. This is our third question -- how many asks? -- appearing for the first time, and appearing as a wound rather than a footnote.

This is worth marking as special: it is the only true assumption-level break in the whole story. Everything else that supersedes something in the lineage does so because it is cheaper, or answers one more question. Only here does a construction fall because the mathematical ground under it gave way. The strong-Diffie-Hellman assumption was the wrong foundation, and no engineering on top could fix a foundation that eroded by design.

The fix was not a cleverer attack defense. It was to stop building on an assumption that decays -- to hash the input to one group element and re-base the whole construction on an assumption that does not weaken sample by sample. That single stroke produced the workhorse that every deployment now runs, and it is where the OPRF stops being a research object and becomes infrastructure.

4. Moving the Server From Trusted to Blind

Here is the whole next fifteen years compressed into one sentence: each generation moves the server one step from "must be trusted, sees the secret" toward "blind, verifiable, query-limited," and -- the part that surprises people -- most of those steps are additive. A later construction rarely throws out its predecessor. It bolts one more guarantee onto it. To read the lineage correctly you have to separate two kinds of arrow: superseded by, a genuine replacement, and extended by, an additive answer to one more question with the old construction still running underneath.

The workhorse: 2HashDH

In 2014, Stanislaw Jarecki, Aggelos Kiayias, and Hugo Krawczyk wrote down the construction we built by hand in Section 1: $F(k, x) = H_2(x,, H_1(x)^k)$ [@jkk14]. Hash the input into the group with $H_1$, exponentiate by the key, hash out with $H_2$.

It is round-optimal -- one message each way, and you provably cannot do it in fewer. And its security rests on the One-More Gap Diffie-Hellman assumption rather than the strong-Diffie-Hellman family, which is the whole point: One-More Gap security is not a function of a growing pile of key-dependent samples, so it sidesteps the Cheon erosion that doomed the 2009 construction."One-More" assumptions bound how much an attacker can produce relative to how many genuine evaluations it was given -- it cannot get "one more" than it was handed. This framing is what breaks the dependence on a growing q-tuple that made the strong-Diffie-Hellman family decay under Cheon's attack. Because the input is hashed to a single group element, cost is flat in input length. Jarecki, Kiayias, Krawczyk, and Jiayu Xu put it on composable footing two years later [@jkkx16].

The construction $F(k, x) = H_2(x,\, H_1(x)^k)$: hash the input into a prime-order group, raise it to the secret key, and hash the result back out with the input bound in. It is the OPRF and VOPRF core standardized in RFC 9497 [@jkk14], [@rfc9497].

This is the OPRF that ships. But notice what it does not do. It answers Q1 -- the server never sees the input -- and nothing more. The client has no way to tell which key the server used. A malicious server can quietly assign a different key to each client and, later, use the distinct responses to tell which client was which. In an anonymity system that is fatal: the primitive designed to hide you becomes the tag that identifies you. 2HashDH left Q2 open. The next generation did not replace it; it extended it.

Verifiability you can batch: the VOPRF

In 2018, Alex Davidson, Ian Goldberg, Nick Sullivan, George Tankersley, and Filippo Valsorda shipped Privacy Pass, and with it the deployed VOPRF [@dgstv18]. The addition is precisely the 1992 machinery we set aside. The server publishes a commitment to its key -- a public key $pk_S = k \cdot G$ -- and alongside each response attaches a Chaum-Pedersen proof that the same $k$ relates its public key and its answer, made non-interactive by Fiat-Shamir [@chaumped92], [@fiatshamir86]. The client verifies before it accepts. Answering Q2, at last.

The engineering move that made it deployable was batching: many evaluations fold into a single proof via a random linear combination, so a client redeeming a thousand tokens verifies one proof, not a thousand [@dgstv18]. That is what let Privacy Pass run at content-delivery-network scale. That scale is what surfaced the primitive's real-world failure modes -- key consistency, tagging, rotation, double-spend -- that no research prototype had stress-tested.

An OPRF augmented with a proof that the server applied the key committed in its published public key, so a client can reject an answer computed under any other key. In RFC 9497 the proof is a batchable Chaum-Pedersen DLEQ [@rfc9497], [@dgstv18].

The VOPRF still left one gap. Its verifiability binds one key to one public key, which means one key cannot cleanly serve many domains, tenants, or rotation epochs -- to separate them you would need a different key per context, and a different public key per context is, again, a tag. What was missing was a way to fold a public label into the evaluation without changing the key.

Partial obliviousness: heavy, then light

The first answer came early and expensive. In 2015, Adam Everspaugh, Rahul Chatterjee, Samuel Scott, Ari Juels, and Thomas Ristenpart built Pythia, the first partially oblivious PRF: a public per-tenant tweak let one server key serve many domains and support bulk key rotation, while the password stayed oblivious [@pythia]. It worked, but it needed bilinear pairings -- special curves, heavier operations, a bigger dependency. Powerful, but not the thing you reach for by default.

The light answer came in 2022. Nirvan Tyagi, Sofia Celi, Thomas Ristenpart, Nick Sullivan, Stefano Tessaro, and Christopher Wood built 3HashSDHI: the first POPRF that needs no pairings [@tcrstw22]. It folds the public input info into the key by inversion. The server computes $t = k + H(\text{info})$ and returns $t^{-1} \cdot \text{blindedElement}$, with a DLEQ proof against the tweaked key. The private input stays oblivious; info is public and known to both sides. And it runs, in the authors' words, as fast as the standards-track 2HashDH protocol [@tcrstw22].

A VOPRF that also binds a *public* input `info` into the evaluation, computing $F(k, x, \text{info})$ while keeping $x$ oblivious. One published key can then serve many public contexts -- tenants, rotation epochs, rate-limit buckets. A POPRF with a fixed `info` is functionally a VOPRF [@rfc9497], [@tcrstw22].

Here is the detail worth savoring. To fold in info, 3HashSDHI uses key inversion -- $t^{-1}$ where $t = k + H(\text{info})$ -- which is the same Dodis-Yampolskiy inversion structure Jarecki and Liu used back in 2009 [@tcrstw22], [@jareckiliu09]. The mechanism that got the field burned by Cheon's attack was never actually wrong. What was wrong was the assumption it had been analyzed under. Tyagi and co-authors re-proved the same inversion under a One-More Gap assumption that reduces to plain discrete log in the algebraic group model, and the old idea walked back onto the field rehabilitated [@tcrstw22].

The lesson is one every protocol designer should internalize: a construction can be sound while the security assumption used to justify it is not, and better analysis can resurrect a "broken" mechanism untouched.

The other lineage, in one breath

Not every OPRF is a Diffie-Hellman OPRF. In 2016, Vladimir Kolesnikov, Ranjit Kumaresan, Mike Rosulek, and Ni Trieu built a completely different one: a batched OPRF from oblivious-transfer extension, symmetric-key rather than public-key, and enormously fast in bulk [@kkrt16]. It is not verifiable, not publicly reusable, and only semi-honest secure, but it intersects two sets of a million ($2^{20}$) elements each in about 3.8 seconds [@kkrt16], and OT-extension OPRFs of this kind were for years the throughput workhorse of high-volume semi-honest PSI, until VOLE-based PSI overtook them in communication for very large sets [@rindalvolepsi]. The takeaway for a practitioner: "OPRF" names a goal, and at least two very different mechanisms reach it. Do not assume every system labeled OPRF is the standardized Diffie-Hellman family.

Approach	Year	Key idea	Questions answered	Fate
Chaum blind signature	1982	Blind, sign, unblind in RSA	none (a signature, not a PRF)	Ancestor; became Blind RSA [@chaum82]
FIPR generic OPRF	2005	Obliviously evaluate an algebraic PRF; names "OPRF"	Q1	Superseded on cost [@fipr05]
Jarecki-Liu	2009	$g^{1/(k+x)}$, committed	Q1 + Q2	Superseded: strong-DH erodes with use [@jareckiliu09]
2HashDH	2014	$H_2(x, H_1(x)^k)$; One-More Gap CDH	Q1	Active core of RFC 9497 [@jkk14]
VOPRF	2018	2HashDH + batched Chaum-Pedersen DLEQ	Q1 + Q2	Active; extends 2HashDH [@dgstv18]
Pythia	2015	Verifiable partially oblivious PRF, pairings	Q1 + Q2 + info	Superseded by 3HashSDHI [@pythia]
3HashSDHI	2022	$(k + H(\text{info}))^{-1}$; no pairings	Q1 + Q2 + info	Active POPRF of RFC 9497 [@tcrstw22]
KKRT16	2016	Batched OPRF from OT-extension (symmetric)	Q1 (relaxed, semi-honest)	Active, niche: high-volume PSI [@kkrt16]

Twenty years of constructions now answered all three questions. But each was a separate paper with its own parameters, its own group choices, and its own foot-guns. The last move was not a new construction. It was a standard that unified them and, unusually for a specification, wrote the one unavoidable cost down as a number.

5. RFC 9497: Three Modes, One Interface

In December 2023, the IRTF's Crypto Forum Research Group published RFC 9497, written by Alex Davidson, Armando Faz-Hernandez, Nick Sullivan, and Christopher Wood [@rfc9497]. It did what twenty years of individual papers had not: it turned the whole family into a single misuse-resistant interface, fixed five ciphersuites, mandated the safety checks, and -- the honest move no construction paper had made -- wrote the one attack it cannot design away down as a number.

Start with the interface, because all three modes share it. Over a prime-order group with generator $G$, and using the hash-to-group machinery of RFC 9380, the protocol is three calls [@rfc9497], [@rfc9380]:

Blind(x):
    blind           <- random nonzero scalar               # fresh, uniform, per call
    blindedElement  <- blind * HashToGroup(x)              # a uniformly random point
    if blindedElement == Identity: abort                   # element validation
    return blind, blindedElement

BlindEvaluate(k, blindedElement, [info]):
    OPRF / VOPRF:  evaluatedElement <- k * blindedElement
    POPRF:         t <- k + HashToScalar(info)
                   evaluatedElement <- t^(-1) * blindedElement
    # VOPRF and POPRF also emit a DLEQ proof (see below)

Finalize(x, blind, evaluatedElement, [info]):
    N <- blind^(-1) * evaluatedElement    # OPRF/VOPRF: = k * HashToGroup(x); POPRF: = HashToGroup(x)^(1/(k+H(info)))
    return Hash( len(x) || x || [len(info) || info ||] len(N) || N || "Finalize" )

The server sees only blindedElement, a uniformly random point independent of $x$; the client recovers exactly one PRF value and nothing about $k$ [@rfc9497]. That is the same 2HashDH we have been circling, now with every byte of the output hash pinned down.HashToGroup is RFC 9380 hash-to-curve, the subject of Part 16. Its defining property is that the output point has an unknown discrete logarithm: no one, including the client, knows a scalar relating it to the generator. That unknown-discrete-log property is exactly why blinding hides the input and why the server cannot invert the map.

The three modes are three answers

This is where the second shift in understanding lands. The three modes are not three products. They are three points on one axis, distinguished by exactly which of our questions they answer.

The base OPRF answers Q1 and stops. BlindEvaluate is just $k \cdot \text{blindedElement}$, with no proof. The client trusts that some key was applied; it gets no assurance about which. Cheapest mode, smallest messages, right only when a wrong key can hurt no one but the querier [@rfc9497].

The VOPRF answers Q1 and Q2. The server commits to a public key $pk_S = k \cdot G$ and attaches a proof; the client verifies before finalizing [@rfc9497]. The POPRF answers Q1 and Q2 and binds a public info, via the key-inversion tweak. A POPRF with a fixed info collapses back to a VOPRF [@rfc9497]. Base to verifiable to partially oblivious: blind, then blind-plus-which-key, then blind-plus-which-key-plus-public-tweak.

Key idea: Three modes are three answers to three questions. OPRF answers "is it blind?" VOPRF adds "which key?" POPRF adds "and bind this public label." You do not choose a mode by taste; you choose it by counting how many of the three questions your threat model forces you to answer.

flowchart LR Q1["Q1: is it blind?"] --> OPRF["OPRF: blind only"] OPRF -->|add DLEQ proof against one committed key| VOPRF["VOPRF: blind plus which key"] VOPRF -->|fold in a public info tweak| POPRF["POPRF: blind, which key, public label"]

Verifiability, in depth

The proof is the 1992 machinery finally doing its job. A Chaum-Pedersen DLEQ proof establishes that two discrete logarithms are equal: that the $k$ relating $pk_S$ to $G$ is the same $k$ relating evaluatedElement to blindedElement [@rfc9497], [@chaumped92]. If the server used any other key, no valid proof exists. Fiat-Shamir turns the interactive proof into a single non-interactive object the client checks offline, so verifiability costs no extra round [@fiatshamir86].The DLEQ proof is a sigma protocol made non-interactive by Fiat-Shamir -- the same transform behind Schnorr signatures, which Part 17 covers. The client recomputes the challenge as a hash of the transcript and checks one equation; there is no back-and-forth with the server.

A non-interactive zero-knowledge proof that two discrete logarithms are equal -- here, that the server's public key and its response were produced under the same secret key. It is what makes a VOPRF verifiable, and via a random linear combination it can prove a whole batch of responses with one object [@rfc9497], [@chaumped92].

Batching is what makes verifiability affordable. Many evaluations fold into one proof through a random linear combination, so a client redeeming a batch verifies a single object, not one proof per element [@rfc9497], [@dgstv18]. That is one proof object per batch, not $n$ -- but verifying it still forms one linear combination across the batch, so the win is skipping $n$ separate proof checks, not making verification constant-time in the batch size. That is what let anonymous-token issuance scale.

There is a subtlety that quietly carries the entire security of any anonymity system built on a VOPRF: verifiability is only as strong as key consistency. Proving the server used the key in its public key is worthless if the server hands a different public key to every client, because then the unique key is itself a deanonymizing tag. Verifiability protects you only when everyone is served under one transparently published key [@rfc9497]. We will return to this in the practical guide; for now, note that "add a proof" and "pin one key" are two requirements, not one.

sequenceDiagram participant C as Client (input x) participant S as Server (key k, public pkS) Note over C: blindedElement holds blind times HashToGroup(x) C->>S: send blindedElement Note over S: evaluatedElement holds k times blindedElement Note over S: GenerateProof binds pkS and the answer to one k S->>C: return evaluatedElement and DLEQ proof Note over C: VerifyProof against pkS, abort on failure Note over C: unblind, then Finalize with domain separation

The machinery that makes it safe

A specification earns "misuse-resistant" in the details, and RFC 9497's details are where the accumulated scar tissue lives. Hashing and group operations are delegated, not reinvented: HashToGroup and HashToScalar come from RFC 9380, and the groups themselves from RFC 9496 -- ristretto255 and decaf448 -- or the NIST curves [@rfc9497], [@rfc9380], [@rfc9496].ristretto255 and decaf448 are prime-order abstractions built over Edwards curves whose raw order has a small cofactor. They remove the cofactor pitfalls that Part 15 covers -- the small-subgroup and equivalent-point traps -- which is exactly why RFC 9497 prefers them and why it mandates rejecting the identity element on deserialization.

Three requirements are worth naming because dropping any one silently breaks the guarantee:

Note: RFC 9497 requires that every deserialized element be validated -- on-curve, in the right range, and not the identity -- or an attacker can probe the key with malformed inputs [@rfc9497]. It requires that operations on secret data, including GenerateProof and BlindEvaluate, run in constant time, or the server leaks its key through timing [@rfc9497]. And it requires domain separation: the literal "Finalize" tag and the mode context string keep one application's evaluations from colliding with another's [@rfc9497]. None of these is optional hardening; each is load-bearing for a property the primitive claims.

The domain separation is the discipline Part 13 argued for, applied here: the output hash binds the input length, the input, the point, and a fixed label, so no two contexts can be coaxed into producing the same value. Inputs are bounded -- shorter than $2^{16}-1$ bytes, with a two-byte length prefix -- so longer inputs must be pre-hashed [@rfc9497].

The guarantee that the server cannot link two evaluations of the same input, nor learn anything about the input. Because the blind is fresh and uniform, this holds *even against an adversary with unbounded computation* -- it is information-theoretic, not merely computational [@rfc9497], [@dgstv18].

{` // STRUCTURAL MODEL. Shows why Finalize binds lengths + a "Finalize" tag, not just N. function toyHash(str) { // a tiny non-cryptographic stand-in let h = 5381 >>> 0; for (const ch of str) h = (Math.imul(h, 33) ^ ch.charCodeAt(0)) >>> 0; return (h >>> 0).toString(16).padStart(8, '0'); } // length-prefixed encoding: len(x) || x, so boundaries are unambiguous function lp(s) { return String(s.length).padStart(4, '0') + s; }

// RFC 9497 Finalize binds: len(x) || x || len(N) || N || "Finalize" function finalize(x, N) { return toyHash(lp(x) + lp(N) + 'Finalize'); }

// Without length prefixes, ("ab","c") and ("a","bc") would collide. With them, they don't: console.log('naive ab|c =', toyHash('ab' + 'c')); console.log('naive a|bc =', toyHash('a' + 'bc'), '(collides above)'); console.log('finalize ab,c =', finalize('ab', 'c')); console.log('finalize a,bc =', finalize('a', 'bc'), '(distinct)'); `}

Finally, the honesty. RFC 9497 section 7.2.3 states outright that every BlindEvaluate is a static-Diffie-Hellman oracle sample, and quantifies the erosion: the best-known attacks reduce the group's security by $\log_2(Q)/2$ bits, where $Q$ is the number of calls [@rfc9497], [@browngallant04], [@cheon06]. That is the domesticated ghost of the very failure that killed the 2009 construction -- no longer a surprise, but a budget line. We give it the full treatment it deserves in Section 8. First: who actually runs this, and what looks like it but is not.

6. Who Runs This Today

The OPRF is quietly load-bearing. You almost certainly used one this week without knowing it, because it lives one layer below the protocols you do know. Here are the four deployed consumers, each at "exactly where and why it calls the OPRF," and each paired with the look-alike an expert must not confuse it with.

OPAQUE, standardized as RFC 9807 in July 2025. This is the flagship. OPAQUE is an augmented password-authenticated key exchange: the server authenticates you by password without ever seeing the password, even at registration, and with no cleartext salt an attacker could precompute against [@rfc9807], [@opaque-paper]. The OPRF is the tool that makes the password oblivious, and it is what defeats precomputation attacks -- there is nothing static to build a rainbow table against.

RFC 9807 derives a per-user OPRF key from a single seed, keyed by each credential_identifier, so a server compromise does not let an attacker enumerate accounts, and it discusses a threshold-OPRF defense that forces an attacker online before any dictionary attack can even begin [@rfc9807]. The RFC names WhatsApp's end-to-end encrypted backups as a driving use case, and Meta's audited opaque-ke is the reference implementation [@rfc9807], [@opaque-ke]. If Part 12 explained why offline dictionary attacks are the thing to fear, OPAQUE is the OPRF's answer to them.

Privacy Pass, RFCs 9576, 9577, and 9578, June 2024. The in-scope token type is 0x0001 = VOPRF(P-384, SHA-384); RFC 9578 says plainly that its privately verifiable issuance is based on the OPRF [@rfc9578], [@rfc9576], [@rfc9577]. This is the VOPRF most engineers meet by name. But Privacy Pass is not one thing, and this is the boundary the whole article has been protecting.

RFC 9578 defines two interchangeable token types. Token `0x0001` is a VOPRF, and it is an OPRF. Token `0x0002` is Blind RSA (2048-bit), standardized in RFC 9474, and it is a blind *signature* -- Chaum's 1982 construction, publicly verifiable, and emphatically *not* an OPRF [@rfc9578], [@rfc9474]. The most visible Privacy Pass deployment in the world, Apple's Private Access Tokens, uses the Blind-RSA token, not the VOPRF one. The two make a real, standardized trade-off: VOPRF tokens are issuer-verifiable only, small, and easy to rotate; Blind-RSA tokens are publicly verifiable with the RSA public key but larger and heavier to rotate [@rfc9578]. So never write "Privacy Pass equals OPRF." One of its two token types is not an OPRF at all -- a point the earlier field-guide entry on anonymous credentials shipping develops further.

Password breach checking. Google's Password Checkup performs a blinded, OPRF-based lookup: it checks your credential against a corpus of breached ones without Google learning the credential [@thomas19], [@google-blog]. Microsoft's Password Monitor in Edge does something related but not identical, and the difference matters.

It is tempting to describe Microsoft Password Monitor as "an OPRF breach check," but that undersells the machinery. The OPRF is one layer; the actual set-matching runs on *homomorphic encryption* -- Labeled Private Set Intersection built on the Microsoft SEAL library, evaluating the match under encryption [@msft-monitor]. The OPRF hides the query; the fully homomorphic layer performs the private lookup against the breach set. Do not attribute the set intersection to the OPRF alone. And note the well-known *non-OPRF* alternative for the same job: Have I Been Pwned's k-anonymity range API, where the client sends the first five hex digits of a SHA-1 hash and receives the whole bucket to search locally [@cloudflare-kanon]. That leaks a hash prefix by design; it is prefix-bucketed hashing, simpler and cache-friendly, but not oblivious. The earlier entry on [Edge's two password cryptographies](/blog/edge-two-password-cryptographies/) traces this contrast in detail.

OPRF-based private set intersection. OPRF-PSI is one approach among several -- plain Diffie-Hellman PSI, oblivious-transfer and circuit-based PSI, and homomorphic-encryption PSI all compete for different workloads [@fipr05]. Even within OPRF-PSI, the two mechanisms from Section 4 occupy different corners: the public-key 2HashDH family when you want few messages and verifiability, and the symmetric KKRT16 OPRF when you want raw throughput over enormous sets [@kkrt16].

Consumer	What the OPRF does there	The non-OPRF look-alike to not confuse it with
OPAQUE (RFC 9807)	Makes the password oblivious; defeats precomputation; per-user keys block enumeration [@rfc9807]	A plain salted or peppered hash, where the server must see the password
Privacy Pass token `0x0001`	VOPRF issuance of unlinkable, issuer-verifiable tokens [@rfc9578]	Token `0x0002` = Blind RSA, a publicly verifiable blind signature (Apple PAT) [@rfc9474]
Google Password Checkup	Blinded OPRF lookup against a breach corpus [@thomas19]	HIBP k-anonymity range API: leaks a SHA-1 prefix, not oblivious [@cloudflare-kanon]
Microsoft Password Monitor	OPRF hides the query; FHE Labeled PSI does the match [@msft-monitor]	Assuming the OPRF alone does the set intersection
OPRF-based PSI	Oblivious set membership via 2HashDH or KKRT16 [@kkrt16]	DH-PSI, OT/circuit-PSI, and FHE-PSI, which are different approaches

The production substrates are a short list: Cloudflare's CIRCL in Go, the voprf crate and opaque-ke in Rust, and curve25519-dalek providing the ristretto255 group backend [@circl], [@voprf-crate], [@opaque-ke], [@dalek]. Four deployments, one primitive, three look-alikes that are emphatically not it. When you actually have to choose, the decision comes down to a small matrix.

7. The Decision Matrix

Given a real problem, each decision has a crisp rule. Here they are, head to head.

Which mode?

The primary choice is the mode, and it falls straight out of the three questions.

Dimension	OPRF (base)	VOPRF	POPRF
Questions answered	Q1 (blind)	Q1 + Q2 (which key)	Q1 + Q2 + public tweak
Extra output	none	DLEQ proof (batchable)	DLEQ proof (batchable)
Public input `info`	no	no	yes, $F(k, x, \text{info})$
Construction	2HashDH	2HashDH + DLEQ	3HashSDHI
Assumption	One-More Gap CDH	One-More Gap CDH	One-More Gap SDHI (to q-DL, AGM)
Client trust in key	must trust	verifies	verifies
Best suited for	trusted-key internal oracle	anonymity systems, OPAQUE	per-tenant, rotation, buckets

Sources: RFC 9497 sections 3.3.1 through 3.3.3, plus DGSTV18 and TCRSTW22 [@rfc9497], [@dgstv18], [@tcrstw22]. The rule: if you trust the server's key by construction and need only obliviousness, use the base OPRF. If any adversarial server could hand you a wrong or per-client key -- anonymity systems, OPAQUE -- use the VOPRF. If you need to bind a public label such as a per-tenant salt, rotation epoch, or rate-limit bucket, use the POPRF, and never put a secret in info.

Which ciphersuite?

Pick the ciphersuite by your query budget, because the group size is what buys you static-Diffie-Hellman headroom (Section 8).

Ciphersuite	Group	Nominal security	Use when
ristretto255-SHA512	ristretto255	128-bit	Default: prime-order, fast, no cofactor traps
decaf448-SHAKE256	decaf448	224-bit	Internet-facing oracle needing static-DH headroom
P-256-SHA256	NIST P-256	128-bit	FIPS or interop constraints
P-384-SHA384	NIST P-384	192-bit	Higher budget; Privacy Pass `0x0001` uses this
P-521-SHA512	NIST P-521	256-bit	Maximum static-Diffie-Hellman headroom

Source: RFC 9497 sections 4.1 through 4.5 [@rfc9497]. The rule: default to ristretto255-SHA512. If you expose an unmetered public oracle on a 128-bit group, the $\log_2(Q)/2$ erosion argues for decaf448, P-384, or P-521 -- RFC 9497 recommends exactly these for applications that cannot tolerate discrete-logarithm security below 128 bits [@rfc9497]. Choose P-256-SHA256 only when FIPS or interoperability forces it. And never roll your own group or hash-to-curve; use RFC 9380 and RFC 9496 [@rfc9380], [@rfc9496].

Which token cryptography?

If you are issuing anonymous tokens, the choice between the two Privacy Pass token types is a genuine trade-off, not a default.

Dimension	VOPRF token `0x0001`	Blind-RSA token `0x0002`
Primitive	OPRF (VOPRF, P-384/SHA-384)	Blind signature (RSA-2048), not an OPRF
Verifiability	Issuer-verifiable only (secret key)	Publicly verifiable (RSA public key)
Token size	Small	Larger
Key rotation	Easy	Heavier (RSA keypair)
Flagship deployment	CDN anonymous rate-limiting	Apple Private Access Tokens
Spec	RFC 9578, RFC 9497	RFC 9578, RFC 9474

Sources: RFC 9578 and RFC 9474 [@rfc9578], [@rfc9474]. The rule: if only the issuer needs to verify tokens and you want small, easily rotated tokens, use the VOPRF token. If a third party must verify a token without contacting the issuer, you need public verifiability, and that means a blind signature -- the Blind-RSA token -- which is not an OPRF at all.

The remaining two, briefly

For private set intersection, choose the public-key 2HashDH OPRF when you want few messages and malicious-secure verifiability, and the symmetric KKRT16 OPRF when you want to intersect enormous sets fast under a semi-honest model [@jkk14], [@kkrt16]. For breach checking, choose an OPRF when query privacy is a hard requirement, and k-anonymity when simplicity and cache-friendliness outweigh the leak of a hash prefix [@thomas19], [@cloudflare-kanon].

Every row above assumes one thing worth making explicit, because it is the property the whole family exists to deliver. Against a plain salted or peppered server-side hash, the server must see the secret to key it. That is the single compromise the OPRF removes, and each decision in this matrix is a variation on how much structure you are willing to add on top of "the server never saw it." Which is worth asking: what, precisely, can this primitive prove -- and what can it provably not?

8. What the Assumptions Buy, and What They Cost

If the discrete logarithm has never been broken, what can still go wrong with an OPRF -- and what can never be fixed? The answer separates cleanly into what the primitive provably delivers, what it rests on, and the one price it can never stop paying.

What it delivers. RFC 9497 section 7.1 enumerates the guarantees [@rfc9497]. Pseudorandomness: for a random key, the output is indistinguishable from a random function. Nonmalleability: you cannot turn one evaluation into another. Verifiability, in the VOPRF and POPRF modes. Partial obliviousness, in the POPRF. And the one worth pausing on -- unconditional input secrecy. Because the blind is fresh and uniform, the point the server receives is uniform and independent of the input, so input secrecy holds even against an adversary with unbounded computation [@rfc9497]. That is not "secure until someone finds a faster algorithm." It is information-theoretic. The secret was never in the message, so there is nothing for computation to extract.

What it rests on. The OPRF and VOPRF rest on the well-studied One-More Gap Computational Diffie-Hellman assumption; the POPRF on One-More Gap Strong-Diffie-Hellman-Inversion [@rfc9497], [@jkk14], [@tcrstw22]. The POPRF's assumption comes with a load-bearing result: it is shown to be implied by the plain $q$-discrete-logarithm assumption in the algebraic group model [@tcrstw22]. All three are discrete-log-family assumptions believed hard in the groups actually used, so the deployed OPRF is anchored to the same discrete-log problem Part 18 argued has stood unbroken for half a century. That is about as good a foundation as applied cryptography offers.

What it costs, forever. Now the third question comes due. Every BlindEvaluate is, by construction, a static-Diffie-Hellman oracle sample: the server computes $x \mapsto x^k$ for a fixed secret $k$, and Brown-Gallant and Cheon showed that collecting such samples recovers $k$ at a cost that drops with the count [@rfc9497], [@browngallant04], [@cheon06].

A service that, for a fixed secret key $k$, answers queries of the form $x \mapsto x^k$. Each answer is a sample that erodes the key: after $Q$ queries, the best-known attacks recover $k$ at a cost reduced by $\log_2(Q)/2$ bits (the Brown-Gallant and Cheon bound). Offering an OPRF *is* offering this oracle [@browngallant04], [@cheon06].

The specification does not bury this. It states it:

"Best-known attacks reduce the security of the prime-order group instantiation by log_2(Q) / 2 bits, where Q is the number of BlindEvaluate calls." -- RFC 9497, section 7.2.3

Work the arithmetic and the design pressure becomes concrete. On a 128-bit group, effective key security is $128 - \log_2(Q)/2$ bits. Answer $2^{40}$ queries and you have shed 20 bits, down to 108. Answer $2^{60}$ and you are at 98. This is not an implementation flaw you can patch; it is a lower bound on the attacker's advantage that no construction in this family removes, because it follows from the primitive doing the one thing it exists to do.

BlindEvaluate calls $Q$	Bits lost, $\log_2(Q)/2$	Effective security on a 128-bit group
$2^{20}$	10	118 bits
$2^{40}$	20	108 bits
$2^{60}$	30	98 bits
$2^{80}$	40	88 bits

Note: "Keep this key secret forever" and "answer unlimited public blind queries on a 128-bit group" cannot both hold. The static-Diffie-Hellman erosion is inherent to exposing the oracle, so an unmetered public OPRF on a 128-bit group provably cannot retain 128-bit key security [@rfc9497], [@browngallant04]. The only resolutions are operational: rate-limit BlindEvaluate, rotate the key on a schedule, or move to a larger group (decaf448, P-384, P-521). You are choosing a budget, not eliminating a cost.

Look at what just happened across five sections. The strong-Diffie-Hellman decay that doomed the 2009 Jarecki-Liu construction was treated then as a fatal flaw -- the reason to abandon a whole generation [@jareckiliu09], [@cheon06]. The *same physics* reappears in RFC 9497, but now it is a written-down budget with a formula and a mitigation list [@rfc9497]. Nothing about the mathematics changed. What changed is the engineering posture: a phenomenon that was a silent, disqualifying weakness became an explicit, managed policy knob. This is often how a field matures -- not by defeating a limit, but by naming it precisely enough to live with it.

Two more facts bound the theory. Round-optimality: two messages is provably the minimum, and 2HashDH achieves it, so there is no efficiency left to win there.The two-message floor is structural: the client must send at least one blinded value and receive at least one response to recover an output, so no protocol of this shape can use fewer round-trips. And two honest open edges. RFC 9497 admits that the exact multi-key, batched protocol the industry actually deploys has no security proof:

"There is currently no security analysis available for the VOPRF protocol described in this document in a setting with multiple server keys or batching." -- RFC 9497, section 7.2.1

The deployed reality -- many issuer keys, batched proofs -- outruns the single-key proof it is built on [@rfc9497]. And the whole family rests on discrete log, so a scalable quantum computer running Shor's algorithm breaks obliviousness and unforgeability alike. Two of these limits are not settled facts but open frontiers -- and the sharpest one opened with a construction that was broken within a year of being proposed.

9. Where It Is Still Moving

For the single-key, non-batched, classical setting, the theory is essentially closed: round-optimal, constant communication, unconditional input secrecy, a clean assumption reducing to discrete log. The live research is almost entirely about the edges the deployments already stand on.

The post-quantum frontier, which opened with a cautionary tale. Because every deployed OPRF falls to Shor, the sharpest open problem is a post-quantum replacement -- and the first serious attempt is exactly why the field is cautious.

In 2020, Dan Boneh, Dmitry Kogan, and Katharine Woo built the first substantial post-quantum OPRF from supersingular isogenies [@bkw20]. Within a year, Andrea Basso, Peter Kutas, Simon-Philipp Merz, Christophe Petit, and Antonio Sanso cryptanalyzed it, giving a polynomial-time attack and a subexponential one that survived the obvious countermeasures -- together breaking the parameters the authors had proposed [@basso21].

A construction proven secure under a named assumption was undone because the assumption itself did not hold. It is the cleanest possible reminder that a proof is only as good as what it reduces to.The isogeny paper actually offered two constructions. Its second one revived the 1997 Naor-Reingold PRF, reinterpreted over commutative group actions (the CSIDH setting) [@bkw20], [@naorreingold97]. The oldest algebraic PRF in this story turned out to be the one with a plausible post-quantum future -- a twenty-three-year-old idea made newly relevant by a change of group.

The other post-quantum directions are advancing but heavy. Martin Albrecht, Alex Davidson, Amit Deo, and Nigel Smart gave a round-optimal verifiable OPRF from ideal lattices in 2021 [@adds21]; Albrecht and Kamil Doruk Gur made it "practical-ish and thresholdisable" in 2024, cutting its lattice bandwidth roughly fourfold and adding a threshold variant [@albrechtgur24]. And a general framework arrived in 2025: Ward Beullens, Lucas Dodgson, Sebastian Faller, and Julia Hesse compiled quantum-safe OPRFs from secure multi-party evaluation of simple functions, reporting a working construction in about 0.57 seconds with under a megabyte of communication [@beullens25].

That is a genuine milestone -- and it is still orders of magnitude heavier than the sub-millisecond classical evaluation it aims to replace. An efficient, verifiable, partially oblivious post-quantum OPRF, matching the classical profile on all three counts at once, does not yet exist.

The proof the industry is running ahead of. Section 8's second pull quote is also an open problem: prove the multi-key, batched VOPRF that Privacy Pass actually deploys [@rfc9497]. Batching is a well-used heuristic, but the formal guarantee still covers only the single-key case.

Removing the single point of failure. A threshold or distributed OPRF splits the key across several servers so no one of them holds it, which is the structural answer to server compromise. RFC 9807 names exactly this as the defense that forces an attacker online before any dictionary attack can start [@rfc9807]. Round-optimal, misuse-resistant threshold OPRF specifications are still maturing.

The limits that are policy, not cryptanalysis. Two open problems are engineering rather than mathematics. The static-Diffie-Hellman budget is a permanent tax on any public oracle; the open question is operational -- what query cap and rotation cadence keep a given group above 128 bits -- not whether the bound can be improved, since Brown-Gallant and Cheon are believed essentially tight for generic groups [@browngallant04], [@cheon06].

And verifiability quietly collapses if a malicious issuer hands each user a different public key, so making "one key for everyone" auditable needs key-transparency infrastructure that does not yet ship as a turnkey component [@rfc9497]. Formally verified constant-time implementations sit in the same category: RFC 9497 mandates constant-time secret operations, but the guarantee is only as strong as the machine-checked code behind it [@rfc9497].

None of these block you from shipping today. They tell you what to watch. What you ship today has a small, boring set of rules that separate a correct deployment from a broken one -- and unlike the open problems, those rules are entirely settled.

10. The Rules, Made Operational

Here is the whole deployment discipline in a form a reviewer can apply without rereading the RFC. It has three parts: pick two things, always do a handful, and never do another handful.

Pick the mode by the questions. Trust the key by construction: base OPRF. Must verify which key: VOPRF. Must bind a public label: POPRF, and never smuggle a secret into info, which is public by definition [@rfc9497], [@tcrstw22]. Pick the ciphersuite by the query budget. Default to ristretto255-SHA512; for an internet-facing unmetered oracle move to decaf448, P-384, or P-521; for FIPS or interop use P-256-SHA256. Never roll your own group or hash-to-curve -- use RFC 9380 and RFC 9496 [@rfc9497], [@rfc9380], [@rfc9496].

flowchart TD Start["Choose an OPRF deployment"] --> A{"Could the server be adversarial about which key it uses?"} A -->|no, key trusted| B["Base OPRF"] A -->|yes| C{"Must you bind a public label such as tenant or epoch?"} C -->|no| D["VOPRF"] C -->|yes| E["POPRF"] B --> F{"Unmetered public oracle?"} D --> F E --> F F -->|no| G["ristretto255-SHA512 default"] F -->|yes| H["decaf448 or P-384 or P-521"]

Note: Every call: draw a fresh, uniform blind, and a fresh nonce for the DLEQ proof. Every received element: validate it -- on the curve, in range, and not the identity -- before you touch it [@rfc9497]. Every secret operation, including BlindEvaluate and GenerateProof: run it in constant time [@rfc9497]. Every output: domain-separate with the "Finalize" tag and mode context, and keep inputs within the length limit [@rfc9497]. For a VOPRF or POPRF: publish and pin one public key, transparently, for everyone. For a POPRF: treat an InverseError as a signal that the tweak collided and it is time to rotate [@tcrstw22]. And bound $Q$: rate-limit BlindEvaluate or rotate keys so the static-Diffie-Hellman loss stays inside budget [@rfc9497], [@browngallant04].

The "never" list is just the failure catalog from the last nine sections, re-read as review rules. Each entry maps to one of the three questions answered wrong.

Anti-pattern	Why it breaks	Question violated	The fix
Sending the un-blinded input	The server sees the input; obliviousness is gone	Q1	Always apply the fresh blind before sending [@rfc9497]
A MAC or HKDF "used as an OPRF"	If the server computes it, it saw the input	Q1	Use a real two-party OPRF; the blind is the point [@rfc9497]
Reusing the blind across calls	Two evaluations become linkable, and the input can leak	Q1	Fresh, uniform blind every call [@rfc9497]
Skipping element validation	Malformed points enable key-probing attacks	Q1/Q3	Reject off-curve, out-of-range, and identity elements [@rfc9497]
Dropping or unsoundly batching the DLEQ	A malicious server can use a per-client key and tag you	Q2	Verify the proof; combine batches soundly [@rfc9497], [@dgstv18]
A per-user public key	The unique key is itself a deanonymizing tag	Q2	Pin one transparently published key for all [@rfc9497]
Non-constant-time secret ops	The key leaks through timing	Q3	Constant-time group ops, proof, and evaluate [@rfc9497]
Treating POPRF `info` as secret	`info` is public by definition; obliviousness assumed of it fails	Q1	Put only public labels in `info` [@tcrstw22]
An unmetered oracle on a 128-bit group	The key erodes by $\log_2(Q)/2$ bits, unbounded	Q3	Rate-limit, rotate, or use a bigger group [@rfc9497], [@browngallant04]
Using an OPRF where you need public verifiability	A third party cannot verify a VOPRF token	(wrong primitive)	Use a blind signature (Blind RSA), not an OPRF [@rfc9474]

{` // STRUCTURAL MODEL. Shows why reusing the blind across calls destroys unlinkability. // Same additive group model: a "point" is an integer mod q, scalar*point is mod q. const q = 2147483647; const mod = (a) => ((a % q) + q) % q; const scalarMul = (s, point) => mod(s * point);

const Hx = 991; // H(x): the SAME secret input, evaluated twice const blindedWith = (r) => scalarMul(r, Hx); // what goes on the wire: r*H(x)

// BAD: reuse the same blind r for both calls const rFixed = 55555; const wire1_bad = blindedWith(rFixed); const wire2_bad = blindedWith(rFixed); console.log('reused blind -> wire equal? ', wire1_bad === wire2_bad, '(server links the two as one input)');

// GOOD: a fresh uniform blind each call const wire1_ok = blindedWith(37337); const wire2_ok = blindedWith(88123); console.log('fresh blind -> wire equal? ', wire1_ok === wire2_ok, '(server cannot link them)'); `}

Most of those "nevers" are the same handful of mistakes phrased for different audiences: do not let the server see the input, do not let it pick a per-client key, and do not let it answer unlimited queries. It is worth answering the questions engineers actually ask about them head on.

The `voprf` Rust crate and Cloudflare's CIRCL both implement all three modes against the RFC 9497 test vectors [@voprf-crate], [@circl]. A good first exercise: run the base OPRF, print the blinded element on two evaluations of the same input, and confirm the two wire values differ because the blind is fresh. Then switch to the verifiable mode, tamper with one byte of the server's response, and watch `VerifyProof` reject it. That single afternoon teaches more about Q1 and Q2 than any diagram.

11. Questions Engineers Actually Ask

No, and the difference is the whole primitive. If the server computes `HMAC(k, x)` for you, it *saw* `x`. That is exactly the compromise the OPRF removes: it applies the key to a blinded value it cannot read, so it never sees the input or the output [@rfc9497]. An HMAC that the server evaluates on your plaintext input is not oblivious by any definition. In any setting with an untrusted server, yes, decisively. The base OPRF answers only "is it blind?" Without the DLEQ proof, a malicious server can hand each client a *different* key and later use the distinct responses to tell clients apart -- deanonymizing the very users an anonymity system is meant to protect [@rfc9497], [@dgstv18]. The VOPRF's proof, plus one transparently pinned public key, is what closes that gap. Because every `BlindEvaluate` is a static-Diffie-Hellman oracle sample, and collecting samples recovers the key at a cost that drops by $\log_2(Q)/2$ bits after $Q$ calls [@rfc9497], [@browngallant04], [@cheon06]. It is inherent to offering a Diffie-Hellman oracle, not an implementation defect. Rate-limit, rotate keys, or use a larger group to keep the loss inside budget. Half of it. Privacy Pass token type `0x0001` is a VOPRF, which is an OPRF. Token type `0x0002` is Blind RSA -- a blind *signature*, not an OPRF -- and it is the type behind Apple's Private Access Tokens, the most visible deployment [@rfc9578], [@rfc9474]. So "Privacy Pass equals OPRF" is wrong; one of its two token types is a different primitive entirely. No. Checkup performs a blinded, OPRF-based lookup, so Google does not learn the credential being checked [@thomas19]. Have I Been Pwned's range API uses k-anonymity: you send the first five hex digits of a SHA-1 hash and receive the whole bucket to search locally [@cloudflare-kanon]. That leaks a hash prefix by design. It is simpler and cache-friendly, but it is not oblivious. No. Reusing the blind across calls makes two evaluations of the same input produce the same on-wire value, so the server can link them, and in some settings it can leak the input [@rfc9497]. The blind and the proof nonce must be freshly and uniformly drawn every single call. This is non-negotiable. No. Every RFC 9497 ciphersuite rests on discrete-log hardness, which Shor's algorithm breaks, so a scalable quantum computer defeats both obliviousness and unforgeability [@rfc9497]. Post-quantum OPRFs are an open frontier: the first serious isogeny construction was broken within a year [@bkw20], [@basso21], and lattice and MPC candidates remain far heavier than classical evaluation [@albrechtgur24], [@beullens25]. And to preempt the related question: no, a POPRF's `info` is not secret -- it is public by definition [@tcrstw22].

Read back across the whole story and the shape is unmistakable. Every named failure was one of three questions answered wrong. FIPR's early constructions answered "is it blind?" but too expensively to ship. Jarecki and Liu answered "which key?" too, and then the ground under "how many asks?" gave way beneath them. A base OPRF deployed where a VOPRF was needed answers "which key?" wrong and tags its users. A reused blind answers "is it blind?" wrong. An unmetered public oracle answers "how many asks?" wrong. The broken isogeny construction answered all three -- until its assumption did not hold. The diagnostic is not a teaching device bolted onto the history; it is the history.

And the resolution is a single move, assembled from primitives this series has already built. Take Chaum's 1982 blinding from the RSA world of Part 14, run it in the Diffie-Hellman group of Part 18 -- the discrete log that Part 18 argued nobody has broken, here run one-sided so a server applies a secret rather than agreeing on one -- hash the input into the group with the hash-to-curve of Part 16, and pin the key with the equal-discrete-log proof descended from the sigma protocols of Part 17.

Four earlier building blocks, one new primitive. Later parts of this guide return to its consumers as topics in their own right -- the augmented PAKE, anonymous credentials, private set intersection -- because each is, underneath, this same engine.

The server helped, and it still never saw.

That is the sentence to keep. A pseudorandom function is a lock only the keyholder can open, which is exactly what made it dangerous to offer as a service. The oblivious PRF removed the danger without removing the help: it lets a server apply its secret key to your secret input, prove it used the right key, and do so within a query budget it is honest about -- all without ever seeing what it operated on. Blind, verifiable, rate-limited. The server helped, and it still never saw.

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.