What are the 'P' values in some cipher string?

P521 is an elliptic curve

“P521” is a dead giveaway for an elliptic curve which SECG and TLS formally call secp521r1 and which NIST FIPS 186-4 calls P-521. An elliptic curve is a mathematical domain used by elliptic curve algorithm such as ECDH and ECDSA.

Curves are generally known by a name that includes some information about the type of curve and the key size¹. The letters “sec” stand for SECG (Standards for Efficient Cryptography Group), and the specifically for the curves described in SEC2. The following P is because the curve is over a prime field (a finite field whose number of elements is prime). 521 is the bit size associated with the curve. The R indicates that certain parameters of the curve were generated at random, and the final 1 is because this is the first (and so far only) secp521r curve.

Curve parameters are typically chosen in such a way as to make calculations faster, given mathematical constraints to ensure that the parameters have the required security properties. In particular, it helps if the size of the field differs from a power of 2 by as few bits as possible, because that allows fast modulo reduction. It happens that 2521-1 is prime. There's no prime that's nearly as nice and has 512 bits or a little less.

In terms of sizes, today, 256 bits is considered enough for elliptic curves for ephemeral key exchange (ECDH) and signature (ECDSA). As usual, larger sizes give more resistance (but being more resistant that “unbreakable in practice” isn't a practical benefit) at the cost of less performance.

Elliptic curves and TLS cipher suites

A TLS cipher suite is a set of parameters that describe how the TLS protocol sets up the keys that are used for the communication. See How does SSL/TLS work? for more information. For example, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 means to perform a key exchange using elliptic-curve Diffie-Hellman (ECDH) with single-use (E for ephemeral keys), verifying the server's signature with RSA, and using AES-128-CBC to encrypt the secure channel and HMAC-SHA-256 to authenticate it. The client and the server negotiate which cipher suite to use at the beginning of the TLS connection (the client sends the list of cipher suites that it supports, and the server picks one and lets the client know which one). The choice of elliptic curve for ECDH is not part of the cipher suite encoding. The curve is negotiated separately (here too, the client proposes and the server decides).

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 is not a thing that's different from TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256. It means to use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 with secp521r1 for the ECDHE part.

Most TLS server software allows the administrator to configure which security parameters it's willing to support. Sometimes this is done independently for each piece (which key exchange types, which key agreement algorithms, which hashes for signature, which elliptic curves, which hashes for HMAC, which symmetric ciphers, which AEAD algorithms, …). Here you select which elliptic curve to support separately for each cipher suite. The choice of which parameters to configure together is a matter of convenience vs flexibility.

¹ More precisely, it's the size in bits of the coordinates of points on the curve. But for all common curves, that's also the size in bits of the private key.


I would suggest that these mean the curve used within the ECDHE key exchange, i.e. NIST P-256, NIST P-384 and NIST P-521. These are not actually part of the cipher itself (i.e. the 16-bit cipher id used in the TLS handshake) but it looks like Microsoft has added it to their cipher syntax.

There's really no difference between cipher suites with and without the "P value", except that one is being explicit about which elliptic curve it's using, while the other will use a system default.


They are the naming for NIST ECC Curves. Also see at NIST.FIPS.186-4

NIST  RFC 4492

P-256 secp256r1  
P-384 secp384r1 
P-521 secp521r1