Parag Mali - tag: elliptic-curves

The Log Was Never the Weak Part: How Discrete-Log Cryptography Actually Breaks

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

For a well-chosen group the discrete logarithm is essentially as hard as it can be: the best generic attack is Pollard's rho at about $0.886\sqrt{\ell}$ steps, and Shoup proved no *generic* algorithm does better. So every faster classical break -- anomalous curves, MOV and Frey-Ruck pairing transfers, weak twists, invalid-curve shadow groups, Weil descent, the Number Field Sieve, Logjam's shared-prime precomputation, and small-characteristic quasi-polynomial descent -- is never a cleverer logarithm; it is a receipt for a structural property of the *group that was chosen*. Strip every such property away and only one known break remains, and it changes the machine: Shor's quantum algorithm -- "as far as is known," since the elliptic-curve discrete-log problem is still unproven to be hard.

1. The 256-Bit Paradox

Four cryptographic groups walk onto the internet. NIST P-256 and Curve25519 -- both 256 bits wide -- each advertise roughly $2^{128}$ security, and after two decades of public scrutiny neither has been broken [@safecurves]. A third 256-bit curve, differing from the first two only in a hidden arithmetic property, can be broken on a laptop in polynomial time [@smart-1999]. And a 1024-bit finite-field group -- four times the bit length of the curves -- is a realistic target for a well-funded adversary [@logjam-adrian-2015]. The operation an attacker has to invert is the same discrete logarithm in all four groups.

The variable that decided their fates was never the logarithm. It was the group.

That sentence runs against the way most of us first meet the subject. We are taught that a one-way function is hard, that a bigger key makes it harder, and that "solving the discrete log" is a single monolithic feat an attacker either can or cannot perform. This article argues the opposite, and it argues it as a claim you should not yet believe: the discrete logarithm is essentially never the weak part. The weak part is always the group -- some extra structure it carries, or the wrong group quietly substituted for the right one.

Two settings recur throughout. The first is the multiplicative group of a prime field, written $\mathbb{F}_p^*$, the home of classic finite-field Diffie-Hellman, DSA, and ElGamal. The second is the group of points on an elliptic curve over a finite field, the home of ECDH, ECDSA, and EdDSA. The plan is a guided tour of every known way the discrete log "breaks." Each stop will turn out to exploit a structural property of a chosen group rather than compute a faster logarithm, and the tour ends at the one break that survives even a flawless group: Shor's quantum algorithm.

Note: This is a structural cryptanalysis -- an argument about the mathematics of the group itself. Side-channel leaks, fault and power attacks, implementation bugs, weak random-number generators, and protocol misuse are out of scope, named only to mark the boundary. Those failures are real and often more common in practice, but they belong to the empirical sibling of this piece, "How Elliptic Curves and Diffie-Hellman Break in Real Life: PS3, CurveBall, Logjam, and Biased Nonces." When a break here has an implementation trigger, this article hands that trigger to the sibling and keeps only the group mathematics.

By the end you will be able to look at any of the ten attacks in the literature and name, in one phrase, the structural property of the group it needs -- and see that a well-chosen group simply does not have it. To understand why the group is the variable, we have to go back to the moment the discrete log became something worth attacking at all.

2. What the Discrete Log Actually Is, and Where It Lives

In November 1976, Whitfield Diffie and Martin Hellman published "New Directions in Cryptography" and handed two strangers a way to agree on a shared secret over a wiretapped line without ever having met [@diffie-hellman-1976]. Their construction is simple enough to state in a sentence, and in stating it they turned an obscure number-theoretic puzzle into the thing standing between an eavesdropper and your traffic.

Fix a cyclic group with a public generator $g$. Alice picks a secret $a$ and publishes $g^a$; Bob picks a secret $b$ and publishes $g^b$. Each raises the other's value to their own secret, so both compute $g^{ab}$ -- the shared key. An eavesdropper sees $g$, $g^a$, and $g^b$, and must find $g^{ab}$. The obvious route is to recover $a$ from $g^a$, which is exactly the discrete logarithm. Given a cyclic group generated by $g$ and an element $h = g^x$, find the exponent $x$. In the integers this is easy -- it is just division on a logarithmic scale. Inside a finite group the exponent "wraps around" unpredictably, and no efficient general method to recover $x$ is known. The security of Diffie-Hellman, DSA, ElGamal, ECDH, ECDSA, and EdDSA all rest on this one problem being hard in the group they use.

The instant the DLP became a security assumption, a very old question acquired stakes: how hard is it, actually? And the first answer was unsettling, because it showed that the difficulty had nothing to do with the size of the numbers involved.

Priority is disputed. At GCHQ, James Ellis, Clifford Cocks, and Malcolm Williamson developed classified "non-secret encryption" and a key-exchange analogue between 1969 and 1974, work declassified only in 1997 [@ellis-1997]. The public invention, and the framing of the discrete log as a security assumption, are Diffie and Hellman's.

timeline title Fifty years of attacking the discrete logarithm section The problem and its floor 1976 : Diffie-Hellman make the discrete log a security assumption 1978 : Pohlig-Hellman shatters smooth-order groups : Pollard rho sets the sqrt-time floor section The escape to curves 1985 : Miller and Koblitz move the log onto elliptic curves 1993 : MOV pairing transfer : Gordon adapts the Number Field Sieve to prime fields 1994 : Shor reduces the discrete log to quantum period-finding section Structure strikes back 1998 : Anomalous trace-one curves fall in polynomial time 2002 : Weil descent breaks special binary curves section Records and frontiers 2015 : Logjam weaponizes shared-prime precomputation 2019 : A 795-bit prime-field record : quasi-polynomial small-characteristic descent proven

The first structural lesson: Pohlig-Hellman

In January 1978, Stephen Pohlig and Martin Hellman proved something that should have set the tone for the entire field [@pohlig-hellman-1978]. Suppose the order of the group -- the number of elements -- factors into small primes, $n = p_1^{e_1} p_2^{e_2} \cdots p_r^{e_r}$. Then the discrete log does not have to be solved in the big group at all. It can be solved separately in each prime-power piece, where the numbers are tiny, and the answers glued back together with the Chinese Remainder Theorem.

The total work is on the order of $\sum_i e_i(\log n + \sqrt{p_i})$ -- dominated by the largest prime factor, not by the size of $n$.

Read that again with the thesis in mind. A group can be astronomically large and still offer no security, if its order happens to be a product of small primes. A 4096-bit group whose order is smooth falls instantly.

Security was never a property of "the log" or of the key length. It was a property of the group's order -- specifically, whether that order contains a large prime factor. The first thing anyone proved about the discrete log moved the weakness off the logarithm and onto a structural feature of the chosen group. Everything that follows is a variation on that move.

The escape that defines the rest of the article

By the mid-1980s, the multiplicative group $\mathbb{F}_p^*$ had a second problem beyond smooth orders: it admitted index calculus, a family of sub-exponential attacks we will meet in Section 6. The response, arriving independently from two directions, was not a better logarithm algorithm. It was a change of group.

In 1985, Victor Miller [@miller-1986] and, independently, Neal Koblitz [@koblitz-1987] proposed replacing $\mathbb{F}_p^*$ with the group of points on an elliptic curve over a finite field. Their motivation was explicit and structural: the multiplicative group hands index calculus something to grip, and a general elliptic curve does not, so the same security should be reachable with far smaller keys.

This is the thesis in its constructive form -- when a group is weak, do not sharpen the attack, choose a group with less structure -- and it introduces the lens we will look through for the rest of the article: the distinction between a generic group, whose elements are opaque handles you can only combine with the group operation, and a structured group, whose elements leak extra arithmetic an attacker can exploit.

Miller and Koblitz had escaped one kind of structure. The question their move raised -- and the one the next section answers -- is what an attacker can do against a group that has nothing wrong with it. If Pohlig-Hellman is defeated by a large prime order, how hard is the log then?

3. The Generic Floor: Why Square-Root Time Is the Best You Can Do

