# Trying to understand the use of ECC in TLS certificates

I was looking the certificate of this website: https://www.cloudflare.com that has an ECC based certification.

I'm just curious to know if is possible to understand which elliptic curve is used and which point is used.

Another thing: I don't understand why in the certificate there is a RSA 2048 public key and not an ECC key.

• usually one of the standard NIST-Curves is used (P-256, P-384, P-521 IIRC). May you provide us with a screenshort or anything showing the said ECC certificate? Or do you mean by "has ECC based certification" that ECC certs are offered? – SEJPM Jun 3 '15 at 21:40
• Thanks for your answer, I mean this: postimg.org/image/6un05zdt5 TLS ecdhe that is a ECC – NxA Jun 3 '15 at 22:06

ECC is indeed used by CloudFlare's website but only for the session key agreement. The authentication is performed using an RSA 2048 bit private key. The corresponding RSA public key is in the certificate. In other words, although ECC is being used, it is not used for authentication and therefore not part of the certificate.

The ciphersuite is:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256


Which means TLS with ECDHE (ephemeral Elliptic Curve Diffie-Hellman) key agreement, RSA based authentication (and thus certificates). The ephemeral part means that no static private ECDH key is used on the server and no public ECDH key is therefore present in the certificate.

Or, as specified by RFC 4492 section 2.4:

2.4 ECDHE_RSA

This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message must be computed with the corresponding RSA private key. The server certificate MUST be signed with RSA.

To state that the CloudFlare website is using ECC certificates (not certification, that term means something else) is therefore incorrect. It uses a cipher suite that performs ECDH key agreement.

The used explicit or named parameters are determined during the handshake. The client has the ability to include a list of supported curves, ordered to preference RFC 4492 section 5.1.1. The point format - uncompressed (default) or compressed - can also be indicated. As the EC points themselves are ephemeral (short-lived) you can only retrieve them by analyzing the handshake.

For completeness the rest of the ciphersuite: AES-128 bit encryption using GCM authenticated (AEAD) mode encryption. The final SHA-256 is used as definition of the keyed hash (HMAC) used for key generation (or key derivation) and validation.

• Thanks for the answer, following your explaination I've found a website that use TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 When i go to the parameters, just to understand which curve is used and the value of P and B i've found this string: ANSI X9.62 elliptic curve prime256v1 (aka secp256r1, NIST P-256) This means that the values that are used are the raccomanded values of NIST or the owner can use different values? In this case how can i retrieve them? (Curve equation, P, and the other public information) – NxA Jun 4 '15 at 7:59
• The value of the private key (a vector of 256 bits) and public key (a single point on the curve) will of course be generated by the owner. The other parameters are set if you use a well specified curve. – Maarten Bodewes Jun 4 '15 at 8:06
• So what are you saying is that the following parameters are fixed (and are the same of NIST definition). So for secp256r1 : $$p = 2^256 - 2^36 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1$$ The curve $$E: y2 = x^3+ax+b$$ over F256 is defined by: $$a = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000$$ $$b = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000007$$ The base point G in compressed form is: $$G = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798$$ – NxA Jun 4 '15 at 8:43
• The parameters are fixed. I'll check the curve when I get home. I only have the uncompressed version on screen. I get invalid point compression when I try to decompress g. You should use {} around e.g. 256 in above equation: $2^{256}$ – Maarten Bodewes Jun 4 '15 at 12:03
• My big mistake... the stuff that i wrote was for the curve secp256k1 not for the curve secp256r1.. I have found all the stuff i need on the nist website – NxA Jun 4 '15 at 14:10