5

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.

4 Answers 4

3

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.

2
  • So the public key in the certificate is only used to verify the key exchange, and it is not used as a session key?
    – Sam Gregg
    Commented Feb 2, 2017 at 7:21
  • you can save the two additional steps at the beginning by signing the ephemeral keys with the key in the certificate
    – lalebarde
    Commented Feb 13, 2019 at 15:54
2

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.

2

Related questions:


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.
2

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.

In the early days of SSL/TLS the server's long term private key was used directly in the key exchange process to establish a shared secret between client and server. The downside of this approach is that if an attacker managed to compromise the server's private key they could go back and decrypt any previous sessions.

So nowadays, the best practice is to use a randomly generated "ephemeral" key for the key exchange process. The server's long term key is used to sign the key exchange process and hence provide protection from man in the middle attacks.

It would be possible to devise an ephemeral key exchange scheme based on RSA alone, but it would perform badly because generating RSA keys is an expensive operation. Generally, for a given security level, ECDH is considered the least expensive option for ephemeral key exchange. traditional DH is also used.

If a system was being designed from scratch, then ECDSA would likely be the obvious choice for signing the key exchange, and indeed ECDH with ECDSA is a supported option in modern TLS clients and servers.

However many server admins don't want to be bothered with maintaining multiple different certificates for modern and legacy clients. So ECDH with RSA remains a common option.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .