Diffie-Hellman key generation

Question

We all see X509 certificates with 2048/4096-bit RSA key pairs; however, it is difficult to understand how they work in the DH part of the TLS handshake.

At most, they authenticate and sign. DH 4096-bit generates "parameters," which I know is time-consuming.

When the server generates those parameters, what do they look like? What has the 4096-bit key become? I generated certificates with Let's Encrypt, but I cannot recall seeing the process. I only saw an RSA key pair, I think. Yet DH will be used for the session key exchange, not the RSA keys.

So far, I have only found one document that talks about public and private keys for Diffie-Hellman, even though most people on the web say there are public and private keys with DH.

Answer 1

Generally, named curves are used for DH and servers don't generate parameters themselves. These are configured using a specific number in the TLS protocol. The keys on the other hand are always re-generated preferably for each connection for TLS. This is assuming that an ephemeral key exchange is used, which can be identified using the postfixed letter E in the cipher suite for TLS 1.2 (DHE or ECDHE). Because of this the shared secret should always be specific to a TLS session.

RSA is a completely separate algorithm from DH. The RSA private key is used to authenticate the TLS handshake including the freshly generated DH public keys. RSA doesn't require any parameters (other than the key size). The color explanation of DH doesn't have anything to do with RSA. In principle you can use an entirely different key size for RSA and DH, although it makes sense to use a set that has approximately the same strength.

Let's Encrypt will never know about the DH parameters, they are specific to the TLS connection and are not included in a certificate.

Answer 2

RSA keys are generally used for signing and authenticating the key exchange. It is not used for (EC)DH, which uses freshly generated one-time-use public/private key pair for key exchange.

The color analogy within DH is to show that if an adversary only has two public keys, it won't be able to calculate the DH shared secret used to derive session keys. This is known as tje CDH assumption.

To derive this secret need the other side's public key and your own private key, thus only the ends involved in the key exchange can generate session key. The commutative nature of modular exponentiation means that both sides will get the same shared secret.

Of course the color analogy is only for laymen. The two mixed colors are of no equal roles, like the color analogy might mislead people into thinking. The shared color is a generator (a group element), and the private color is your private exponent, an integer less than the order (or the number of elements) of the (sub)group.

---

The DH parameters are generally not generated, but a known or named group is used. You might think using new parameters may lead to better security, which indeed it may (I am not sure about possible plantation of back doors). However, finding a good DH group for such long keys is quite hard. On top of that the other side must do a lot of work to validate the new parameters (like one extra modular exponentiation and two primality tests).

I once tried finding a 1024 bit safe prime using Java code and it did not stop for five minutes. And DH modulo minimum requirement today is 2048 bits. Finding a good EC(DH) curve is just as hard if not harder. You need to make sure it has a large prime order subgroup amongst others, and finding the order of a EC curve is quite expensive. If it does not meet any criteria of a usable curve you will have to start all over again.

So we usually use a small number of named curves.