Subject: [Cfrg] hash-to-curve updates and suite reduction

From: "Christopher Wood" <[email-masked]>
Date: Tue, 28 Apr 2020 05:39:12 -0700

Hi folks,

The hash-to-curve authors spun draft-irtf-cfrg-hash-to-curve-07 recently [1]. Some of the major changes focus on how we handle DSTs for domain separation in hash_to_field. If you have some spare cycles, please have a look and provide feedback! 

In addition to this change, I'd also like to call attention to the section on suites [2]. We've heard criticism that there are currently too many suites defined, which can complicate implementations and protocols [3]. The list should likely be reduced. In particular, the document should probably specify at most one recommended suite covering both the RO and NU cases for each curve. (Alternatives could be defined elsewhere, i.e., in separate documents if needed.) 

In this interest of document clarity and ease of use by the community, we'd like to know what folks think about this proposal. Some questions to consider are:

- What should be the preferred mapping function for each curve? For example, P-256 specifies P256_XMD:SHA-256_SSWU_RO_  and P256_XMD:SHA-256_SVDW_RO_, which use the Simplified SWU (SSWU) and Shallue-van de Woestijne maps, respectively. Considering libraries that might implement the Shallue-van de Woestijne for more than one curve, should we err towards code re-use or stick with the less-general SSWU map?
- Should each curve have one suite for the RO case and another for the NU case? Doing so assumes implementers know when and how to choose between these two variants. This is something the document mostly skips over, saying simply, "When the required encoding is not clear, applications SHOULD use a random oracle."

Thanks in advance for your time and consideration.

Best,
Chris

[1] https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-07
[2] https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-07#section-8
[3] https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/235

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 28 Apr 2020 15:24:39 +0000

Offhand: in this context I would prefer erring towards code reuse, even at the cost of lesser efficiency.

On 4/28/20, 08:40, "Cfrg on behalf of Christopher Wood" <[email-masked] on behalf of [email-masked]> wrote:

    Hi folks,

    

    
    Best,
    Chris

    _______________________________________________
    Cfrg mailing list
    [email-masked]
    https://www.irtf.org/mailman/listinfo/cfrg