I would like to implement a protocol using elliptic curves. I'm thinking of using MIRACL so using curves in their Weierstrass form is preferable as it they are supported by this framework.
I don't want to start picking random curves, so I am looking at the available safe curves. None of the curves is in Weierstrass form however. Do you have any suggestions for such curves? Even curves with low security, such as 80 bit curves are welcome.
Bernstein and Lange regard any curve in Weierstraß form as "not safe" because they assume, implementers of ECC with these curves will make stupid mistakes. You can see a more detailed discussion on this point here:Safety of ECC-point addition.
So you should pick a subset of their criteria if you want the Weierstraß form(I don't see any reason not to). IMHO the most important criterion is that their creation was "stiff" i.e. there was no unexplained way to fill degrees of freedom in the creation process. The NIST curves do not fullfill this criterion. They somehow fell from heaven and the community is suspicious. You might use the "stiffly" created ECC-brainpool elliptic curves(up to 512 bit), or my stiffly created curves ECC-curves_anders (up to 1024 bit).
I am not clear about the categorisation of safe and non-safe curves on this site.
But the "unsafe" curves of Nist, Brainpool and Certicom are used in electronic passports , the new german id card , etc.
So, I would simply stick to that curves and forget the fancy "safe" curves.
Nobody including DJB has proved that Brainpool curves are not safe. The only relative weakness that has been mentioned in the safe curves wiki was related to twist security, which includes according to this wiki things like "invalid curves", but those are more implementations issues than something attributed to a curve's properties, e.g. if you always validate point-on-curve condition in your protocol, "invalid curve" attack won't be possible.
Unlike in NIST case, Brainpool's constant generation method is clearly defined and doesn't leave any room for manipulations. In NIST case a method of a seed generation has never been disclosed, which has made some people (including me) nervous after DUAL_EC_DRBG exploit had been disclosed.
The disadvantage of Brainpool curves compare to the NIST ones is that the former couldn't be optimized, which makes them about two times slower than the optimized implementation of NIST's curves, but peace of mind is more important than optimization here.
In regard of DJB's "safe curves", an apparent disadvantage is that a group of researchers that work with them is smaller than that for more traditional curves defined by the short Weierstrass equation. It means that declared "safety" might not live too long as more researchers start looking at them in details.
Bottom line, you should be perfectly safe with Brainpool curves and they are in the short Weierstrass form, which is what you're looking for.
UPDATE
Check this one as well. It's related to "safe"/"not safe" discussion. A timing attack on Curve25519 is described there. It's based on a flaw in a EC point multiplication implementation, so the curve creators could say that it's an implementation problem. At the same time, they claim that other curves are not safe because it's very difficult to implement them right. Well, judging from the provided link implementing Curve25519 right is not easy either :)
