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

Safe Curves? #23

Closed
10 tasks
DonaldTsang opened this issue Oct 10, 2018 · 1 comment
Closed
10 tasks

Safe Curves? #23

DonaldTsang opened this issue Oct 10, 2018 · 1 comment

Comments

@DonaldTsang
Copy link

DonaldTsang commented Oct 10, 2018

Is it possible to add safe curves like Curve25519 and the ones in the paper blow to the library?
The reasoning is to get people to use curves that are actually secure (https://safecurves.cr.yp.to/)
https://eprint.iacr.org/2013/647.pdf

  • M191
  • M-221
  • Curve25519
  • M-383
  • M-511
  • E-191
  • E-222
  • Curve1174
  • E-382
  • E-521
@AntonKueltz
Copy link
Owner

AntonKueltz commented Oct 10, 2018

All the curves mentioned above are curves that are not in Weierstrass form, and as such will need specialized implementations of their group operations (which is certainly possible though it will require a fair amount of time and testing). For Edwards curves and Montgomery curves (i.e. these curves) there actually isn't really much sense to adding them to an ECDSA package since they would be much more suited to using EdDSA.

For Curve25519 I recommend using python-ed25519, which uses the reference C implementation and should perform reasonably well.

Also, while I have a lot of respect for the researchers behind the Safe Curves work, their criteria is a bit unfairly misleading in implying that e.g. NIST curves are unsafe. Those curves have been researched and used for many years, and no significant cryptanalytic breaks have been found. Most of the safe criteria is aimed at preventing bad implementations that allow side channel attacks, as well as other criteria that simply give the curves some nice properties on the implementation level. See this answer and this question on the crypto SE for further opinions on the matter.

So for curves listed it may make more sense to put them in their own package since they have different group rules and a different signature algorithm. I'm not opposed to starting an eddsa package but it's beyond the scope of this package.

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

No branches or pull requests

2 participants