Here is a number that has barely moved in fifty years. Against a well-chosen group, the best known generic attack on the discrete log runs in about $0.886\sqrt{\ell}$ steps, where $\ell$ is the largest prime factor of the group's order. Not only is that the best anyone has found -- there is a proof you cannot do fundamentally better generically. To see why that floor exists, and why it is a floor and not a ceiling waiting to be lowered, start with the simplest attack that hits it.

Baby-step giant-step: sorting your way to the log

In 1971 Daniel Shanks described a deterministic method that trades memory for time [@shanks-1971]. To solve $h = g^x$ with $x$ below some bound $N$, precompute and store the "baby steps" $g^0, g^1, \ldots, g^{m-1}$ for $m \approx \sqrt{N}$, then take "giant steps" $h \cdot g^{-jm}$ for $j = 0, 1, 2, \ldots$ until one lands in the stored table. A match pins down $x = i + jm$. The running time is $O(\sqrt{N})$ and so is the memory -- and remarkably, this square-root cost is essentially the same one that still bounds the state of the art.

The clean "given $g$ and $h$, find $x$" statement of the DLP that every textbook now opens with is partly a later reconstruction; Shanks's 1971 paper framed the computation in the language of class numbers and genera, and the crisp cryptographic phrasing was settled in references like the Handbook of Applied Cryptography [@hac-1996].

The memory is the problem. Storing $\sqrt{\ell}$ group elements is fine for a 40-bit group and impossible for a 256-bit one. The breakthrough was getting the same square-root time with almost no memory at all.

A *generic* algorithm treats group elements as opaque tokens: it can multiply them, invert them, and test equality, but it cannot read anything from their representation -- no bits, no size, no factorization. A group is effectively *generic* for an attacker when no such extra structure is exposed. The whole thesis of this article lives in this word: the square-root floor is proven only for *generic* algorithms, and every faster attack works precisely by treating the group as *non*-generic.

Pollard's rho: a random walk that traps itself

Walk pseudo-randomly through the group with a function $f$ that also tracks how each point is built from the generator $g$ and the target $Q$, as $g^a Q^b$. Because the group is finite, the walk must eventually revisit a point, and the birthday bound makes that first self-collision appear after only about $\sqrt{\ell}$ steps. When it does, two different expressions $g^{a_1}Q^{b_1}$ and $g^{a_2}Q^{b_2}$ name the same element, which rearranges into $(a_1 - a_2) \equiv x\,(b_2 - b_1) \pmod{\ell}$ -- and the log $x$ drops out.

John Pollard published this in 1978 [@pollard-rho-1978]. Its beauty is the memory: using Floyd's or Brent's cycle-finding, you need to remember only a couple of points, so the cost is about $0.886\sqrt{\ell} = \sqrt{\pi/4},\sqrt{\ell}$ group operations at $O(1)$ space. The name comes from the shape the walk traces -- a tail that runs into a loop, like the Greek letter rho.

Two effects stack. A pseudo-random walk through a set of $\ell$ elements is expected to run into its own past after on the order of $\sqrt{\ell}$ steps, and working that expected value through the birthday integral gives $\sqrt{\pi/2}\,\sqrt{\ell} \approx 1.2533\sqrt{\ell}$ -- the pure birthday constant. On an elliptic curve a second, curve-specific discount then applies: because $P$ and $-P$ share an $x$-coordinate, the walk can run on equivalence classes under point negation, a $\sqrt{2}$ speedup that pulls the constant down to $\sqrt{\pi/4}\,\sqrt{\ell} \approx 0.886\sqrt{\ell}$ -- the figure SafeCurves quotes for the elliptic-curve discrete log [@safecurves]. Half a century of refinement -- distinguished points, that negation map, better step functions -- has improved the constant but never the exponent. The square root is the wall. flowchart TD A[Start at a known element, tracking exponents a and b] --> B[Apply the pseudo-random step f] B --> C[Land on the next element of the walk] C --> D{"Element seen before?"} D -->|No, keep walking| B D -->|Yes, collision| E[Two products in g and Q name the same element] E --> F[The collision becomes a linear equation in the unknown x] F --> G[Read off the discrete log x]

You can watch the birthday collision happen on a toy group. The subgroup below has prime order $\ell = 509$, so $\sqrt{\ell} \approx 23$; the walk finds its self-collision in a few dozen steps and reads off the secret exponent.

Group: the order-509 subgroup of the integers mod 1019. Q = g^x; recover x.

p, l, g = 1019, 509, 4 # p = 2*l + 1 (safe prime); g has prime order l x_secret = 137 # the exponent the attacker does not know Q = pow(g, x_secret, p)

def step(X, a, b): # A three-way pseudo-random walk that also tracks X = g^a * Q^b (mod p). r = X % 3 if r == 0: return (X * Q) % p, a, (b + 1) % l elif r == 1: return (X * X) % p, (2 * a) % l, (2 * b) % l else: return (X * g) % p, (a + 1) % l, b

seen = {} # a table only to make the collision visible X, a, b = g, 1, 0 # start at X = g^1 * Q^0 for i in range(1, l + 5): if X in seen: a2, b2 = seen[X] den = (b - b2) % l x = ((a2 - a) * pow(den, -1, l)) % l # solve the collision for x print("collision at step", i, " (sqrt(l) is about", round(l ** 0.5), ")") print("recovered x =", x, " true x =", x_secret, " match:", x == x_secret) break seen[X] = (a, b) X, a, b = step(X, a, b) `}

A production attacker drops the table and uses constant memory, restarting on the rare degenerate collision where the bookkeeping cancels. What matters is the exponent: the cost scales as the square root of the subgroup order, and nothing about the group's size changes that scaling.

A close cousin, Pollard's kangaroo (or lambda) method, solves the DLP when $x$ is known to lie in a short interval, at cost proportional to the square root of the interval width rather than of $\ell$.

Parallelism does not change the exponent

In 1999, Paul van Oorschot and Michael Wiener turned rho into a production weapon [@vanoorschot-wiener-1999]. Many machines walk independently and report only distinguished points -- points with a rare, easy-to-test property such as a run of leading zero bits. A collision between any two chains is caught by a central server, and the speedup is near-linear: $m$ machines finish in about $\sqrt{\ell}/m$ wall-clock time. Parallelism buys you a smaller constant and a division by your budget. It does not touch the square root.

The floor is a theorem, not a lack of imagination

Why be sure no cleverer generic walk exists? Because in 1997 Victor Shoup proved a matching lower bound: any algorithm that uses only the group operation must make $\Omega(\sqrt{\ell})$ queries to solve the discrete log, where $\ell$ is the largest prime factor of the order [@shoup-1997]. Pollard's upper bound and Shoup's lower bound close on the same exponent.

Key idea: On a group with no exploitable structure, the best attack anyone knows -- Pollard rho at about $0.886\sqrt{\ell}$ steps -- is provably the best attack anyone generically can know, because Shoup's $\Omega(\sqrt{\ell})$ lower bound meets it. The two bounds coincide at $\Theta(\sqrt{\ell})$. The hardness is not a property of "the logarithm." It is fixed entirely by one number: the largest prime factor of the group's order. The variable has moved from the operation to the group.

That is why "security level" is defined as the rho cost. A 256-bit curve is a $2^{128}$ target, not a $2^{256}$ one, because rho gets a square-root discount that no key-size increase can revoke.

Curve (256-bit unless noted)	Pollard rho cost	What it means
Curve25519	$2^{125.8}$	about 128-bit security, unbroken [@safecurves]
NIST P-256, secp256k1	$2^{127.8}$	about 128-bit security, unbroken [@safecurves]
brainpoolP256	$2^{127.5}$	about 128-bit security, unbroken [@safecurves]
NIST P-384 (384-bit)	$2^{191.8}$	about 192-bit security [@safecurves]
SafeCurves "anomalous" curve (about 204-bit)	$2^{101.6}$ by size alone	a red herring -- its real break is polynomial-time SSSA (Section 4), off the rho scale entirely [@safecurves]

