search

fcelda / nsec5-draft

Working Copy of the NSEC5 Specification
15 stars 2 forks source link

Incorporate hash-to-curve by reference #35

Closed kwantam closed 4 years ago

kwantam commented 5 years ago

Hello! I'm helping with the hash-to-durve Internet draft, and I've been chatting with @reyzin about harmonizing our two documents.

To that end, this PR removes the step-by-step descriptions of Elligator 2 and Simplified SWU, and replaces them with references to hash-to-curve ciphersuites.

We (the hash-to-curve authors) are just about ready to push revision -05. This PR preemptively refers to that version of the document, which means xml2rfc will die until the -05 draft is actually published---sorry about that.

Happy to coordinate further, make changes, etc. Please let me know how I can help!

kwantam commented 5 years ago

(Also, this PR may have some bearing on #25)

kwantam commented 4 years ago

Hello again!

I've updated this PR to reflect the latest changes to hash-to-curve. This change comprehends the redesign in the hash_to_base function (now called hash_to_field) inside hash-to-curve, which was done partially in response to @reyzin's comments, and it also comprehends the revamped h2c suite naming scheme.

The issue with the prior approach to hash_to_base (built on HKDF) was that it was not possible to get a strict guarantee of domain separation between calls to H() inside of HKDF and calls to H() outside. Our redesigned function no longer uses HKDF, which allows us to make this guarantee (see further discussion in /cfrg/draft-irtf-cfrg-hash-to-curve#202). In particular, in the new version every call to H() inside hash_to_field appends the domain separation tag.

We decided to append (rather than prepend) for a small bit of extra safety margin when using a Merkle-Damgaard hash function. In particular, this guarantees that in all of hash_to_field's calls to H(), the high-entropy part of the hash's input (in our case, either the message being hashed or the pseudorandom key being re-hashed---rather than the domain separation tag) starts on an input block boundary. This maximizes the amount of entropy that the hash function digests in a single evaluation of the compression function, and in particular avoids the case where the high-entropy string is split across a block boundary. (Dan Boneh pointed out that splitting in this way could invite meet-in-the-middle--style attacks.)

To ensure correct domain separation, this PR also changes the way that suite_string, one_string, two_string, and three_string are injected in all of the ECVRF functions. This has the nice side effect of making sure that the high-entropy part of the input to H() comes first in the hash's input string for all of the calls in VRF, too.

Finally, because I made the hash input ordering change for the EC spec, I also made the same change for the RSA spec---specifically, reversing the order of inputs to MGF1 and to H in the RSA proof-to-hash algorithm. This is a combination of paranoia's and consistency's sake, but I'm happy to back it out if you'd prefer.