Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
You can use Curve25519 as per this answer. – SEJPM Sep 26 '15 at 17:06
Thanks for this. I also found this post which is very useful – absinthe Sep 26 '15 at 19:45
Most of the advantages of safe curves only apply if you use Mongomery or (twisted) Edwards form for computation. Or do you just want to use Weierstrass form for easy prototyping with MIRACL and then switch to another form for production use? – CodesInChaos Sep 28 '15 at 14:50
At the current stage I want to use them for a prototype and say that I use this curves which are known as secure even if they do not perform as they are expected to. It's more like a proof of concept. Indeed, using the original form of these curves would give me a significant performance boost, but this will be done at a later stage, if so. – absinthe Sep 30 '15 at 8:44

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

share|improve this answer
'Rigid' is the word they use. – otus Oct 2 '15 at 10:20

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.

share|improve this answer
I wouldn't say fancy Curve25519 as it is being standardized. However, the arguments that the site has are not unfair (see here. – absinthe Sep 26 '15 at 21:28
Well, calling them "the" safe curves is a bit of an exaggeration. So maybe stick to something more neutral such as "the Bernstein curves". – Circonflexe Oct 29 '15 at 18:40
@Circonflexe What do you think about twist insecurity for Brainpool curves that DJB has mentioned here: How big this threat is in your view? – Oleg Gryb Nov 1 '15 at 17:43

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.