Introduction

There are several different standards covering selection of curves for use in elliptic-curve cryptography (ECC):

Each of these standards tries to ensure that the elliptic-curve discrete-logarithm problem (ECDLP) is difficult. ECDLP is the problem of finding an ECC user's secret key, given the user's public key.

Unfortunately, there is a gap between ECDLP difficulty and ECC security. None of these standards do a good job of ensuring ECC security. There are many attacks that break real-world ECC without solving ECDLP. The core problem is that if you implement the standard curves, chances are you're doing it wrong:

Your implementation produces incorrect results for some rare curve points.

Your implementation leaks secret data when the input isn't a curve point.

Your implementation leaks secret data through branch timing.

Your implementation leaks secret data through cache timing.

These problems are exploitable by real attackers, taking advantage of the gaps between ECDLP and real-world ECC:

ECDLP is non-interactive. Real-world ECC handles attacker-controlled input.

ECDLP reveals only nP. Real-world ECC also reveals timing (and, in some situations, much more side-channel information).

ECDLP always computes nP correctly. Real-world ECC has failure cases.

Secure implementations of the standard curves are theoretically possible but very hard.

Most of these attacks would have been ruled out by better choices of curves that allow simple implementations to be secure implementations. This is the primary motivation for SafeCurves. The SafeCurves criteria are designed to ensure ECC security, not just ECDLP security.

Other attacks would have been ruled out by better choices at higher levels of ECC protocols. For example, deterministic nonces were proposed in 1997, are integrated into modern signature mechanisms such as EdDSA, and would have prevented the 2010 Sony PlayStation ECDSA security disaster. However, this security issue does not interact with curve choices, so it is outside the scope of SafeCurves.

Efficiency

All of the standards listed above add further constraints for the sake of efficiency. For example, the NIST P-256 curve

uses a prime 2^256-2^224+2^192+2^96-1 chosen for efficiency ("modular multiplication can be carried out more efficiently than in general"),

uses curve shape y^2=x^3-3x+b "for reasons of efficiency" (similarly, IEEE P1363 claims that this curve shape provides "the fastest arithmetic on elliptic curves"); and

takes cofactor "as small as possible" for "efficiency reasons".

Subsequent research (and to some extent previous research) showed that essentially all of these efficiency-related decisions were suboptimal, that many of them actively damaged efficiency, and that some of them were bad for security.

SafeCurves does not attempt to correct the erroneous efficiency claims in the standards listed above. SafeCurves does not consider efficiency issues, except to the extent that they interact with security issues.

Evaluation targets

The SafeCurves web site reports security assessments of various specific curves. Some of the curves listed on this site are deployed or have been proposed for deployment. Some of the curves are merely toy examples meant to illustrate how curves can fail to meet various security criteria.

"Safe" in the following table means that a curve meets all SafeCurves requirements. The curves are sorted in increasing order of the prime ℓ.

The following table splits the SafeCurves requirements into (1) basic parameter requirements, (2) ECDLP security requirements, and (3) ECC security requirements beyond ECDLP security:

Parameters: ECDLP security: ECC security: Curve Safe? field equation base rho transfer disc rigid ladder twist complete ind Anomalous False True ✔ True ✔ True ✔ True ✔ False False True ✔ False False False False M-221 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ E-222 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ NIST P-224 False True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ False False False False False Curve1174 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ Curve25519 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ BN(2,254) False True ✔ True ✔ True ✔ True ✔ False False True ✔ False False False False brainpoolP256t1 False True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ False False False False ANSSI FRP256v1 False True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ False False False False False NIST P-256 False True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ False False True ✔ False False secp256k1 False True ✔ True ✔ True ✔ True ✔ True ✔ False True ✔ False True ✔ False False E-382 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ M-383 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ Curve383187 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ brainpoolP384t1 False True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ False True ✔ False False NIST P-384 False True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ False False True ✔ False False Curve41417 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ Ed448-Goldilocks True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ M-511 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ E-521 True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔ True ✔

Contributors

SafeCurves is joint work by the following authors (alphabetical order):

Daniel J. Bernstein, University of Illinois at Chicago, USA, and Technische Universiteit Eindhoven, Netherlands

Tanja Lange, Technische Universiteit Eindhoven, Netherlands

SafeCurves should be cited as follows:

Daniel J. Bernstein and Tanja Lange. SafeCurves: choosing safe curves for elliptic-curve cryptography. https://safecurves.cr.yp.to, accessed 1 December 2014.

Replace 1 December 2014 by your download date.

Acknowledgments

This work was supported by the U.S. National Science Foundation under grant 1018836. "Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation."

This work was supported by the Netherlands Organisation for Scientific Research (NWO) under grant 639.073.005.

Many calculations used the Sage computer-algebra system. The most difficult factorizations were completed with CADO-NFS.

Version: This is version 2017.01.22 of the index.html web page.