Hashing to Elliptic Curves
draft-irtf-cfrg-hash-to-curve-16

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-irtf-cfrg-hash-to-curve-16 and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
IANA Operations Manager

IRSG poll has closed with enough positions to proceed. Spencer had comments. Please review and discuss, and submit an updated draft if needed, then this can go for IESG conflict review.

[Ballot comment]
I'm only vaguely aware of how this stuff works, so please keep that in mind, when reading my comments. I hope they are somewhat helpful.

In this text from the Introduction,

Unfortunately for implementors, the precise hash function that is suitable for a given protocol implemented using a given elliptic curve is often unclear from the protocol's description. Meanwhile, an incorrect choice of hash function can have disastrous consequences for security.

I’m not sure I understand (at this point in the document) what the problem is (“why it’s not OK to just pick a hash function”), other than “if you do that, bad things will happen”). Is there a reference you could include here, or even a forward pointer if there's a good place to point to in the draft, so that us non-experts can follow along?

I learned a lot from googling “rejection sampling methods” while reading this text

This document does not cover rejection sampling methods, sometimes referred to as "try-and-increment" or "hunt-and-peck,"

But the text didn’t tell me enough to understand rejection sampling methods. Perhaps a half-sentence explanation, or a reference, would be helpful.

This is nit-ish, but it confused me.

5.1.  Security considerations, is only for section 5, is that right? There’s another Security Considerations - section 10 - which starts with these two sentences:

Section 3.1 describes considerations related to domain separation. See Section 10.4 for further discussion.

Section 5 describes considerations for uniformly hashing to field elements; see Section 10.2 and Section 10.3 for further discussion.

I found myself wondering why some security considerations seem to be in Section 3.1 (which isn’t called Security considerations), and others seem to be in Section 5 (shouldn’t the second sentence refer to Section 5.1, which IS called Security considerations?), and these considerations outside Section 10 aren’t complete. If I was looking for all the Security considerations, I’d expect to find them together, and probably in Section 10.

Do the right thing, of course.

I’m not picking on BCP 14 language in most of the text, but in Section 7,

Note that in this case scalar multiplication by the cofactor h does not generally give the same result as the fast method, and SHOULD NOT be used.

I’m not understanding why this is not a MUST - when is it OK to use scalar multiplication, if it usually gives a different result?

I have roughly the same question in Section 8.5,

This section defines ciphersuites for curve25519 and edwards25519 [RFC7748]. Note that these ciphersuites SHOULD NOT be used when hashing to ristretto255 [I-D.irtf-cfrg-ristretto255-decaf448]. See Appendix B for information on how to hash to that group.

What if I DO use these ciphersuites inappropriately?

Very similar text is in 8.6, so I have a very similar question.

This section defines ciphersuites for curve448 and edwards448 [RFC7748]. Note that these ciphersuites SHOULD NOT be used when hashing to decaf448 [I-D.irtf-cfrg-ristretto255-decaf448]. See Appendix C for information on how to hash to that group.

Do the right thing, of course.

In section 8.9,

The RECOMMENDED way to define a new hash-to-curve suite is:



When hashing to an elliptic curve not listed in this section, corresponding hash-to-curve suites SHOULD be fully specified as described above.

As a nit, “not listed in this section” might reasonably be read as “not listed in section 8.9”. I think you might better say “not listed elsewhere in section 8”.

But beyond that, I don’t think you mean “RECOMMENDED” in the BCP 14 sense. If this text said

For elliptic curves not listed elsewhere in section 8, a new hash-to-curve suite can be defined by


You wouldn’t need any of the BCP 14 language in this section, with the attendant “why is this not a MUST”, “in what cases would you not do this”, and “if you don’t do this, what happens?” questions that reviewers can’t help asking …

I sent IRTF Chair review comments to the list. I expect a minor update is needed to address these, but am willing to hear arguments otherwise.

Technical Summary
This document describes a set of procedures for encoding an arbitrary-length byte string to a point on an elliptic curve. The document contains a set of recommended suites, provides implementation guidelines and target security levels for each of them. Rejection sampling methods of hashing to curves are not covered by the document because of significant issues with constant-time implementations.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Research Group Summary
After adopting the document it was presented in CFRG meetings at IETF 101, IETF 102, IETF 103, IETF 105 and IETF 106.
There was a Research Group Last Call for the draft in 2020. There were no major concerns raised during the RGLC. Several minor concerns raised during the RGLC were addressed by the authors.
The authors have answered the questions raised during the Research Group Last Call, no questions have remained unanswered.
Crypto Review Panel review was solicited in June 2020. The review was provided by Thomas Pornin. Comments from that review were addressed in -09 and -10.

Document Quality
There are at least eight implementations for various elliptic curves: a Go implementation (in CIRCL) for hashing to curve for the three NIST curves[1] and for BLS12-381 [2], implementations for BLS12-381 in rust [3], boringSSL [4], wrapper Go-rust-C [5] , and py_ecc [6], EIP for ethereum [7,8], see also [9].
All authors of the document have confirmed that they are not aware of any IPRs related to the document other than the ones that are already in the datatracker.
The construction is used in a significant number of CFRG documents (active CFRG I-Ds for the current moment): Two-Round Threshold Signatures with FROST, SPAKE2, Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups, Verifiable Random Functions (VRFs), Pairing-Friendly Curves.

Personnel
Stanislav Smyshlyaev is the Document Shepherd.
Colin Perkins is the IRTF Chair.

[1] https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/pull/326
[2] https://github.com/cloudflare/circl/blob/master/ecc/bls12381/g1.go#L357
[3] https://github.com/zkcrypto/bls12_381/tree/main/src/hash_to_curve
[4] https://boringssl.googlesource.com/boringssl/+/refs/heads/master/crypto/ec_extra/hash_to_curve.c
[5] https://github.com/drand/bls12381rs
[6] https://github.com/ethereum/py_ecc/blob/master/py_ecc/bls/hash_to_curve.py
[7] https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3068.md
[8] https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2537.md
[9] https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve#reference-implementations

Request for posting confirmation emailed to previous authors: Riad Wahby , Armando Faz-Hernandez , Christopher Wood , Nick Sullivan , cfrg-chairs@ietf.org, Sam Scott , irtf-chair@irtf.org