When choosing an elliptic-curve look for a safe curve

There are many elliptic-curves to choose from, some are safer than others see SafeCurves: choosing safe curves for elliptic-curve cryptography. But the CA/Browser Forum also limits the elliptic-curve choices.

NIST P-256 (secp256r1) and NIST P-384 (secp384r1) are not the safest NIST P-521 (secp521r1) isn't shown in the list, but there are worse ones. I personally choose x448, x25519, secp521r1, secp384r1 (server preferred order).

Now Certificates For ECDSA key pairs, the CA SHALL:
• Ensure that the key represents a valid point on the NIST P‐256, NIST P‐384 or NIST
P‐521 elliptic curve.

Reference Baseline Requirements Documents (SSL/TLS Server Certificates)
For ECDSA key pairs, the CA SHALL:

  • Ensure that the key represents a valid point on the NIST P‐256, NIST P‐384 or NIST P‐521 elliptic curve. ECDSA
The CA SHALL indicate an ECDSA key using the id‐ecPublicKey (OID: 1.2.840.10045.2.1)
algorithm identifier. The parameters MUST use the namedCurve encoding.

  • For P‐256 keys, the namedCurve MUST be secp256r1 (OID: 1.2.840.10045.3.1.7).
  • For P‐384 keys, the namedCurve MUST be secp384r1 (OID:
  • For P‐521 keys, the namedCurve MUST be secp521r1 (OID:
    When encoded, the AlgorithmIdentifier for ECDSA keys MUST be byte‐for‐byte
    identical with the following hex‐encoded bytes:
  • For P‐256 keys, 301306072a8648ce3d020106082a8648ce3d030107.
  • For P‐384 keys, 301006072a8648ce3d020106052b81040022.
  • For P‐521 keys, 301006072a8648ce3d020106052b81040023.

Now the Cipher Suites seem to have greater flexibility as shown by SSL Report: hp-67.com in the Handshake Simulation section. You will note that ECDH x25519 is being used with some of the simulated clients.

So there is more than meets the eye on selecting elliptic-curves and more than one choice to be made for TLS(SSL). Certificates are only one of the pieces that has a choice and it is presently limited to 3, other area (Cipher Suites) have more choices and at least 1 Safe Curve is available from a practical point.


This isn't generally something that the average implementation developer has to consider. Choices are largely already made by standards and crypto libraries (and you really shouldn't write your own crypto library, unless you already know all these things by heart).

In a web context, ECDSA is generally only used with P-256 or P-384. Chrome doesn't even support anything else.

For the Diffie-Hellman key exchange, modern implementations often also support x25519, but that's pretty much it. Everything else is niche. Sure, if you're doing your own thing you can do what you want, but if interoperability or certifications are required, you're not going to do well with much else.

Also, while the SafeCurves website is a really great resource, it is often misunderstood.


@Nummer378 Should I have not posted this?
Should I delete it?


No need to delete anything, it's all good :grinning_face_with_smiling_eyes:.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.