I recently had a problem where I created an EC client certificate which used the sect571k1 curve and I got some strange errors attempting to use it as a client certificate through Mozilla Firefox. It turns out that Firefox supports secp521r1 but not sect571k1.

I had created the certificate using Java's keytool, which reports the curve as 570-bit EC key, while openssl x509 tells me it is both ASN1 OID: sect571k1 and NIST CURVE: K-571. A bit of googling leads me to RFC 4492 which lists several keys and their various aliases, but it does not list many of the curves which are popularly discussed such as djb's Curve25519 and any of the brainpool curves. (Java's keytool doesn't appear to allow you to choose the exact curve, only the bit-size of the key, so I didn't really have a choice.)

My LibreSSL supports ~90 different curves while my Java supports ~50 different curves. I'd like to be sure that anything I do with any "more-capable" tools are going to be compatible with web browsers, and it would be good to know what the equivalents are for all of these names.

  • If you just want compatibility for the web (which is a subset of SSL/(D)TLS which is a small subset of X.509 uses) almost everybody that does EC at all does the three larger F_p (prime) random curves from X9/SECG secp{256,384,521}r1 adopted by NIST FIPS186 as P-{256,384,521} which names are more common, and the first two of which (P-256,P-384) were in NSA's Suite B standard until NSA decided to drop EC and go post-quantum instead. Anything under 256 is considered too small today, and in practice almost no one uses any of the F_2^m curves (X9/SECG sect{size}{r/k}{n} = FIPS186 B-{n},K-{n}) ... May 15, 2018 at 12:16
  • ... and very few use the brainpool curves. Many do use djb's 25519 and sometimes 448, but those require different code not just parameters, and Java standard SunEC doesn't support them, though I think BC does. Also be careful to keep your key, and thus cert, in 'named' (OID) form not explicit form, which almost nobody supports; for Java this is mostly automatic, but OpenSSL can screw it up. BTW there is no secp521k1; SECG prime Koblitz only go up to 256. And the outer bounds for TLS are the registrations May 15, 2018 at 12:26
  • Sorry, I mistyped that curve name... it should have been sect571k1. I've corrected the question text. May 15, 2018 at 14:09
  • You can find a listing of some named curves with references here: crypto.stackexchange.com/a/59968. See also safecurves.cr.yp.to for information about curves in DH and Schnorr-type signature applications. However, more curves is not better—rather, it's evidence of a badly designed protocol or a badly implemented library. Nov 10, 2019 at 4:56
  • @SqueamishOssifrage I'm not looking for a huge library of curves to use. I'm looking for the random names that various libraries choose to use the the same curve. It's getting frustrating to try to compare apples to apples with these things when everyone uses their own pet names. Nov 11, 2019 at 19:44

2 Answers 2


For TLS there is of course the official list of curves, but there's not a single, comprehensive list of elliptic curve names I am aware of. But when you look at different TLS implementations, you will quickly notice that there is only a limited number of elliptic curves that are supported by all major implementations.

For maximum interoperability, you should use secp256r1 (NIST P-256) or secp384r1 (NIST P-384), as these are used by most CAs for their own certificates, are supported by all major TLS implementations and will also be contained in TLS 1.3 (which only contains a total of five curves (secp256r1, secp384r1, secp521r1, curve25519 (x25519) and curve448 (x448)).

Curve25519 will probably play a major role in the future, as it has has many desirable properties (very fast, easy to implement, avoids leaking information via side channels), but has only recently been included in many important standards.

  • "Curve25519 ... has has many desirable properties... easy to implement" - Lol... Here's Andrew Moon's x25519 and ed25519. I'm not sure I'd use the word "easy" to describe it.
    – user29925
    Dec 25, 2018 at 10:56

I found this site to be invaluable.

It's not very browseable, but all the curve data is in json format here:

I noticed some of the OIDs were missing and looked up and contributed that data and my PR was merged very quickly.

Worked great to help me generate this list of curves for a Java library I'm working on for reading/writing keys in all the common formats:

  • 1
    Thanks for this. In the years since I asked this question, I actually discovered the Neuromancer.sk site and have been using it for details on "the maths" but it never occurred to me to add a reference, here, to that site. Thanks! Sep 6, 2021 at 16:58
  • I'll add another reference for you, since I did similar work that might be useful to you. pem-utils is a Java project which can read PEM files of all kinds. It looks like you and I ended up doing basically the same work... your curve-setup code looks suspiciously like mine :) Feb 24, 2022 at 21:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .