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.
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.
-
And oh, eh, hehe, https://github.com/bwesterb/go-ristretto/blob/el2inv/ristretto.go#L193 … (although here, the use cases are slightly different - the reverse operation is possible).
End of conversation
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.