What exactly is the purpose of these DH Parameters?
These parameters define how OpenSSL performs the Diffie-Hellman (DH) key-exchange. As you stated correctly they include a field prime p
and a generator g
. The purpose of the availability to customize these parameter is to allow everyone to use his / her own parameters for this. This can be used to prevent being affected from the Logjam attack (which doesn’t really apply to 4096 bit field primes).
So what do they define?
A Diffie-Hellman key exchange operates as follows (for TLS 1.2 and before1):
The server Bob uses these parameters to calculate B=g^b mod p
. He sends (B,g,p)
to the client Alice who computes A=g^a mod p
on her own along with K=B^a mod p
. She sends A
to Bob and he computes K=A^b mod p
. As A^b=g^(a*b)=g^(b*a)=B^a mod p
holds both parties will agree on a shared key. The parameters p
and g
define the security of this key-exchange. A larger p
will make finding the shared secret K
a lot harder, defending against passive attackers.
And why do you have to pre-compute them?
Finding the prime p
means finding a value for p
for which p=2q+1
holds, with q
being a prime. p
is then called a safe prime.
Finding such primes is really computational intense and can’t be afforded on each connection, so they’re pre-computed.
Can they be public?
Yes, it’s no risk publishing them. In fact they’re sent out for every key-exchange that involves some Diffie-Hellman (DH) key exchange. There are even a few such parameters standardized for example in RFC 5114. The only possible problems with publishing may be that a powerful attacker may be interested in performing some computations on them, enabling him to perform the Logjam attack. However as your parameters use a 4096 bit field prime p
this isn’t a risk.
To explain why publishing them isn’t a risk you may want to take a look at the above key-exchange description and note that the parameters are only used as a base for the computations but all the secrets (a,b
) are completely independent of g,p
.
1: For TLS 1.3, the client first guesses the parameters of the servers from a standardized set. Then it A
s for all of these parameters to the server who then either responds with a B
of his own along with the choice of parameter set or responds with a list of parameters actually supported – which may include the custom generated ones this Q&A is all about.
From the openssl wiki page for the Diffie Hellman Key Exchange:
If Alice and Bob wish to communicate with each other, they first agree between them a large prime number p, and a generator (or base) g (where 0 < g < p).
Alice chooses a secret integer a (her private key) and then calculates g^a mod p (which is her public key). Bob chooses his private key b, and calculates his public key in the same way.
So Alice will always have the same private key, but for each set of DH parameters g and p, she will get a different corresponding public key.
Further down that page it says:
Since parameter generation can be an expensive process this is normally done once in advance and then the same set of parameters are used over many key exchanges.
And on the openssl wiki page for Diffie Hellman Parameters it says:
To use perfect forward secrecy cipher suites, you must set up Diffie-Hellman parameters (on the server side)
When static Diffie Hellman (DH) is used (as opposed to Ephemeral Diffie Hellman (EDH)) the DH parameters are set for the server and can actually be embedded in a certificate, so they are public see this answer. The secrecy comes from Alice and Bob’s private keys.
The purpose of the DH parameters is to exchange a secret(a large prime integer belonging to a prime order group) that will be used to encrypt a transcript of messages within a session.
Ephemeral DH offers forward security, meaning that the session key(exchanged at the beginning of the session) is deleted upon session termination. Thus an attacker could not retrieve the messages exchanged between two parties for more than the last session(as each session has a different secret key which is always deleted upon termination).