Fast hashing into elliptic curve

Question

Is there a fast algorithm for mapping $n$-bit numbers $s$ (for fixed $n$) into a cyclic subgroup of an elliptic curve (over a finite field) in which the Discrete Logarithm Problem is hard?

By fast, I mean it takes about as long as a point addition (and is much faster than a point scalar multiplication in the elliptic curve group, or an exponentiation operation in the finite field).

The mapping: $s \rightarrow s \cdot G$, for some generator $G$, would be too slow, and also would defeat the security of construction since the discrete logarithm with respect to $G$ would be known.

It is not necessary for the running time to be independent of the input. For instance, for elliptic curves defined by

$y^2 = x^3 + ax + b$

over the finite field $F_p$, there is the standard method of setting $x = s \bmod p$, and then computing the square root of $x^3 + ax + b$. If $p = 3 \bmod 4$, then we can compute the square root using exponentiation in the finite field. If the square root does not exist, we increment $x$ and try again. In this way we can obtain a point in the elliptic curve group, and if our cyclic subgroup has cofactor 1, then we are done. This method would be valid except that computing the square root via exponentiation takes significantly more time than a point addition.

Is there some method/choice of elliptic curve that allows a much more efficient mapping to be defined?

The speed I'm looking to beat (in order for this construction to be faster than an alternative that does not use elliptic curves) is around 100000 operations (hashes to curve points) per second on a standard single CPU core (e.g. 3.2GHz Nehalem) with a 256-bit elliptic curve. Testing with libsecp256k1, which seems to include an optimized square root implementation, I can compute only about 77000 square roots per second.

Answer 1

Over large characteristic fields, I am not aware of any "point generation method" that can be computed faster than a base field exponentiation, and I would be very surprised if such a thing existed even if you do not require constant running time. So your best bet in general is probably Icart's function (I'd pick that one over Elligator if I didn't need injectivity), which won't be fast enough for your purposes.

Over binary and ternary fields, however, it is possible to do better. For example, in the binary field case, you can use the binary Shallue–van de Woestijne encoding, which can be computed with simple base field arithmetic and half-traces, as discussed by Brier et al. in Appendix E of this paper.

Some colleagues and I have an implementation paper that should appear on the IACR ePrint archive shortly, and it computes that function to a 254-bit binary curve in well under 10,000 Haswell cycles, so your goal is easy to achieve on newer CPU architectures (I think recent AMD CPUs should be quite fast as well). Nehalem doesn't have a carry-less multiplier, however, so binary field arithmetic might be quite slow in practice on that architecture.

Incidentally, as this question falls squarely within my research interests, I'm quite curious about your concrete use case if you can say something about it.

Answer 2

The simpler answer is probably Elligator and Edwards curves (see also Fouque et al). The more general answer is the hash function

$$ H(u, v) = f(u) + f(v), $$

where $f$ is the Shallue-Woestijne-Ulas algorithm, and $u$ and $v$ are random $\mathbb{F}_p$ elements (perhaps obtained by $h_1(s)$ and $h_2(s)$, where $h_i$ hash bitstrings into $\mathbb{F}_p$). This construction was proven indifferentiable from a random oracle by Farashahi et al. Elligator squared adapts this approach to make the map invertible.

Each of these methods still requires square-root computations, however, as far as I can tell. But the cost should still be much lower than a point multiplication.

Answer 3

I had the same problem, but I found a solution:

Using the heavier $a^\frac{p+1}{4}$ to calculate the square root, hash to a set of points to create agreed upon $\{H_i\}_{i=0}^n$ that no one will know the discrete log to. The $n$ I choose is $log_2(p) / 2$. Now, we can define:

$H_E(P) = \sum_{i=0}^n H_Z(P)[i] \cdot H_i$

Where $G$ is our generator, and $H_Z(P)$ is a hashing function the maps points in the elliptic curve to the integers. This creates a random point, that no one will know the discrete log to, since it's a random combination of points that no one knows the discrete log to. I defined the bracket operator to mean extract the $i$th bit from $H_Z(P)$, so that we essentially are choosing between adding or not adding a given $H_i$. This takes on average $log_2(p)/4$ additions, which is semiclose to the processing power of multiplying but the speed difference did make a difference in my case at least so it might make a difference in yours (It requires 1/6 the amount of additions than multiplication does).

Note that an ECC curve with $n$ bits in $p$ has security $n/2$, which is why we can use only half the bits in the hash but still providing the same level of security.

Answer 4

There is a pending standard that specifies ways of hashing to elliptic curves of various types. It's called hash-to-curve: https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/

Currently it describes hashing to NIST curves, curve25519, curve448, secp256k1 and bls12-381.