State-of-the-art attacks on the elliptic-curve discrete log are still within a factor of two of Shanks's 1971 method. Half a century of cryptanalysis against a clean curve has bought a factor of two.

The records bear this out. The largest discrete log ever solved on a generic, randomly chosen prime-field elliptic curve is a 112-bit curve, secp112r1, cracked in 2009 by a parallel rho computation [@bos-112bit-2009]. The only solves that have reached higher leaned on exploitable curve structure rather than a stronger generic attack, which is the thesis in miniature. Set that against the finite-field records we are about to meet, where the numbers run past 795 bits, and the gap tells the whole story: against a clean curve there is no better attack than the square-root walk, so records crawl.

This is the wall every attacker hits -- unless the group hands them a crack. So where are the cracks? They start with the curve you choose.

4. The Curve as the Weak Part, I: Special Curves That Transfer the Log Away

The move to elliptic curves was supposed to strip out structure. But the first generation of curve choices smuggled it back in, and the way each weakness works is the quiet engine of this whole article. None of them computes a faster logarithm. Each one moves the logarithm out of the curve and into a different group where the log was never hard to begin with.

flowchart TD A[ECDLP on the chosen curve E] --> B{"What structure did the curve leak?"} B -->|Trace equals 1, so the point count equals p| C[Additive transfer, the SSSA map] B -->|Small embedding degree k| D[Pairing transfer, MOV and Frey-Ruck] C --> E[Log now lives in the additive group of F_p, which has no hardness] D --> F[Log now lives in a finite field where index calculus finishes it] E --> G[Recovered in polynomial time] F --> H[Recovered in sub-exponential time]

Anomalous curves: a trapdoor hiding in the point count

Every elliptic curve over a prime field $\mathbb{F}_p$ has a point count governed by a single integer. Hasse's theorem says $#E(\mathbb{F}_p) = p + 1 - t$, where $t$ is the trace of Frobenius and $|t| \le 2\sqrt{p}$. That one number, $t$, decides whether the curve is world-class or worthless.

The trace of Frobenius $t$ measures how the number of points on $E$ over $\mathbb{F}_p$ deviates from $p + 1$, via $\#E(\mathbb{F}_p) = p + 1 - t$. A curve is *anomalous* when $t = 1$, so that $\#E(\mathbb{F}_p) = p$ exactly -- the group of points has the same order as the additive group of the field it sits over. That coincidence is fatal.

When the group order equals $p$, a map exists -- built from the $p$-adic (formal) logarithm and expressible through Fermat quotients -- that sends the elliptic-curve discrete log straight into $(\mathbb{F}_p, +)$, the additive group of the field. And addition has no discrete-log hardness at all: recovering $x$ from $x \cdot a$ in $(\mathbb{F}_p, +)$ is one modular division. The transfer runs in polynomial time.

This was worked out in 1998 and 1999 by Nigel Smart [@smart-1999], and independently by Igor Semaev [@semaev-1998] and by Takakazu Satoh and Kiyomichi Araki [@satoh-araki-1998]; the attack is often abbreviated SSSA after the four names.

Note: Size buys nothing here. A 256-bit anomalous curve -- indistinguishable at a glance from a strong one, same field size, same key length -- falls in polynomial time, essentially instantly, while its 256-bit clean neighbor stands at about $2^{125.8}$ operations [@safecurves]. The only thing that changed is the trace. The defense is one check: confirm that $#E(\mathbb{F}_p) \neq p$.

There is a subtlety worth flagging so you can spot a common mis-citation: this 1998-99 break is the additive, formal-logarithm transfer. It is not Semaev's later 2004 work on summation polynomials [@semaev-2004], which is a different line of attack we will meet in Section 10. Trace one is a coincidence in the point count; summation polynomials are an index-calculus program. Conflating them is the classic error in retellings of this attack.

Low embedding degree: a bridge into a weaker field

The second transfer needs a different structural flaw. Every prime-order subgroup of a curve has an embedding degree, and if it is small, a bridge opens into a finite field where the log is soft.

For a subgroup of prime order $\ell$ on a curve over $\mathbb{F}_q$, the embedding degree $k$ is the least positive integer such that $\ell \mid q^k - 1$. Equivalently, $k$ is the smallest extension field $\mathbb{F}_{q^k}$ whose multiplicative group contains a copy of the subgroup. When $k$ is small, that copy is reachable, and the finite-field discrete log there is sub-exponential rather than square-root.

The bridge itself is a bilinear pairing.

A pairing is a map $e$ that takes two curve points to an element of $\mathbb{F}_{q^k}^*$ and is *bilinear*: $e(aP, bQ) = e(P, Q)^{ab}$. Bilinearity is what turns a curve log into a field log, but there is a subtlety most retellings get wrong. The *Weil* pairing that MOV uses is *alternating*: $e(P, P) = 1$ for every $P$, so a naive $e(P, P)^x$ is just $1$ and carries no information. MOV instead pairs $Q = xP$ with a *second, linearly independent* order-$\ell$ point $R \notin \langle P \rangle$, giving $e(Q, R) = e(P, R)^x$ in $\mathbb{F}_{q^k}^*$ -- an ordinary finite-field discrete log in the nontrivial root of unity $e(P, R)$. On the classic supersingular victims that independent $R$ arrives for free from a *distortion map* $\psi$, an endomorphism that moves $P$ off its own subgroup so that $R = \psi(P)$ works [@verheul-2004] [@galbraith-2012]. Frey and Ruck use the *Tate* pairing, which is not alternating and does admit a nontrivial self-pairing, so there the bare $e(P, P)^x$ form is the legitimate one.

Menezes, Okamoto, and Vanstone published the Weil-pairing reduction in 1993 [@mov-1993]; Frey and Ruck gave the companion Tate-pairing version in 1994 [@frey-ruck-1994]. The classic victims are supersingular curves, which have embedding degree $k \le 6$. Once transferred into $\mathbb{F}_{q^k}^*$ with small $k$, the log falls to the sub-exponential Number Field Sieve of Section 6.

The escape to a curve is undone by a curve that quietly kept a low-degree door into a field. The defense, again, is a property of the curve you choose: demand a large embedding degree, which the pairing textbook literature treats as a standard selection criterion [@hankerson-mv-2004].

There is a twist worth savoring. The very property MOV and Frey-Ruck exploit -- a workable pairing into a small field -- became the foundation of an entire branch of cryptography. Identity-based encryption, BLS signatures, and much of what makes modern threshold and aggregate signatures possible are *built on* pairing-friendly curves with deliberately small embedding degree. The supersingular curves that MOV destroyed for plain ECDLP found a second career as the substrate of constructive pairing-based cryptography. The same distortion maps that hand MOV its independent second point are what make Antoine Joux's one-round tripartite Diffie-Hellman work -- a three-party key agreement in a single round, and the first purpose-built pairing protocol [@joux-tripartite-2000]. A structural feature is only a weakness relative to what you are trying to do with it.

Step back and notice what both attacks have in common with each other and with Pohlig-Hellman before them.

Note: Neither the anomalous break nor the pairing break computes a faster logarithm. Each one transfers the log: the anomalous curve's log is mapped into $(\mathbb{F}p, +)$, where addition is trivial; the low-embedding-degree curve's log is mapped into $\mathbb{F}{q^k}^*$, where index calculus finishes it. The attacker never out-computes the logarithm on the curve. They relocate it to a group that was never hard. Structure, not speed, is the entire game.

Trace one and small embedding degree are properties an attacker can only hope the designer chose badly. The next family of breaks is nastier, because they can be triggered by the attacker's own inputs, or by a field chosen one level up from the curve.

5. The Curve as the Weak Part, II: Twists, Shadow Groups, and Descent

The cleanest structural weakness of all does not live in the curve you publish. It lives in the curve's twin.

Twist attacks: falling off the curve onto its shadow

Fast elliptic-curve implementations often work with $x$-coordinates only -- the Montgomery ladder, used by X25519, never computes a $y$-coordinate at all. That is a real speed and safety win, but it introduces a subtlety: an $x$ value the attacker sends might not correspond to any point on $E$.

