# Diffie-Hellman key generation

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.

• Most (but not all) SSL/TLS certificates contain RSA public keys. In that case, server signatures made during the key exchange process must be done using RSA signatures. However, there are some SSL/TLS certificates in use that contain ECDH public keys. In this case, ECDSA is used for signing. See security.stackexchange.com/questions/227761/… for more info. Feb 9 '21 at 23:13
• Moderator note (updated): Thanks to @Patriot for improving the question.
– fgrieu
Feb 10 '21 at 7:42
• Hi @fgrieu I didn't expect my message to land here to be honest (I'm kind of new to stackexchange, I only knew about the security sub). I guess I had a hard time trying to phrase what is confusing in my mind, hence my message being confusing as well. After reading the answers, I see no one really explained what I wish to understand. This definitely makes me feel my post is wrong. I'm going to comment people's answers so maybe I can bring more details about what is still confusing and end up with the right answers. Sorry for that and I will understand if you close the subject. Feb 10 '21 at 9:35
• Thanks @Patriot for making me sound a bit less of an idiot. Feb 10 '21 at 16:28

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.

• Thanks for taking the time to explain. So when launching a openssl dhparam -out dh.pem 2048 command, I understand this is about generating a "DH group", itself containing the parameters based on a prime of 2048bits depending on the keysize given. This is already a great improvement in my understanding, a thousand thanks to you for that :-) Also, when I hear about a public key and a private key (1st part of your post), I understand the public key is the "prime" and it is the one 2048bit long. However, what is the private key in a DH context? Is it also 2048bit long or is it a smaller number? Feb 10 '21 at 17:51
• DH public key is not necessarily a prime, it is a (sub)group element. For EC(DH) groups a public key is a point (x,y) General DH group have three known parameters, the modulo $p$ (a prime number), the order $q$ (a prime number which is a factor of $p$) and a generator $g$ of subgroup of order $q$. Any positive integer $x$ less than $q$ can be a private key. Corresponding public key is $g^x$ DH actually still works if you use a larger composite order subgroup or even the entire group but is not recommended. In EC groups public key is $xB$ where B is the generator (base point). Feb 11 '21 at 3:56
• And about bit length, 2048 bit DH key is length of modulus $p$. Private key is generally shorter but should not be by much. In elliptic curve based groups, it is the length of field (or of the x/y-coordinate) of the point. Feb 11 '21 at 4:01
• Well, that could be part of your post above to make it complete :) Thanks again. Feb 11 '21 at 13:14

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.

• Thanks for your answer. In the end I guess what's confusing at first is the step "generate DH keys" when - for exampe - setting up and OpenVPN server. openssl takes some time to generate a .pem file with a 2048/4096 key. Diffie-Hellman is clearly mentioned and I can't relate that to anything from the DH explanations I read. Do you have any idea of what is that(those?) DH key(s?) generated on (some) servers? Feb 10 '21 at 9:37
• No, but that's just because I don't know the OpenVPN deployment specifics... You could try and ask it on Super User and include the test key (if it is a key and not just a set of DH parameters, I don't know - PEM is a generic ASCII armor, what's in there is specified in the header / footer lines). Feb 10 '21 at 9:42
• When setting up the server you have to generate this: openssl dhparam -out dh.pem KEYSIZE (and then it takes ages to generate what I have thought to be a keypair). I'm wondering what this is really about... if you have no idea I'll go to the superuser board as you recommend (had no idea about this board). Feb 10 '21 at 13:17
• Yeah, that's not a key, that's the parameter set specific to a certain key size... See the the answer by Manish; generally we keep to named parameters nowadays. If you'd generate a set yourself you'd do it once per server / service. DH key pair generation is fast, but that's certainly not true for parameter generation. Feb 10 '21 at 15:40