Closed DonaldTsang closed 5 years ago
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.
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