Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new hash_to_field definition #212

Merged
merged 19 commits into from Feb 28, 2020
Merged

new hash_to_field definition #212

merged 19 commits into from Feb 28, 2020

Conversation

@kwantam
Copy link
Collaborator

kwantam commented Feb 24, 2020

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

Now ready for review, I believe.

Todo:

  • rename to hash_to_field
  • write new definitions and security considerations
  • update Security Considerations section
  • update Roadmap section
  • 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.!

draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
Copy link
Collaborator

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.)

draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Show resolved Hide resolved
@kwantam

This comment has been minimized.

Copy link
Collaborator Author

kwantam commented Feb 25, 2020

@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

This comment has been minimized.

Copy link
Collaborator

armfazh commented Feb 25, 2020

@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 kwantam marked this pull request as ready for review Feb 25, 2020
@kwantam kwantam requested a review from chris-wood Feb 25, 2020
@kwantam kwantam force-pushed the kwantam:new-hash_to_field branch from 04ba703 to e2f803d Feb 25, 2020
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.
@kwantam

This comment has been minimized.

Copy link
Collaborator Author

kwantam commented Feb 25, 2020

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.

k is used in expand_message_md and in hash_to_field, so it needs
to be specified in suites in order to ensure compatibility.
@kwantam kwantam force-pushed the kwantam:new-hash_to_field branch from f55aff5 to 4830ca7 Feb 25, 2020
@peteroupc

This comment has been minimized.

Copy link

peteroupc commented Feb 25, 2020

You have said that power analysis attacks are not in scope for this document (#202 (comment)); you should note something about that in the security considerations.

kwantam added 2 commits Feb 25, 2020
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.
@kwantam

This comment has been minimized.

Copy link
Collaborator Author

kwantam commented Feb 27, 2020

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

This comment has been minimized.

Copy link
Collaborator

chris-wood commented Feb 27, 2020

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

Separately is fine by me!

Copy link
Collaborator

chris-wood left a comment

The latest changes LGTM!

Copy link
Collaborator

armfazh left a comment

It looks good, I just left few comments.
What is the consensus about using octet rather than byte?

draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Show resolved Hide resolved
draft-irtf-cfrg-hash-to-curve.md Show resolved Hide resolved
@chris-wood

This comment has been minimized.

Copy link
Collaborator

chris-wood commented Feb 27, 2020

What is the consensus about using octet rather than byte?

I prefer byte. @kwantam?

@kwantam

This comment has been minimized.

Copy link
Collaborator Author

kwantam commented Feb 28, 2020

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 kwantam force-pushed the kwantam:new-hash_to_field branch from df1db4a to 4021f2f Feb 28, 2020
@kwantam

This comment has been minimized.

Copy link
Collaborator Author

kwantam commented Feb 28, 2020

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.

this is necessary to ensure that distinct (msg, DST, len) inputs
give distinct outputs. Otherwise, it's possible to 'move' bytes
from msg to DST and thereby create ambiguous inputs.
@kwantam kwantam merged commit 2b2ea54 into cfrg:master Feb 28, 2020
@kwantam kwantam deleted the kwantam:new-hash_to_field branch Feb 28, 2020
@CarlBeek CarlBeek mentioned this pull request Mar 18, 2020
2 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.