Closed kwantam closed 4 years ago
cc @armfazh @grittygrease @chris-wood
Yeah, I think this makes sense. It likely needs to be written down somewhere, and I really don't have a strong feeling as to where it goes. The only oddity about making this a suite is that the document's title is "hash to curve," whereas Ristretto isn't "really" a curve.
Hot take: Ristretto really is a curve, it's just dressed up in a funny way :smile:
I can write something down later today or tomorrow. I think it'll be in an appx since it won't follow the required format of a suite, but we can play around with it and see what works best once we have some text.
Hot take: Ristretto really is a curve, it's just dressed up in a funny way 😄
Hah, okay, fine. I was speaking in terms of the API.
An alternative way is to describe how the output of one of the h2c ciphersuites can actually be used to generate a ristretto element. For example:
def h2c_ristretto(msg,dst):
P = edwards25519_XMD:SHA-512_ELL2_RO_(msg, DST)
return P as ristrettoPoint
This seems completely possible. I worry that the Ristretto authors would get annoyed by this since it completely sidesteps the "this is not a curve" abstraction they're trying to build. (And in fact when I've spoken with them about ~exactly~ something like this proposal in the past they were explicitly not happy about it for that reason.)
By the way, apologies that I have not yet written this down---trying to push something else towards completion. I will aim to have it done in the next couple days, and certainly before the end of the weekend.
Agreed. I think we should not break that abstraction, even if it may be correct.
This is a contentious enough point that it should be discussed on-list.
On Thu, Aug 6, 2020 at 12:21 PM Christopher Wood notifications@github.com wrote:
Agreed. I think we should not break that abstraction, even if it may be correct.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/291#issuecomment-670145784, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHDHZ2MPXRYW6UEHJRQ2IDR7L7B7ANCNFSM4PTSWOCA .
I know this is something we've discussed before (certainly @chris-wood and I have), but:
Would it make sense for us to add (say, in an appendix) a suggested way of composing the h2c primitives with the Ristretto FROM_UNIFORM_BYTES API? I've gotten a few questions about this from folks implementing VOPRFs on ristretto255, and my impression is that the Ristretto authors are adamant about wanting no mention of hash functions in their document.
The obvious suggestion for ristretto255 is to pick a DST and call
FROM_UNIFORM_BYTES(expand_message_XXX(msg, DST, 64))
. Honestly, I'd even be OK mentioning this in the Suites section...