The Ristretto specification defines a way to do hash-to-curve. The hash-to-curve draft and other drafts (such as the one on OPRFs) recommend doing it using hashtobase+elligator2 as with Ed25519 instead. A forthcoming paper is going to propose a 3rd way. This is annoying.
And people who don’t want things to be slow for the sake of eliminating a virtually nonexistent bias will simply map a random 255 bit string.
-
-
Or 256 bit, depending on what the 2^255-19 field arithmetic implementation can reduce.
-
“This is compatible with the RFC, but you have to use a specific function if this is really what you want. By default, we don’t want to be twice as slow” https://github.com/bwesterb/go-ristretto#compatibility-with-ristretto255-rfc-draft … - And both are still different from what the hash-to-curve draft says.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.