1

I cannot quite understand the role of Diffie–Hellman key exchange.

Does RSA SSL certificate work with the Diffie–Hellman key exchange or is it only used with an ECDSA certificate?

When is Diffie–Hellman algorithm used if a client still has an option to use the RSA algorithm suggested by most servers for compatibility?

t7e
  • 127
  • 4
  • 1
    The certificate has nothing to do with the key exchange. It's entirely separate. –  Apr 08 '20 at 14:09
  • @MechMK1: in 1.3 they are independent; below that they are linked although conceptually distinct. See https://security.stackexchange.com/questions/90422/ssl-certificates-and-cipher-suites-correspondence and https://security.stackexchange.com/questions/127542/can-we-restrict-cipher-suites-using-server-certificate (mine) – dave_thompson_085 Apr 09 '20 at 05:08

3 Answers3

2

No. tls_ecdhe_rsa_with_aes_128_gcm_sha256 would use an RSA certificate and tls_ecdhe_ecdsa_with_aes_128_gcm_sha256 would use an ECDSA certificate.

Read again about how TLS works, what Diffie Hellman key exchange does, what digital signatures do, etc.

Z.T.
  • 7,768
  • 1
  • 20
  • 35
0

In very broad terms, Diffie-Hellman (DH) is a key exchange algorithm that allows for parties with no prior knowledge to agree a shared secret, with this process happening securely over an insecure medium. In other words, the full negotiation can be analysed by an attacker and by design will take cryptanalysis to extract the secret key.

DH is used in some TLS cipher suites (mutually agreed to by client and server) in the initial phase of the connection for establishing a shared secret key for encrypting traffic within the tunnel, using a symmetric encryption algorithm.

Pedro
  • 3,911
  • 11
  • 25
0

During TLS negotiation (at least in 1.2 and below, I'm not sure how 1.3 changes things), the client and server agree a "ciphersuite". Basically the client sends a list of ciphersuites in order of preference and the server picks one, the server is supposed to respect the client's preferences but not all do. The server must pick a ciphersuite that is compatible with a certificate it has (servers can have multiple certificates for different ciphersuites).

Ciphersuites can be divided into "traditional" and "emphemeral". In a traditional ciphersuite the server's long-term secret is used directly in the process of establishing the shared secret. For example in a traditional RSA ciphersuite the client generates the shared secret and encrypts it with the public key from the certificate. The server then decrypts the shared secret using the corresponding private key. In a non-ephemeral DH ciphersuite (rarely if ever used) the certificate would contain a diffie-hellman public key which the client would use in the diffie-hellman process to agree the shared secret.

In ephemeral ciphersuites the shared secret is agreed using "ephemeral" keys and the long term key from the certificate is used to sign the key exchange. This means that if the servers long term key is compromised it cannot be used to decrypt passively sniffed connections, only to perform MITM attacks. It would in-principle be possible to design a cipersuite based on ephemeral RSA keys but this is not done because RSA keys are relatively expensive to generate.

RSA keys can be used for both encryption and signing, so a RSA certificate can be used with both traditional (TLS_RSA_*) and ephemeral (TLS_DHE_RSA_* and TLS_ECDHE_RSA_*) ciphersuites.

ECDSA keys on the other hand can only bs used for signing and thus ECDSA certs can only be used with ephemeral ciphersuites (TLS_ECDHE_ECDSA_*).

Peter Green
  • 4,918
  • 1
  • 21
  • 26