Switch to better hash to curve

[swasilyev]

Please explain what "better" stays here for. For the sake of a padding point, try-and-increment is not worse than anything else, including a hardcoded point. Also hard to review with all the formatting changes.

[hujw77]

@swasilyev I think follow the hash_to_curve spec is better.

[swasilyev]

Then, i think, the standard suggests using Elligator 2 for BLS12-377, as it does have a twisted Edwards form.

[burdges]

Yes, arkworks h2c is currently fucked since it does not really work for anything besides bls12-381. The H2c spec caused the problem by not being too friendly to polymorphic implementations. We'll fix it but bigger priorities this week.

[hujw77]

@swasilyev Another question, I see gnark use simplified-swu-method in BLS12-377.

• https://github.com/Consensys/gnark-crypto/blob/208eeba5a82c069ec6cb51b2f82abaa6c7c870f4/ecc/bls12-377/hash_to_g1.go#L171
• https://github.com/Consensys/gnark-crypto/blob/208eeba5a82c069ec6cb51b2f82abaa6c7c870f4/ecc/bls12-377/hash_to_g2.go#L618

And BLS12-377 also have a Weierstrass form. What do you think of this?

[burdges]

It's gnark's mistake. All curves have a short Weierstrass form. Elligator 2 is a much nicer hash-to-curve, so it should always be preferred for curves with an Edwards form, like BLS12-377.

An application might ignore this advice if they foresee never implementing the Edwards form, but a framework like Arkworks should always favor the faster & cleaner Elligator 2 when available.