Over $\mathbb{F}_p$, a curve $E$ has a *quadratic twist* $E'$ -- a sibling curve that becomes isomorphic to $E$ only over the larger field $\mathbb{F}_{p^2}$. The key fact for $x$-only arithmetic is that every $x$ in $\mathbb{F}_p$ is the $x$-coordinate of a point on *either* $E$ *or* $E'$. So an attacker-supplied $x$ that is not on $E$ is silently processed as a point on the twist. A curve is *twist-secure* when both $E$ and $E'$ have near-prime order.

Here is the attack. If the twist $E'$ has a smooth order -- a product of small primes -- then a scalar multiplication the victim performs on that twist leaks the secret modulo each small prime, exactly the Pohlig-Hellman shattering from Section 2, now triggered by an attacker's chosen input rather than by the designer's bad luck. Collect enough small residues and the Chinese Remainder Theorem reassembles the key.

The weakness is real, and again it is a property of the group the designer chose: it is defeated by requiring the twist's order, not just the curve's, to be near-prime. Curve25519 was designed to be twist-secure from the start [@bernstein-curve25519-2006], and SafeCurves treats twist security as a first-class criterion [@safecurves].

Invalid-curve shadow groups: arithmetic that forgets its own curve

The next mechanism is sharper still, and it exposes something almost philosophical about how curve arithmetic works.

For a short-Weierstrass curve $y^2 = x^3 + ax + b$, the standard point-addition formulas use $a$ but never use $b$. So if you feed the arithmetic a point that satisfies $y^2 = x^3 + ax + c$ for the *wrong* constant $c$, every formula still returns a well-defined answer -- computed as if on a different, weaker "shadow" curve. If that shadow curve has smooth order, the secret is confined to small subgroups, just as in a twist attack.

Biehl, Meyer, and Muller analyzed this in 2000 [@biehl-meyer-muller-2000], and SafeCurves states the load-bearing fact plainly: the standard formulas do not involve the constant coefficient $b$ [@safecurves]. What makes this a "shadow group" rather than a single weak curve is that the attacker gets to choose $c$, and so gets a whole family of weaker curves to hunt through for one with a smooth order.

Do not confuse invalid-curve attacks with small-subgroup confinement in the Lim-Lee sense. The former uses many different off-curve shadow curves reached by varying $c$; the latter feeds a single low-order element inside one group. Both end in Pohlig-Hellman, but the structural handle is different.

Now, the honest boundary. The mechanism above is pure group arithmetic -- a genuine structural property of the short-Weierstrass addition law -- and that is what belongs here. What makes it fire in a real system is a missing check: the software accepted a point without verifying it was on the intended curve. That trigger is an implementation gap, not curve mathematics, and this article deliberately stops at the mathematics.

This piece keeps a strict contract: it analyzes only the mathematics of the group. The moment a break depends on a missing input validation, a leaked nonce, a fault injected into a signature, a downgrade negotiated on the wire, or a manipulated parameter, it crosses into implementation and protocol territory. Those are the domain of the empirical sibling, "How Elliptic Curves and Diffie-Hellman Break in Real Life: PS3, CurveBall, Logjam, and Biased Nonces," which covers the PlayStation 3 repeated-nonce disaster, the CurveBall certificate-validation flaw, the Logjam downgrade handshake, and the biased-nonce lattice attacks. When you finish here knowing *which group properties* are dangerous, that article shows *how deployments trip over them*. The invalid-curve trigger -- "the code forgot to validate the point" -- is handed there in full.

Weil descent: a weakness chosen one level up, in the field

The last structural break in this pair does not need a bad curve so much as a badly chosen field. Some curves live over binary extension fields $\mathbb{F}_{2^n}$. When the extension degree $n$ is composite, a technique called Weil restriction can re-express the curve's group as points on a higher-genus curve over a smaller subfield -- and on that higher-genus object, index calculus applies and beats the generic square-root floor.

Gaudry, Hess, and Smart formalized this in 2002 [@ghs-2002], and the title of their paper is itself a summary of this whole section: "Constructive and destructive facets of Weil descent on elliptic curves." The precondition is structural and specific: a composite-degree binary extension field. The defense is equally specific: use prime fields, or at worst prime-degree extensions, so there is no subfield to descend into.

Every curve break in these two sections has needed a particular structural precondition -- trace one, small embedding degree, a smooth twist, $b$-independent arithmetic, a composite extension field. Not one has been a faster logarithm. Now cross the aisle to the group the whole field was fleeing in 1985. There, the structure is not an accident of a bad curve. It is built into the group itself.

6. The Finite-Field Side: When the Group Itself Has Structure

An anomalous curve is a bad choice -- pick a different curve and the weakness is gone. The multiplicative group $\mathbb{F}_p^*$ is different. It is not a bad choice; it is inherently structured. Its elements are ordinary integers, and integers can be multiplied and factored. That single property -- the one thing an elliptic-curve group pointedly does not have -- is exactly what the fastest classical attack needs.

Index calculus: turning multiplication into linear algebra

Fix a *factor base* of small primes. An element is *smooth* if it factors completely over that base. Index calculus hunts for powers $g^k$ that are smooth; each one factors as a product of factor-base primes, and taking logs turns that product into a *linear equation* relating the unknown logs of the base primes. Collect more smooth relations than there are base primes, solve the linear system once, and you know the log of every prime in the base. To finish a specific target $h$, nudge it by random powers of $g$ until $h \cdot g^k$ is smooth, and read the answer off the precomputed base logs.

Notice what index calculus consumes: the ability to factor group elements into small pieces. In $\mathbb{F}_p^*$ that ability is free, because the elements are integers. On an elliptic curve there is no such thing as a "small" point, no factor base, no notion of a smooth point at all. The attack has nothing to grip. That absence is not a minor detail -- it is the entire reason elliptic-curve cryptography exists.

The Number Field Sieve, pointed at the logarithm

The mature form of this idea is the Number Field Sieve. Built for factoring by Lenstra, Lenstra, Manasse, and Pollard in 1990 [@nfs-llmp-1990], it was adapted to the discrete log in a prime field by Daniel Gordon in 1993 [@gordon-1993].

Its pipeline has four stages: choose number fields tuned to $p$ (polynomial selection), sieve for smooth relations (relation collection), solve the resulting sparse linear system modulo the group order (linear algebra), and then peel off each individual target log (descent). The first three stages depend only on the prime $p$ -- a fact that looks academic here and becomes a weapon in the next section.

Cryptographers measure these costs with $L_p[\alpha, c] = \exp\!\big((c + o(1))(\ln p)^{\alpha}(\ln\ln p)^{1-\alpha}\big)$. The exponent $\alpha$ interpolates between two worlds: $\alpha = 1$ is fully exponential (Pollard rho on a $b$-bit group costs about $2^{b/2}$, an $L_p[1, 1/2]$ cost), and $\alpha = 0$ is polynomial. The Number Field Sieve sits at $\alpha = 1/3$, deep in *sub-exponential* territory -- vastly faster than the generic square root, and the same complexity class as integer factoring.

Gordon's 1993 algorithm put the finite-field discrete log in the sub-exponential $L_p[1/3]$ class, with heuristic constant $3^{2/3} \approx 2.08$ [@gordon-1993]; later refinements sharpened that constant to the modern $(64/9)^{1/3} \approx 1.923$. To feel what the difference between $\alpha = 1/2$ and $\alpha = 1/3$ does to real key sizes, run the estimator: the finite-field cost grows like a cube root of the bit length in the exponent, while the elliptic-curve cost grows linearly. That is why the two settings need such different key sizes for the same security.

{` import math

def nfs_bits(bits): # Leading-term model of the NFS-DL cost L_p[1/3, (64/9)^(1/3)] for a 'bits'-bit prime. lnp = bits * math.log(2) c = (64 / 9) ** (1 / 3) # about 1.923 return c * lnp ** (1/3) * math.log(lnp) ** (2/3) / math.log(2)

def rho_bits(order_bits): return order_bits / 2 # Pollard rho: half the bit length

print("Finite-field DH (cost grows like a cube root in the exponent):") for b in [512, 1024, 2048, 3072]: print(f" {b:>4}-bit prime ~ 2^{nfs_bits(b):5.1f}") print("Elliptic curve (cost grows linearly):") for m in [160, 224, 256]: print(f" {m:>4}-bit curve ~ 2^{rho_bits(m):5.1f}")

The leading term runs a little high; calibrated against real records, standard practice reads 1024-bit as roughly 80-bit and 3072-bit as roughly 128-bit security.

The scaling is the point. A clean 256-bit curve and a 3072-bit prime deliver comparable security -- the curve does it with an eighth of the key length -- precisely because the curve denies the sieve its factor base. This is the thesis at its sharpest: the same discrete logarithm, but a group whose structure leaks drops the attack from square-root time all the way to $L_p[1/3]$.

Same discrete log. On a generic curve, the largest ever solved is 112 bits and the records crawl. In a prime field, the record is 795 bits and climbing. The logarithm did not change -- the group did.

The records make the gap concrete. The current prime-field discrete-log record is 795 bits (240 decimal digits), set in 2019 by Boudot, Gaudry, Guillevic, Heninger, Thome, and Zimmermann, with the discrete-log computation costing roughly 3,100 core-years [@boudot-795bit-2020]; the previous record was 768 bits [@kleinjung-768bit-2017]. Against the 112-bit generic-curve ceiling of Section 3, the sieve's structural advantage is not subtle. The multiplicative group hands the attacker a factor base; the curve hands them nothing. The results corroborate the standard textbook accounting of index calculus and its consequences for finite-field sizing [@hac-1996].

A sub-exponential attack still sounds expensive -- years of computation for a single prime. So why is a 1024-bit Diffie-Hellman group a practical target rather than a merely theoretical one? Because the expensive part only has to be done once.

7. Logjam: Precomputation as a Structural Property

The most misunderstood word in forward secrecy is "fresh." A new ephemeral key on every connection feels like it should defeat any precomputed attack -- surely a one-time secret cannot be broken by work done in advance. Against a shared prime, that intuition is simply wrong, and seeing why is the sharpest lesson the finite-field side has to teach.

Recall the four stages of the Number Field Sieve. Three of them -- polynomial selection, relation collection, and the enormous linear-algebra solve -- depend only on the prime $p$. They produce the discrete logs of the entire factor base, and that output is reusable for every discrete log computed in that same prime field. Only the final descent step depends on the particular target. The Logjam researchers put it in one line on the project page: the first step of the number field sieve is dependent only on this prime [@logjam-adrian-2015].

flowchart TD subgraph PC["Precomputation, depends only on the prime p"] A[Polynomial selection] --> B[Relation collection by sieving] B --> C[Linear algebra, logs of the whole factor base] end C --> D[Per-target descent, one quick step per connection] D --> E[Discrete log of this specific ephemeral key] F[Every connection that shares p reuses the same precomputation] -.-> D

So a fresh ephemeral does not help if the prime behind it is shared and undersized. The attacker pays the sieve cost once, for the prime, and then every "fresh" handshake using that prime falls in the cheap descent step. Freshness protects the key; it does nothing for a shared group.

Note: Precomputation is not a shortcut around the math -- it is the structure being exploited. The weakness Logjam turns into a live threat is the amortized cost of a shared, undersized prime, spread across millions of connections. It is not a faster logarithm and not a smaller key in isolation. It is the fact that everyone reused the same group.

The blast radius came from exactly that reuse. A handful of 1024-bit primes were hard-coded into standards and shipped in software everywhere. Adrian and colleagues measured the exposure [@logjam-adrian-2015]. The immediate Logjam downgrade, forcing connections to 512-bit export-grade Diffie-Hellman, initially left 8.4% of the Top 1 Million HTTPS domains vulnerable.

Looking forward, a single precomputation against one common 1024-bit prime would let a passive eavesdropper read roughly 18% of the Top 1 Million HTTPS domains; precomputing a second common 1024-bit prime would reach about 66% of VPNs and 26% of SSH servers. A nation-state budget for one very large computation buys passive decryption of a striking fraction of the internet, all because the primes were shared.

Note: The lesson people take away from Logjam is usually "use bigger primes," and that is half right. The deeper point is that a 1024-bit prime is dangerous mainly because it is shared and precomputed, not merely because it is 1024 bits. A unique, per-organization 2048-bit or larger prime denies the attacker the amortization that makes the sieve economical at internet scale. Shared-and-precomputed versus unique is the real axis; size is secondary [@logjam-adrian-2015].

There is a further twist this article names only to hand off: a prime can be maliciously constructed so that a hidden special-number-field-sieve structure makes it far weaker than it looks, a trapdoor invisible to anyone who did not build it. That, along with the wire-level mechanics of how a downgrade is actually negotiated, is deployment and protocol territory -- the empirical sibling's ground, not this article's.

Logjam attacks a field whose prime was too small and, above all, shared. But there is a family of fields where the sieve does not merely amortize -- it changes complexity class entirely, from sub-exponential to almost polynomial. The only question is which fields, and the answer is, once again, a structural property someone chose.

8. Small Characteristic: The Quasi-Polynomial Frontier

For one specific family of fields, the discrete log came close to collapsing -- and the story teaches the same lesson one more time, in its most dramatic form: the characteristic you choose is a structural gift to the attacker.

Finite fields come in two flavors that matter here. Prime fields $\mathbb{F}p$ have large characteristic $p$. Extension fields like $\mathbb{F}{2^n}$ and $\mathbb{F}_{3^n}$ have small, fixed characteristic (2 or 3) and a large extension degree $n$. For decades both were treated as roughly comparable homes for the discrete log. Then, in the span of a few years, the small-characteristic case fell apart.

In 2013, Antoine Joux broke the long-standing $L[1/3]$ barrier for small-characteristic fields with a new index-calculus algorithm of complexity $L[1/4 + o(1)]$, published at Selected Areas in Cryptography [@joux-2013-l14]. That was the crack in the dam. In 2014, Barbulescu, Gaudry, Joux, and Thome went much further, giving a heuristic quasi-polynomial algorithm -- cost $n^{O(\log n)}$ -- for the discrete log in finite fields of small characteristic [@bgjt-2014]. Quasi-polynomial is not merely faster than sub-exponential; it is a different universe of growth, far below $L[1/3]$.

Then in 2019, Kleinjung and Wesolowski removed the heuristics, proving that the discrete log in a fixed-characteristic field can be solved in expected time $(pn)^{2\log_2(n) + O(1)}$ -- a genuine theorem, not a conjecture backed by experiments [@kleinjung-wesolowski-2019].

Why does small characteristic collapse when a prime field does not? The whole descent turns on one structural gift. In a field like $\mathbb{F}_{2^n}$ every element is a low-degree polynomial over a tiny base field, and the Frobenius map $x \mapsto x^p$ acts linearly on that representation, because $(a + b)^p = a^p + b^p$ in characteristic $p$. Those two facts hand the attacker a cheap, self-replenishing supply of low-degree relations: the algorithm presents the field through a low-degree identity linking an element to its Frobenius image, so a single relation spawns a whole orbit of them essentially for free.

The attack then descends on degree. It rewrites the logarithm of a degree-$d$ target as a combination of logarithms of strictly lower-degree elements, recurses ($d \to d/2 \to \cdots$), and bottoms out at degree-one elements whose logs are read off directly. Because each step roughly halves the degree while spawning only quasi-polynomially many sub-problems, the descent tree has depth about $\log d$ and terminates in $n^{O(\log n)}$ time -- that logarithmic recursion depth is exactly why the exponent is "quasi-," not fully, polynomial.

A prime field $\mathbb{F}_p^*$ offers none of this. Its elements are integers modulo $p$, with no subfield tower, no element degree to shrink, and no small-characteristic Frobenius to make relations cheap. The descent has nothing to grip, which is precisely why the Number Field Sieve at $L_p[1/3]$ stays the best attack there.

The practical consequence was immediate: this line of work retired small-characteristic pairing choices, including the supersingular binary curves once proposed for pairing-based cryptography, whose security rested on a small-characteristic field discrete log. The field that was supposed to be the hard part evaporated.

Note: The quasi-polynomial result applies to small, fixed characteristic only: $\mathbb{F}{2^n}$, $\mathbb{F}{3^n}$, and their relatives. It does not extend to prime fields $\mathbb{F}_p$, where the Number Field Sieve at $L_p[1/3]$ remains the best known attack. Dropping the words "small characteristic" would produce a dangerous falsehood -- that prime-field Diffie-Hellman is quasi-polynomially broken. It is not. Finite-field DH over a properly sized, unique prime is still standing; only the small-characteristic cousins collapsed [@kleinjung-wesolowski-2019].

The calibration is almost comical in scale. The record discrete log in a fixed-characteristic field now stands at $\mathrm{GF}(2^{30750})$, computed in 2019 [@disclog-records-wiki]. That field is roughly thirty-nine times larger in bit length than the 795-bit prime-field record from the same era. Same "discrete logarithm"; the characteristic of the chosen field decides whether the records sit near 800 bits or sail past 30,000.

This reinforced a standards trend already under way. NIST SP 800-186 deprecates the binary and Koblitz curves defined over small-characteristic fields, and FIPS 186-5 removes them from the approved list entirely [@nist-sp800-186]. The precision matters: deprecation and removal are two distinct regulatory steps, and the small-characteristic results are part of why both happened.

Eight sections, eight breaks, and one relentless pattern: every classical break so far -- Pohlig-Hellman, the anomalous transfer, MOV and Frey-Ruck, twists, invalid-curve shadows, Weil descent, the Number Field Sieve, and now small-characteristic descent -- needs a specific structural property of the chosen group. But a pattern is only convincing if you can see all of it at once. Lay every attack on a single table, and the thesis stops being a claim you have to trust and becomes something you can read straight off a column.

9. A Map of Where the Weakness Lives

One table, read down one column, is the whole argument. Here is every attack in this article, each with the structural property it requires, the easy group it reduces the log to, its cost, and the one question that matters -- does a well-chosen group have that property?

Attack	Group property it needs	Reduces the log to	Complexity	Clean group has it?
Pollard rho [@pollard-rho-1978]	none (generic)	nothing; it is the floor	$\approx 0.886\sqrt{\ell}$	the baseline
Pohlig-Hellman [@pohlig-hellman-1978]	smooth group order	small subgroups plus CRT	$\sum_i e_i(\log n + \sqrt{p_i})$	No: large prime order
Anomalous / SSSA [@smart-1999]	trace $t = 1$, so $#E = p$	addition in $(\mathbb{F}_p, +)$	polynomial	No: require $#E \neq p$
MOV / Frey-Ruck [@mov-1993]	small embedding degree $k$	DLP in $\mathbb{F}_{q^k}^*$	sub-exponential	No: large $k$
Twist confinement [@safecurves]	smooth twist plus x-only ladder	small subgroups on the twist	small-subgroup cost	No: twist-secure
Invalid-curve shadow [@biehl-meyer-muller-2000]	$b$-independent arithmetic plus weak shadow	small subgroups on a shadow curve	small-subgroup cost	No: twist-secure and validated
Weil descent / GHS [@ghs-2002]	composite-degree binary field	index calculus on a higher-genus curve	sub-exponential	No: prime field
NFS-DL [@gordon-1993]	a factor base (multiplicative smoothness)	linear algebra on smooth relations	$L_p[1/3,, 1.923]$	No: a curve has no factor base
Small-char quasi-poly [@kleinjung-wesolowski-2019]	small, fixed characteristic	function-field descent	quasi-polynomial	No: prime field
Shor [@shor-1997]	none (changes the machine)	quantum period-finding	polynomial in $\log \ell$	Yes, but needs a quantum computer

Key idea: Read the "group property it needs" column from top to bottom. Every classical attack that beats square-root time names a specific structural precondition -- a smooth order, trace one, low embedding degree, a smooth twist, $b$-independent arithmetic, a composite extension field, a factor base, small characteristic. The only two rows needing no structure are Pollard rho, which is the square-root floor, and Shor, which leaves the classical world entirely. Not one classical row is a faster generic logarithm. That is the thesis, rendered as a table.

The same pattern shows up in what a working engineer actually chooses between. Line up the deployed groups and the story is not "big keys versus small keys" -- it is "which structural weakness is present."

Group	Advertised security	Public-key size	Best known classical attack	Status
FFDH-1024 (shared prime)	about 80-bit, broken in practice	1024-bit	NFS-DL plus shared-prime precomputation [@logjam-adrian-2015]	Deprecated, nation-state target
FFDH-2048 / 3072 (shared or unique)	about 112 / 128-bit	2048 / 3072-bit	NFS-DL, but precomputation is infeasible at this size	Acceptable if unavoidable
NIST P-256	about 128-bit ($2^{127.8}$ rho)	256-bit	Pollard rho, generic [@safecurves]	Active, FIPS
Curve25519 / X25519	about 128-bit ($2^{125.8}$ rho)	256-bit	Pollard rho, generic [@safecurves]	Active, twist-secure and rigid

The two 256-bit curves and the 3072-bit prime all deliver about 128-bit security -- the curves with an eighth of the key length -- because a clean curve denies the sieve its factor base. And the two finite-field rows differ not by size alone but by sharing: the 1024-bit row is a target because its prime is common and precomputed, not merely because it is 1024 bits.

The table has one uncomfortable empty space. Every row is a break that needs structure, and a clean group has none of those structures. But is there a proof that a structure-free group is actually safe -- or have we simply never found the crack? To answer honestly, we have to admit what the entire edifice rests on.

10. Theoretical Limits: Is the Log Itself Ever the Weak Part?

Here is the admission the whole subject rests on, and it is more unsettling than most textbooks let on: nobody has proved the discrete log is hard. Not for $\mathbb{F}_p^*$, not for a clean elliptic curve, not for any group that carries real traffic. The security of a large fraction of the internet rests on a problem no one can prove is difficult.

The only proven wall is Shoup's $\Omega(\sqrt{\ell})$ lower bound from Section 3 [@shoup-1997] -- and its scope is precisely the catch. It holds in the generic-group model, where the algorithm may not read anything from the encoding of group elements. It is a statement about structure-blind algorithms, not about the discrete log as such.

This is exactly why index calculus is not a paradox. The Number Field Sieve beats Shoup's $\sqrt{\ell}$ floor for $\mathbb{F}_p^$ not because the proof is wrong but because $\mathbb{F}_p^$ is not a generic group: its elements are integers, the algorithm reads their factorizations, and the generic model's central assumption simply does not apply. Every faster attack in this article is another group that leaves the generic model through some door of its own. The matching bound of Section 3 is real, and it is real only inside a model that structured groups escape.

The gap has two values, and keeping them straight is the difference between understanding this subject and sloganeering about it. *In the generic-group model* the question is CLOSED: Pollard rho's $O(\sqrt{\ell})$ upper bound meets Shoup's $\Omega(\sqrt{\ell})$ lower bound at $\Theta(\sqrt{\ell})$, a rare matching pair. *Unconditionally* it is WIDE OPEN: there is no proof the discrete log is hard at all. The space between the generic wall and reality is exactly what index calculus and the curve transfers exploit. And there is a structural reason a hardness proof is out of reach: the DLP lies in $\mathrm{NP} \cap \mathrm{coNP}$ -- given the factorization of the group order, both a claimed logarithm and its absence are efficiently checkable -- so it is *not expected* to be NP-complete, since an NP-complete problem in $\mathrm{NP} \cap \mathrm{coNP}$ would collapse $\mathrm{NP} = \mathrm{coNP}$ [@galbraith-2012] [@hac-1996]. Proving the discrete log hard would be a complexity-theory landmark far beyond anything currently in reach. That is why "only Shor breaks a clean group" must always be read "as far as is known."

The sharpest open question sits one level down, and it is the one that keeps elliptic-curve cryptographers honest: does a sub-exponential, index-calculus-style algorithm exist for the ECDLP over a prime field? If it did, it would do to elliptic curves what the Number Field Sieve did to finite-field Diffie-Hellman -- collapse the square-root advantage that justifies 256-bit keys.

This is the correct home for Semaev's summation polynomials and the related Gröbner-basis point-decomposition program, from 2004 onward [@semaev-2004] -- a genuine attempt to build an ECDLP index calculus. It must not be confused with the 1998-99 anomalous-curve transfer of Section 4, which is a different mechanism entirely. Over prime fields the summation-polynomial approach remains exponential: it is the live frontier, not a solved attack.

So, classically and as far as anyone knows, a clean group leaves the square-root floor standing. There is no known sub-exponential attack on a well-chosen prime-field curve, and the conjecture that none exists is exactly that -- a conjecture, the working hypothesis behind every ECC key-size recommendation.

Even the improvements that do exist stay on their side of the line. The extended Tower Number Field Sieve of Kim and Barbulescu sharpens the constants for medium- and non-prime-characteristic fields, but it does not move the $1/3$ exponent for prime fields [@kim-barbulescu-2016]. Prime-field discrete logs have been stuck at $L_p[1/3]$ since Gordon in 1993.

If the log's classical hardness is unproven yet unbroken on a clean group, then the only known way to break such a group is not a cleverer algorithm in the same world. It is to change worlds -- to a machine that computes on a fundamentally different substrate.

11. The Third Road: Shor, and Why a Clean Group Leaves Only Quantum

Strip a group of every exploitable structure and the classical attacker is back at Pollard's 1978 random walk, hitting the square-root wall with no crack to exploit. The one thing left that beats that wall does not compute a cleverer logarithm. It runs on a different machine.

In 1994, Peter Shor showed that a quantum computer could solve both integer factoring and the discrete log in polynomial time [@shor-1997]. The discrete-log algorithm does not attack the group's structure the way index calculus does. It rewrites the problem into a shape a quantum computer is uniquely good at.Framed abstractly, Shor's discrete-log routine solves a hidden subgroup problem: the secret $x$ hides a subgroup of $\mathbb{Z}\ell \times \mathbb{Z}\ell$ generated by $(x, 1)$, and the quantum Fourier transform is the tool that exposes it [@childs-vandam-2010]. The abelian hidden-subgroup problem is the common engine behind Shor's factoring and discrete-log algorithms alike.

Shor's move is to recast the discrete log as *period-finding*. From the target one builds a function whose period encodes the secret exponent $x$. A classical machine cannot see that period without effectively searching for it, but a quantum machine can evaluate the function over a superposition of inputs and apply the quantum Fourier transform, which concentrates measurement probability on the period. Each measurement then returns a pair $(\alpha, \beta)$ obeying a linear relation $\alpha x + \beta \equiv 0 \pmod{\ell}$, and a few such relations pin down $x$ by classical linear algebra mod $\ell$ -- not the continued-fractions step that finishes Shor's *factoring* routine. flowchart TD A[Target: Q equals x times P on a clean curve] --> B[Build a function periodic in the unknown x] B --> C[Evaluate it over a superposition on the quantum register] C --> D[Quantum Fourier transform makes the period observable] D --> E[Measure: each shot yields a linear relation in x, mod l] E --> F[Solve the linear congruences for the discrete log x, polynomial in log of the order]

The consequence is the one classical cryptanalysis can never deliver: the cost is polynomial in $\log \ell$, so key size is no defense. Doubling the curve size barely moves Shor's cost. And it needs none of the structural preconditions from the table in Section 9 -- no trace one, no small embedding degree, no smooth twist, no factor base. It breaks a correct key on a flawless group. Shor is the empty cell filled in: the only known attack that does not require the group to be badly chosen.

Crucially, the progress since 1994 has been algorithmic, not hardware. The first ECDLP-specific quantum circuit came from Proos and Zalka in 2003, who made a structural observation that still holds: elliptic curves are an easier quantum target than equal-security RSA [@proos-zalka-2003].

The modern resource estimate, from Roetteler, Naehrig, Svore, and Lauter in 2017, is concrete: a 256-bit ECDLP needs about 2,330 logical qubits -- following their count of $9n + 2\lceil\log_2 n\rceil + 10$, which for $n = 256$ gives $2304 + 16 + 10 = 2330$ -- and on the order of $1.3 \times 10^{11}$ Toffoli gates, versus roughly 6,146 logical qubits for RSA-3072 [@roetteler-2017]. The curve's small keys, its great classical advantage, make it the cheaper thing to break once a quantum computer exists.

Note: Shor is structural mathematics against an asymmetric primitive: it breaks the discrete-log problem itself, in polynomial time, on a flawless group -- squarely the subject of this article. Grover's algorithm is a different animal: a generic square-root speedup for unstructured search that halves the effective key length of symmetric ciphers and hashes. It is not a structural break of the discrete log, and simply doubling a symmetric key neutralizes it. Grover is named here only to be set aside.

Two honest boundaries close this section. First, no cryptographically-relevant quantum computer exists today, and this article asserts no timeline for when, or whether, one will. The resource estimates set a migration clock, not a countdown. Second, the genuine successor to discrete-log cryptography is post-quantum cryptography -- schemes built on entirely different hard problems such as lattices, error-correcting codes, and hash functions. That is a separate research program, out of scope here, and its independence is the point: it is not a faster discrete log but a different foundation.

That post-quantum cryptography is a genuinely different problem, not a continuation of the discrete-log genealogy, is underscored by how young and unsettled it still is: several proposed post-quantum schemes have themselves been broken during standardization -- the SIDH/SIKE isogeny key-exchange scheme fell to an efficient classical key-recovery attack [@castryck-decru-2022], and the Rainbow signature finalist was broken on a laptop in a single weekend [@beullens-2022] -- which would be impossible if they were merely the discrete log in disguise. Different problems fail in different ways.

So the mathematics is settled enough to act on. Choose a group with no weak part, and the classical attacker is stranded at the square-root floor; the only remaining break is one you cannot out-size, and the response to it is migration, not a bigger key. That leaves one practical question: how do you actually choose a group with no weak part? Every criterion is a scar from an attack in this article.

12. Choosing a Group With No Weak Part

Every line on a curve-selection checklist is a scar from a specific attack in this article. Read the checklist not as arbitrary hygiene but as a map of defeated enemies -- each criterion exists because someone, somewhere, lost a key to the attack it blocks.

Criterion	Attack it defeats
Large prime subgroup order	Pohlig-Hellman [@pohlig-hellman-1978]
Small cofactor	small-subgroup leakage
Trace not one, so $#E \neq p$	anomalous / SSSA transfer [@smart-1999]
Large embedding degree	MOV / Frey-Ruck [@mov-1993]
Twist-security (curve and twist near-prime order)	twist confinement; in a single-coordinate ladder it also confines an off-curve input to the secure twist. The full-coordinate invalid-curve shadow needs input-point validation instead, an implementation check handed to the sibling [@safecurves] [@biehl-meyer-muller-2000]
Prime field, no small characteristic, no composite extension	Weil descent / GHS [@ghs-2002], small-char quasi-poly [@kleinjung-wesolowski-2019]
Rigidity (fully explained, manipulation-resistant parameters)	hidden-structure and backdoor suspicion [@bernstein-curve25519-2006]

Two of these checks are easy enough to run on a toy example, which makes the abstract concrete: a curve is anomalous exactly when its point count equals the field prime, and it has a dangerous embedding degree exactly when the subgroup order divides $p^k - 1$ for some small $k$.

{` def embedding_degree(l, p, bound=200): # least k with l dividing p^k - 1; small k means a MOV / Frey-Ruck door r = p % l for k in range(1, bound + 1): if r == 1: return k r = (r * p) % l return None # beyond the search bound: safely large

def score(p, n, l): flags = [] if n == p: flags.append("ANOMALOUS: #E equals p, trace one -> polynomial-time SSSA transfer") if n % l == 0: k = embedding_degree(l, p) if k is not None and k <= 6: flags.append("LOW EMBEDDING DEGREE k=" + str(k) + " -> MOV / Frey-Ruck transfer") if n // l > 8: flags.append("LARGE COFACTOR " + str(n // l) + " -> small-subgroup leakage") else: flags.append("subgroup order does not divide the point count (bad parameters)") return flags or ["no structural red flag on these two checks"]

print("anomalous toy (p = n = 23):", score(23, 23, 23)) print("low-k toy (p=23, points=24, order=3):", score(23, 24, 3)) print("clean toy (p=101, points=order=83):", score(101, 83, 83)) `}

The decision, in one flow

flowchart TD A{"What are you building?"} -->|New system, free choice| B[X25519 for key exchange, Ed25519 for signatures] A -->|FIPS-constrained| C[NIST P-256] A -->|Finite-field DH is forced| D[A standard RFC 7919 group of at least 2048 bits, never a shared 1024-bit prime] B --> E[Verify large prime order, small cofactor, trace not one, large embedding degree, twist-secure, rigid] C --> E D --> F[Plan a post-quantum or hybrid migration for the Shor horizon] E --> F

For a new system with a free hand, use X25519 for key exchange and Ed25519 for signatures [@rfc7748] [@rfc8032]: they are twist-secure and rigid by construction, and they close every classical door in the table above. Where a standard mandates the NIST curves, P-256 is a sound choice with the same generic-floor security [@nist-sp800-186]. If finite-field Diffie-Hellman is genuinely unavoidable, use a standard RFC 7919 group of at least 2048 bits -- its shared named groups are safe at this size because the sieve precomputation is infeasible -- or a dedicated unique prime; never a shared or legacy 1024-bit prime, whose danger was the entire lesson of Logjam [@rfc7919].

And across the board, avoid the families this article condemned: anomalous curves, low-embedding-degree curves, small-characteristic fields, and the binary and Koblitz curves that NIST now deprecates and FIPS 186-5 removes [@nist-sp800-186].

Note: For roughly 128-bit security you can carry a 256-bit elliptic-curve key or a 3072-bit finite-field prime -- an eighth of the size for the same strength, with the gap widening at higher security levels. That is not a small optimization; it is why elliptic curves dominate new deployments. Unless a specific standard forces finite-field Diffie-Hellman, prefer X25519 and Ed25519 for smaller keys and faster, twist-secure operations [@safecurves] [@rfc7748].

One caveat belongs to the sibling article, not this one: choosing a strong group is necessary but not sufficient. A flawless curve still fails if the software forgets to validate an input point, reuses a nonce, or leaks timing -- the implementation failures catalogued in "How Elliptic Curves and Diffie-Hellman Break in Real Life." This article guarantees only that the mathematics of a well-chosen group offers no purchase. The code still has to hold up its end.

That covers what to do. The questions careful engineers keep asking -- and the misconceptions that trip up even good ones -- deserve direct answers.

13. Frequently Asked Questions

No -- it gives about 128-bit security. Because Pollard rho solves the discrete log in roughly the square root of the group order, a 256-bit curve is a $2^{128}$ target, not a $2^{256}$ one. SafeCurves lists NIST P-256 at about $2^{127.8}$ and Curve25519 at about $2^{125.8}$ operations [@safecurves]. The bit length of the key is double the security level, not equal to it. Only for two of the problems. A bigger key raises the generic square-root floor, and a larger, unique prime defeats undersized or shared finite-field Diffie-Hellman. But a *structural* break ignores key size entirely: an anomalous curve falls in polynomial time regardless of its bit length [@smart-1999], a shared precomputed prime falls no matter how fresh the ephemeral [@logjam-adrian-2015], and Shor is polynomial in the log of the order, so doubling the curve barely moves its cost [@shor-1997]. Against structure, size is no defense. No. On a well-chosen group it is, as far as anyone knows, as hard as it can be -- the best generic attack is Pollard rho, and Shoup proved no generic algorithm does better [@shoup-1997]. Every real break in the literature exploited a structural property of a *chosen* group, not the logarithm itself. The honest caveat is that elliptic-curve discrete-log hardness is *unproven*: no one can prove it is hard, only observe that no one has broken a clean curve. Because $\mathbb{F}_p^*$ has a factor base and a clean curve does not. The multiplicative group's elements are integers you can factor, which is exactly what the sub-exponential Number Field Sieve needs [@gordon-1993]. A well-chosen elliptic curve has no notion of a "smooth" point, so the sieve has nothing to grip, and the best attack stays at the square-root floor. The Logjam exposure came from that structural difference meeting a shared, undersized prime [@logjam-adrian-2015]. No. The expensive first stage of the Number Field Sieve depends only on the *prime*, not on any individual key, so it amortizes across every connection that shares that prime [@logjam-adrian-2015]. Freshness protects the ephemeral key; it does nothing about a shared group. A unique prime, not a fresh ephemeral, is what denies the attacker the precomputation. Shor. It reduces the discrete log to quantum period-finding and solves it in polynomial time on a flawless group, which is a structural break and squarely in scope [@shor-1997]. Grover's algorithm is only a generic square-root speedup for unstructured search; it shortens *symmetric* keys and is neutralized by doubling them. Grover is not a structural break of the discrete log at all, and it is named here only to be set aside. No. The only proven wall is Shoup's $\Omega(\sqrt{\ell})$ lower bound, and it holds only in the *generic-group* model -- index calculus beats it for $\mathbb{F}_p^*$ precisely because that group is not generic [@shoup-1997]. There is no unconditional hardness proof, and one is not expected soon: the discrete log sits in $\mathrm{NP} \cap \mathrm{coNP}$, so it is believed not to be NP-complete, which puts a hardness proof far beyond current complexity theory [@galbraith-2012]. "Only Shor breaks a clean group" always carries the silent rider "as far as is known."

The Log Was Never the Weak Part

Return to the four groups from the opening. NIST P-256 and Curve25519 stand at about $2^{128}$ because they have large prime order, trace not one, large embedding degree, twist-security, and rigid parameters -- every structural door bolted shut, leaving only the square-root floor.

The third 256-bit curve dies in polynomial time for one reason: its trace is one, so its log transfers into simple addition. And the 1024-bit finite-field group is a nation-state target because its group is inherently factorable and its prime was shared and precomputed. Four groups, the same discrete logarithm, three different fates -- and in every case the deciding variable was the group.

Same discrete log, radically different fates. The variable was never the logarithm. It was the group.

That is the pattern under all ten attacks. Pohlig-Hellman needs a smooth order. The anomalous transfer needs trace one. MOV and Frey-Ruck need a small embedding degree. Twist attacks need a smooth twist. Invalid-curve shadows need $b$-independent arithmetic. Weil descent needs a composite extension field. The Number Field Sieve needs a factor base. Logjam needs a shared prime. Small-characteristic descent needs a small characteristic. Every classical break is a receipt for a structural property of a chosen group, and never once a faster generic logarithm.

Key idea: Strip a group of every exploitable structure -- give it a large prime order, a small cofactor, trace not one, a large embedding degree, twist-security, rigidity, a prime field, no small characteristic, and a unique well-sized prime -- and the classical attacker is thrown all the way back to Pollard's 1978 random walk. The only thing left that beats it does not compute a cleverer logarithm; it changes the machine. The logarithm was never the weak part. The group always was.

Which is why the rational response has two halves. Choose a clean group -- the checklist in Section 12 is really a list of defeated attacks -- and begin preparing for the one break you cannot out-size, by planning the migration to post-quantum primitives before a quantum computer forces the issue.

For the failures that live in code rather than mathematics -- unvalidated points, repeated nonces, timing leaks, negotiated downgrades -- turn to the empirical sibling, "How Elliptic Curves and Diffie-Hellman Break in Real Life." The mathematics here gives you a group with no weak part. The engineering there decides whether your system keeps it that way.

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.