# What is the most secure ECC Curve?

I have for a while used Koblitz curve (sect571k1), in ECDH and ECDSA. But I have started wonder if it is the most secure. I prefer security over efficiency. So the curve doesn't have to be the most efficiency curve.

I'm not looking for a curve that is only secure today, and the next few years. The compute power increases rapidly today, and I'm looking for a curve that is secure as far as possible in the future. So if someone is able to steal my encrypted data today, they should not be able to crack it in next 20 years, hopefully longer.

• safecurves.cr.yp.to gives a comprehensive overview of curve security. – Kevin__ Dec 24 '15 at 15:48
• SafeCurves only lists insecure curves, but says nothing about there strength or how to compare them. – Yorick de Wid Dec 24 '15 at 16:49
• safecurves.cr.yp.to doesn't list sect571k1, sect521p1 and such curves that I'm interested in. – BufferOverflow Dec 24 '15 at 18:14
• my personal opinion is that no Koblitz curve is secure – Richie Frame Dec 24 '15 at 19:09
• The goldilocks curve could be interesting for you. – Maarten Bodewes Dec 24 '15 at 20:12

There is no such thing as the most secure curve. For one you can always come up with a larger curve if you need one. For another there are many measures of security and not all curves are directly comparable.

If you wanted the curve for which the current best known attack is the slowest, then by that measure sect571k1 is actually the most secure out of the curves that are in use.

However, that is not necessarily a very useful requirement, because any curve for which the best known attack is slower than ~128-bit strength equivalent will never be broken without either advances in attacks or the arrival of practical quantum computers. Those advances need not apply equally to all curves, while quantum computers would break all curves regardless of strength.

Binary field curves like the one in question are sometimes considered more risky because better attacks are known than for prime field curves of similar size, so it is thought that new attacks are more likely. That is a judgement call.

Likewise there are other measures of security that do not apply to all curves. Perhaps the most talked about is the potential for some kind of backdoor in the parameters, which makes some distrust NIST curves in particular and any curves without a good explanation for the parameters in general. Also things like ease of secure implementation may matter in practice.

• I guess there is no binary curves or prime curves that is «public approved» and considered to be secure that is bigger than 571-bits or 521-bits? I quess I don't need larger than koblitz sect571k1 curve, as long there is no expectation to be broken before arrival of pratical quantum computers, but at the arrival of pratical quantium computer it is possible to break all todays encrypted data. I'm just asking out of curiosity, I like to know. And I have enough understanding to understand that I'm not able to design a curve that is secure, this task leave I to professional cryptgraphy experts. – BufferOverflow Dec 25 '15 at 11:21
• @BufferOverflow, correct, those are the largest that are approved and used in practice. Which of the two is more secure is at least somewhat subjective, like with secp256r1 vs. secp256k1. – otus Dec 25 '15 at 11:27

Beyond weaknesses in specific curves, it is hard to give a scientific answer to this. Personally, I am quite conservative. I always prefer prime curves over binary field curves. I also think that the NIST curves P-256 and so on have been around long enough to give us strong confidence. (And they are fast enough for most applications.)

• I have a long time perspective on encryption of data, and specially data that is sent over channels that is public available. One solution can be secure today, but I'm looking for solutions that is secure as far in the future as possible. The compute power today increases rapidly, so if someone eavesdropp me, and they store the encrypted data that I transmittet. Then the encryption should not be possible to break in least 20 years, and hopefully longer. – BufferOverflow Dec 24 '15 at 20:22
• @MaartenBodewes: correction: the NSA (not NIST, which doesn't own Suite B) has not removed the elliptic curves from suite B; instead, what they published the recommendation that people not put in effort to move to elliptic curves (and instead wait for some unnamed postquantum solution) – poncho Dec 24 '15 at 20:22
• Hmmm. Ok, seems i have been misinformed. I'll chech it after star wars :) – Maarten Bodewes Dec 24 '15 at 20:24

You might want to look at Ed448-Goldilocks, a new 448-bit Edwards curve that has been approved for use in standards like TLS by the CFRG, designed "as an alternative to both secp384r1 and secp521r1": https://eprint.iacr.org/2015/625.pdf

The curve sect571k1 is not listed in the SafeCurves (http://safecurves.cr.yp.to/rho.html), but in theory it should be the most secure from the "SEC 2 ver2" curves (http://www.secg.org/sec2-v2.pdf), because its order is 02000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 131850E1 F19A63E4 B391A8DB 917F4138 B630D84B E5D63938 1E91DEB4 5CFE778F 637C1001, which is 571-bit number (the highest in the SEC 2 ver2 standard).

The Pollard rho algorithm can solve the ECDLP problem for 571-bit private key in 2^280 group operations, so the security level of the curve sect571k1 is 280 bits (learn why from this article: https://eprint.iacr.org/2009/086.pdf).

There's no @secure@ cipher : everything is crackable, it's just a question of time and resources. The "longer the key"/"bigger the block"/"more bits" - the more difficult and laborious is to crack the system. Use the longer/bigger variants.

• The length of the key is not the only factor. There are curve types that have known weaknesses. In general, there are schemes that we have more confidence it and those that we have less. It is a function of how long the scheme has been around, and how much it has been looked at. It's not an exact science, but it's not pure guesswork either. It certainly is NOT just the length. – Yehuda Lindell Dec 27 '15 at 11:53
• @YehudaLindell You're right, and my point is that the question itself is too wide. And the WIDE answer is "pick a more lenghty one". Of course, it does not eliminate any need of checking – Alexey Vesnin Dec 27 '15 at 17:28