RSA or ECDHE for x.509 certificates-what does each do?

Question

I am relatively new to x.509 certificates, but recently i have been looking at the https connection padlock at the top of the screen. On certain websites, clicking on the pad informs me that the site is being securelyconnected through a key exchange, ECDHE, and these keys are signed with RSA. But, when i open the full certificate for the site, the public key is RSA 2048 bits. This confused me, as i thought the public key should be ECC 256 bits, and not an RSA key, as the key exchange is ECC, and not RSA.

I'm probably just missing something really obvious, but any help would be appreciated.

Answer 1

The public/private keys are (fairly) static and are normally 2048 bits or even 4096 bits - they are used early in the TLS negotiation, to verify the site's identity (and the client's, in the case of a client certificate) and to negotiate using asymmetric encryption a new key that will be a) shared between the client and server, b) unique to this connection and c) symmetric. This is the key that is actually exchanged and is shorter and what is used for actual transport.

Asymmetric encryption is (relatively) slow - that's why the session is actually encrypted with symmetric encryption.

Answer 2

A key exchange scheme consists of two algorithms:

• A key generation algorithms, which randomly selects a keypair;
• A key exchange algorithm, which takes as input your private key and the remote party's public key, and outputs a shared secret.

A signature scheme is a triple of algorithms:

• A key generation algorithm, which randomly selects a keypair.
• A signing algorithm, that takes a message and a private key and outputs a signature.
• A verification algorithm, which takes a message, a signature and a public key, and outputs a boolean indicating whether the combination is valid.

To perform an authenticated ephemeral key exchange, the parties must agree on a key exchange scheme and a signature scheme, and must have each other's authenticated signature public key. Then:

1. Both parties generate their own ephemeral key exchange keypair;
2. Both parties signs their ephemeral key exchange public key;
3. Both parties send their ephemeral key exchange public key to the other, along with the signature of that key;
4. Both parties check the signature on the other's ephemeral key exchange public key, and abort if it's invalid;
5. Both parties now use their ephemeral key exchange private key and the other's ephemeral key exchange public key to compute the shared secret.

This can also be done by having only one of the parties sign their ephemeral key exchange public key. That's how we normally do HTTPS, for example. The other party then doesn't get any guarantees that the other one is who they claim they are.

You can choose any combination of signature and Diffie-Hellman algorithms for this. It doesn't matter if the signature scheme is RSA and the key exchange scheme is ECDH. In that case step #1 uses the ECDH key generation algorithm to generate an ECDHE keypair, and then step #2 uses the RSA signing algorithm to sign that ECDHE public key. The signature algorithm doesn't care that the message it's signing is an ECDHE public key—it's just data for one party to sign and then the other to verify.

---

Another thing to note is that the title of your question reveals you're confused about something:

RSA or ECDHE for x.509 certificates-what does each do?

ECDHE is not involved in the certificate. The certificate contains a public signature key, metadata describing its owner, and signatures to help the recipient authenticate that the metadata is accurate. The most popular signature algorithm used in certificates is RSA. ECDSA is another alternative. ECDH is not relevant, because it's not a signature algorithm.

With certificates, the sketch algorithm above would be modified by adding two steps at the beginning:

1. Both parties send their certificate to each other.
2. Both parties use their PKI to verify the other's certificate, and abort if it's invalid.

Then the procedure continues using the certificate's enclosed keys to sign and verify the key exchange.

Answer 3

Related questions:

• What is ECDHE-RSA?
• What is the role of RSA in ECDHE-RSA?
• How ECDHE is signed by RSA in ECDHE_RSA cipher

---

Short answer: a TLS session has the following four major steps: (somewhat simplified)

1. Client and server agree on a cipher suite, my browser and security.stackexchange.com agreed on TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1), so let's use that as an example.
2. Client forces the server to proves who it is by doing a public key signature of data provided by the client. In our example, it would use RSA.
3. Client and server perform a key exchange to establish a session key. In our example, they'll use ECDHE with the curve secp256r1. The server will sign the ECDHE messages with its RSA key just to prevent a man-in-the-middle attack.
4. Once a session key has been established and both sides (and nobody else) has a copy of it, they will use this session key with a symmetric cipher for the rest of the session - in our example AES-128-GCM.