Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
new hash_to_field definition #212
This PR redefines hash_to_field in the way discussed in #202.
Now ready for review, I believe.
chris-wood left a comment
This looks great! I quite like the new modularity, especially as it lets us more easily test things. (We can have different test vectors for hash_to_field and expand_message_md et al.)
this edit changes the format of the Suites section to make the definition of each suite more self-contained. Most importantly, each suite definition explicitly states the encoding type (hash_ or encode_to_curve).
This is to guarantee that different values of len_in_octets result in completely different outputs. Otherwise, changing len_in_octets by a small amount may not change ell, and the outputs would be related in that case.
add a paragraph in Security Considerations discussing the way that H shoud be domain separated inside/outside hash_to_field. Also, added a requirement in hashtofield-expand-other to make sure that other variants follow this guideline, too. Also, slight reorg / cleanup / deduplication in Security Considerations.
I think "octet" is a little awkward and annoying, but is more precise than "byte" (in the sense that octet is exactly 8 bits, but byte isn't necessarily).
In practice this probably mattered a lot more when RFC793 was written than it does now, so I'm fine switching everything to bytes and just noting somewhere that we assume bytes are 8 bits.
We want to use a prefix-free encoding of DST in both of the expand_message variants. This is easy: just prepend DST with its length. But I want to make sure the text reflects this throughout.
Done now. By the way, I didn't give a good justification for this above, but the reason is that otherwise we don't meet our own requirement that all distinct (msg, DST, length_in_bytes) triplets give distinct outputs. Specifically, without a prefix-free DST encoding, it's possible to "trade" bytes between msg and DST to get two triplets that give the same output.