Subject: Re: [Cfrg] Comments on draft-irtf-cfrg-hash-to-curve

From: Christopher Wood <[email-masked]>
Date: Sat, 1 Sep 2018 16:11:42 -0700

Hi Marek,

On Thu, Aug 30, 2018 at 4:46 AM Marek Jankowski <[email-masked]> wrote:
>
> With regard to the tables in section 3 - I felt that I had to read them again to understand how they were supposed to be used. I think that a usage example will resolve the issue.

Good suggestion. I'll add one to help clarify usage of the tables.

>
> About section 2.1.1 - I meant that the paragraph deals with the fact that the size of the curve is not usually a power of two, so I don't think that there is a nee to restrict the discussion to non-binary curves (as the first sentence says), as this fact remains true in that case as well.

Also a good point. This particular section need not be restricted to
non-binary curves.

Thanks again for the feedback.

Best,
Chris

---

From: Christopher Wood <[email-masked]>
Date: Sat, 1 Sep 2018 16:12:44 -0700

Hi Dan,

On Thu, Aug 30, 2018 at 6:36 AM Dan Brown <[email-masked]> wrote:

> Hi all,
> I think the goal of this I-D has merit.
> I skimmed it today, just to see what these comments were about. I have
> some very minor comments.
>
> n=qh+r should be n=qh, since the remainder r=0.
>
> I vaguely recall that not all supersingular curves have n=p^k+1, so there
> is not always the described map.
>
> I agree with with Marek's comment. The curve size n being equal to 2^L
> does not depend on p. Usually, n=2^L is avoided, since q=2 is too small
> (and Pohlig--Hellman can be used to solve ECDLP. )
>
> It was a little unclear to me what HashToBase meant. It is applied in SWU
> with p^k, but defined with only p, and the rounding is missing (unless
> defined elsewhere, etc.).
> Similarly, the note about uniformity of HashToBase's output versus bias in
> bits of p is strange: the more biased p is towards 2^L, the less biased the
> output of HashToBase, ...
>

> I haven't made time yet to do a more thorough review that it deserves.
>

Thanks for your comments thus far. We will try to integrate them --
especially those surrounding HashToBase usage, which are (useful) dupes --
in the next revision.

Best,
Chris