7

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.

Community
  • 1
Christopher Schultz
  • 312
  • 2
  • 10
  • 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}) ... – dave_thompson_085 May 15 '18 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](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8) – dave_thompson_085 May 15 '18 at 12:26
  • Sorry, I mistyped that curve name... it should have been `sect571k1`. I've corrected the question text. – Christopher Schultz May 15 '18 at 14:09
  • You can find a listing of some named curves with references here: https://crypto.stackexchange.com/a/59968. See also https://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](https://blog.cr.yp.to/20191024-eddsa.html). – Squeamish Ossifrage Nov 10 '19 at 04: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. – Christopher Schultz Nov 11 '19 at 19:44

2 Answers2

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.

dhe25519
  • 21
  • 4
  • *"Curve25519 ... has has many desirable properties... easy to implement"* - Lol... Here's Andrew Moon's [x25519](https://github.com/floodyberry/curve25519-donna) and [ed25519](https://github.com/floodyberry/ed25519-donna). I'm not sure I'd use the word *"easy"* to describe it. –  Dec 25 '18 at 10:56
1

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:

David Blevins
  • 111
  • 2
  • 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! – Christopher Schultz Sep 06 '21 at 16:58
  • I'll add another reference for you, since I did similar work that might be useful to you. [pem-utils](https://github.com/ChristopherSchultz/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 :) – Christopher Schultz Feb 24 '22 at 21:18