BN254 - Hash-to-Curve (SVDW method)

[mratsim]

This adds hash-to-curve with BN254 Snarks.

For use in Codex (cc @cskiraly)

Unfortunately there is no isogeny of degree less than 30 that would allow us to use the SSWU method (Simplified Shallue-Van Woestijne-Ulas) and so we use the generic SVDW method (Shallue-Van Woestijne) which is slower due to 2 Legendre symbols+square root+inversion.

The SVDW code path is tested with with the old v7 vectors for BLS12-381.

Note: for BN254-snarks, the usual deployed hash to curve is Fouque-Tibouchi method

FT12: Fouque and Tibouchi,
"Indifferentiable hashing to Barreto-Naehrig curves."
Proc. LATINCRYPT, 2012.

It is in particular the one:

• deployed in MCL: https://github.com/herumi/mcl/blob/1e797b8b2ae165c45330ea030ed382b67c38c3cf/include/mcl/bn.hpp#L331-L369=
• suggested as an EIP in https://eips.ethereum.org/EIPS/eip-3068
• used in L2 like probably Loopring (which uses MCL):

SVDW mapping is used by Constantine, gnark and it might be used by Hubble (cc @ChihChengLiang) as Hubble uses a mix of the IETF hashing_to_curve spec + the Fouque-Tibouchi method from MCL:

• https://github.com/thehubbleproject/hubble-bls/blob/b377044abb5d5bca441647a748219e5adbd556f6/src/hashToField.ts
• https://github.com/thehubbleproject/hubble-bls/blob/8e051baabf82247060aae936e0970eb4bbb89a1e/src/mcl.ts#L47-L64=
• https://github.com/herumi/mcl/blob/1e797b8b2ae165c45330ea030ed382b67c38c3cf/include/mcl/bn.hpp#L561-L569= (FpToG1 is hashing_to_curve for BLS12 while mapToEC is Fouque-Tibouche for BN curve and Fouque-Tibouchi is ~SVDW)

FT12 seems to be similar to "encode_to_curve" in the H2C spec due to non-uniformity (NU) rising from modular arithmetic while hashing_to_curve maps to 2 points that are then summed to combat bias.

Compared to SSWU mapping: https://github.com/kwantam/bls12-381_hash#bib

The SvdW map is similar to the one described in FT12, except that our construction is defined at every point in the base field. This may simplify constant-time implementations.

The SWU map uses two new tricks to speed up evaluation. It also uses only field operations, and in particular does not require fast Legendre symbol or extended Euclidean algorithms, which the SvdW map requires for efficiency. This simplifies implementation---especially constant-time implementation---since both of those algorithms would require implementing arbitrary modular reductions rather than reductions modulo a fixed prime.

[mratsim]

Note: if hashing becomes a bottleneck for Codex, we might be able to adapt the faster hashing from @dishport described here:

• New faster indifferentiable hash functions to elliptic curves, including BLS12-381 cfrg/draft-irtf-cfrg-hash-to-curve#316
• https://link.springer.com/article/10.1007/s10623-022-01012-8
• https://link.springer.com/article/10.1007/s12095-021-00478-y
• https://eprint.iacr.org/2021/301
• https://eprint.iacr.org/2021/678
• https://eprint.iacr.org/2021/1034
• https://eprint.iacr.org/2021/1082

We can even draft an EIP to push standardization at the Ethereum-level.

[mratsim]

Benches: