6

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.

|improve this question
  • 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 – 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
1

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.

|improve this answer
  • "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. – jww Dec 25 '18 at 10:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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