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.
-
-
Replying to @jedisct1
everything ends up being summarized in that rfc right :P?
2 replies 0 retweets 0 likes -
Replying to @cryptodavidw
Which RFC? A RFC summarizing what parts of conflicting RFCs should be considered?
2 replies 0 retweets 1 like -
Replying to @jedisct11 reply 0 retweets 0 likes
-
Replying to @cryptodavidw
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.
1 reply 0 retweets 0 likes -
Replying to @jedisct1 @cryptodavidw
Or 256 bit, depending on what the 2^255-19 field arithmetic implementation can reduce.
1 reply 0 retweets 0 likes -
Replying to @jedisct1 @cryptodavidw
“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 reply 0 retweets 0 likes
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).
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.