Re: [Cfrg] I-D Action: draft-irtf-cfrg-hash-to-curve-08.txt

[Christopher Wood <[e-mail]>]

Hi Marek,

Thanks for the feedback! Please see inline below.

On Thu, Jun 11, 2020, at 6:08 AM, Marek Jankowski wrote:
> Hi Chris,
> I think this is a great draft - it explains very well hashing to 
> curves, which is vital for many new applications that I hope to see 
> coming, mainly those using pairings.
> The section about domain separation is very important and I'm glad to 
> see it explained explicitly and thoroughly.
> Here are a few suggestions, most of them minor:
> a. I think Table 1 (Sec. 2.1) could be better formatted, using less 
> line breaks. Please consider redistributing the widths of the columns.

I'll see if we can clean this up:

   https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/279

> b. The second paragraph in 2.2.1 can be simplified: it suffices to say 
> it needs not be bijective/surjective/injective. Also I'm not entirely 
> sure it's best practice to use the term 'invertible' for just 
> _efficiently_ reversible functions.

This seems to be the term used in literature. Would you prefer it say, "efficiently reversible" instead of "invertible"?

> c. I think a better formulation in the first paragraph in 2.2.5 is 
> something like "...assuming the attacker accesses RO only through the 
> protocol, viz. the RO is not used elsewhere."
> d. The word 'encode' (Sec. 3) implies that its output can be decoded. 
> Perhaps there's a better word for noninvertible maps.

I'm less certain about this one, as encode is a fundamental concept in the document. I think the text in 2.2.2. makes it clear that some encodings may be invertible, so I'm not sure this is an issue. (I recognize that view may not be universal. :-))

What word would you recommend instead?

> e. Domain separation (Sec. 3.1): I believe that if needed for backwards 
> compatibility, it is not a disaster if we omit the version number from 
> the Tag. Maybe it is worth a "NOT RECOMMENDED".

That's a good point worth considering:

   https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/280

> f. It says that expand_message MUST NOT use rejection sampling (5.3.4). 
> To the best of my understanding, rejection sampling is to be avoided 
> for the sole purpose of mitigating side channel attacks; this is 
> defined (Sec. 4) as a SHOULD, so I believe this SHOULD should (no pun 
> intended :-) propagate there.

Great catch. This is an inconsistency:

   https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/281

> g. Do we really want to approve as many curves as in [Table 2, Sec. 8]? 
> We are standardizing something new here, so we can allow ourselves to 
> stick to just the best curves. In my opinion Curve25519 is in every way 
> superior to the NIST curve of the same strength, so the latter can be 
> omitted.

We want this document to be maximally useful to implementers who may have a need for NIST curves. Omitting them seems like it would defeat the purpose of the document. So, I'm strongly inclined to keep them. 

> Again, I am very supportive of the draft and will be happy to further 
> help in the process.

And we appreciate your help and input -- thanks again!

Best,
Chris