Subject: [Cfrg] RGLC on draft-irtf-cfrg-hash-to-curve-10

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Sat, 17 Oct 2020 10:29:55 +0300

Dear CFRG participants,

This message is starting 2 weeks RGLC on
draft-irtf-cfrg-hash-to-curve-10 ("Hashing to Elliptic Curves"), that will
end on November 1st 2020. If you've read the document and think that it is
ready (or not ready) for publication as an RFC, please send a message in
reply to this email or directly to CFRG chairs ([email-masked]). If
you have detailed comments, these would also be very helpful at this point.

Thomas Pornin provided a review of the document on behalf of Crypto Review
Panel,
https://mailarchive.ietf.org/arch/msg/crypto-panel/B4zejfpzyl70idp-AFpE4ZV1uB4/

Thank you,

Stanislav, for CFRG chairs

---

From: Greg Hudson <[email-masked]>
Date: Sat, 17 Oct 2020 06:10:24 -0400

I have some concerns over the use of the terms "random" and "uniform" in
this document.

The term "random" is sometimes used to describe the output of
deterministic functions.  For instance, section 5 says "it first hashes
the input byte string to produce a uniformly random byte string", and
section 5.2 says that an alternative hash_to_field must output field
elements that are "uniformly random except with bias at most 2^-k".
hash_to_field is a deterministic function; it introduces no randomness.

The term "uniform" describes a probability distribution where all values
have equal probability.  There is an assumption in the document that
applying a hash function to an input string produces an output that is
somehow uniform or uniformly random, without discussing the input as
being selected from any particular probability distribution.

Perhaps there is a definition of "uniform" which makes this language
more rigorous, but the document does not define the term or provide a
reference, so I can only read it as having the meaning from probability.

I understand that the document wants to specify functions
indistinguishable from random oracles, and therefore needs to be
concerned with not introducing bias beyond what is intrinsic in the
input distribution.  (An example of bias intrinsic to the input
distribution would be hashing passwords to curve elements, where 90% of
the passwords are "mypassword".  One output element will necessarily
have 90% probability, no matter how random-looking that single element
might be.)  I unfortunately don't know how to rigorously describe that,
so can't suggest specific wording changes.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 17 Oct 2020 15:38:33 -0700

On Sat, Oct 17, 2020 at 12:30 AM Stanislav V. Smyshlyaev
<[email-masked]> wrote:
>
> Dear CFRG participants,
>
> This message is starting 2 weeks RGLC on draft-irtf-cfrg-hash-to-curve-10 ("Hashing to Elliptic Curves"), that will end on November 1st 2020. If you've read the document and think that it is ready (or not ready) for publication as an RFC, please send a message in reply to this email or directly to CFRG chairs ([email-masked]). If you have detailed comments, these would also be very helpful at this point.

I think it's ready but have three nitpicky concerns far, far,
downstream of the RGLC, which may be entirely offbase.

My first concern is with the references to a number of active drafts.
I don't want to accidentally make a giant cluster if we don't
absolutely have to. Switching these to papers describing the
applications would be a way around it, but maybe there are others.

My second nitpicky concern is with the normativity of section H: the
behavior of this code could change, especially if using F.gen() in an
extension field. It's probably very sensitive to the details of how
the fields are constructed, so I think users of this document should
be encouraged to define suites in terms a bit more strongly than are
used.

My third nitpicky concern is archiving the hash2curve-repo. There are
several times implementers are referred to it, but it's a github repo.
The RFC series has outlasted many companies and storage media. However
stable that looks now, it isn't forever. Rotted references are an ever
present threat.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

---

From: Hal Murray <[email-masked]>
Date: Sat, 17 Oct 2020 18:41:30 -0700

> My third nitpicky concern is archiving the hash2curve-repo. There are several
> times implementers are referred to it, but it's a github repo. The RFC series
> has outlasted many companies and storage media. However stable that looks
> now, it isn't forever. Rotted references are an ever present threat. 

The Internet Archive has a project where they grab everything that is 
referenced by Wikipedia and patch the Wikipedia links to point to their copy 
when the original goes offline.

I'm sure it wouldn't be hard to convince them to grab a copy of anything a 
draft or RFC links to.  I doubt if we want them patching RFCs.  Maybe an extra 
parallel document that could be linked to by the RFC page.

-- 
These are my opinions.  I hate spam.

-- 
These are my opinions.  I hate spam.