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

EC_hash_to_curve2 as the only option #25

Open
fcelda opened this issue Jun 17, 2017 · 3 comments
Open

EC_hash_to_curve2 as the only option #25

fcelda opened this issue Jun 17, 2017 · 3 comments
Labels

Comments

@fcelda
Copy link
Owner

fcelda commented Jun 17, 2017

EC_hash_to_curve1 is susceptible to timing attacks. I feel quite uncomfortable about proposing this even if this property is not relevant for some use cases. Do we know how to implement the _curve2 without significant drawbacks? If we do, I propose to use _curve2 as the only option in the draft.

@fcelda fcelda added the VRF label Jun 17, 2017
@goldbe
Copy link
Collaborator

goldbe commented Jun 19, 2017

We have _curve2 for Ed25519 (it is Elligator) but not for P256.
However _curve1 works for P256 and Ed25519. That's why its there.

@dipapado
Copy link
Collaborator

In the future, we can look into writing explicitly one of the other algorithms that we know of that work for any curve without being susceptible to timing attacks (e.g., [Icart09]. However, I suspect this would be slower than the current _curve1 and that is why we skipped it in NSEC5.

@goldbe
Copy link
Collaborator

goldbe commented Jun 28, 2018

We added Elligator for Curve25519 in draft-irtf-cfrg-vrf-02
We don't have an equivalent constant time hash for Curve P256 yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants