Switch to better hash to curve #46
Conversation
| >::new(DST_G1) | ||
| .unwrap(); | ||
| wb_to_curve_hasher.hash(message).unwrap().into() | ||
| } |
There was a problem hiding this comment.
Arkworks' H2C interface is kinda garbage btw. I need to split up arkworks-rs/algebra#643 so it can be merged.
|
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. |
|
@swasilyev I think follow the hash_to_curve spec is better. |
|
Then, i think, the standard suggests using Elligator 2 for BLS12-377, as it does have a twisted Edwards form. |
|
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. |
|
@swasilyev Another question, I see gnark use simplified-swu-method in BLS12-377.
And BLS12-377 also have a Weierstrass form. What do you think of this? |
|
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. |
No description provided.