new hash_to_field definition

cfrg / draft-irtf-cfrg-hash-to-curve

Hashing to Elliptic Curves

Other

79 stars 27 forks source link

new hash_to_field definition #212

Closed kwantam closed 4 years ago

kwantam commented 4 years ago

This PR redefines hash_to_field in the way discussed in #202.

Now ready for review, I believe.

Todo:

[x] rename to hash_to_field
[x] write new definitions and security considerations
[x] update Security Considerations section
[x] update Roadmap section
[x] update Suites section
~update implementations~ we can do this in a separate PR (or I'm happy to do it here... what do we think?)

@armfazh @chris-wood @JustinDrake I'd appreciate comments on the WIP version. I'm sure I've left typos, things aren't super clear yet, etc.!

kwantam commented 4 years ago

@chris-wood, @armfazh should we wait to update code until after we land #196?

(I know that I need to review that code! Sorry!!! I will do it next...)

armfazh commented 4 years ago

@chris-wood, @armfazh should we wait to update code until after we land #196?

What about merging 196 (modulo Riad's review). Once this PR (212) be reviewed and approved, we can generate a new pr addressing only the new hash_to_field function.

kwantam commented 4 years ago

I added k, the target security level, to the suite definition. It's needed in the definition of expand_message_md, so we need to specify it for compatibility.

peteroupc commented 4 years ago

You have said that power analysis attacks are not in scope for this document (https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/202#issuecomment-581644873); you should note something about that in the security considerations.

kwantam commented 4 years ago

I've got updated code ready to go.

Should I just add those commits to this PR, or should we handle them separately? @armfazh @chris-wood

chris-wood commented 4 years ago

Should I just add those commits to this PR, or should we handle them separately? @armfazh @chris-wood

Separately is fine by me!

chris-wood commented 4 years ago

What is the consensus about using octet rather than byte?

I prefer byte. @kwantam?

kwantam commented 4 years ago

I prefer byte. @kwantam?

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.

kwantam commented 4 years ago

Ach, there's one more issue I need to think about before we merge @chris-wood @armfazh

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. ~So can we hold off until later today when I push an edit?~

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.