For a Diffie–Hellman (D-H) key exchange (TLS) the server generates a prime p and a generator g, which is a primitive root modulo p.

When setting up a webserver with SSL/TLS (e.g. nginx) one can use a directive ssl_dhparam dhparam4096.pem
The dhparam4096.pem file can be generated using openssl dhparam -out dhparam4096.pem 4096

What exactly is the purpose of these D-H Parameters?
Can they be public? (i.e. can I publish my dhparam4096.pem file?)

Here are the contents of my dhparam4096.pem file:
That seems to be a hexadecimal representation of a 4096bit integer, is that correct?

  • 5
    The answers cover the purpose. As far as representation, all (OpenSSL) PEM files are base64 (not hex) encodings of an ASN.1 DER (or rarely BER) structure. Here the ASN.1 structure is DHparameter, and in addition to ASN.1's TLV overhead it contains the large prime p, here 4096 bits, and the generator g, usually small and here 2. You can see this with openssl asn1parse <pemfile. – dave_thompson_085 Jul 20 '15 at 11:58
  • But when I look up TLS 1.3 handshake phase. It's the client's job to start to send the first handshake request with key_share extension. If p, g comes from the server, how the client generates A without p, g? – nuclear Oct 4 at 6:57

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

| improve this answer | |
  • 6
    Good to see Bob, Alice and Trent after a long time. – Dojo Jan 18 '19 at 11:01
  • Thank you for the explanation. Why is true randomness necessary for dhparam then? It seems like we just need a non-secret number, which can be pseudo random. In dovecot instructions they mention that we require true randomness source for dhparam. – The Quantum Physicist Aug 7 '19 at 20:36
  • @TheQuantumPhysicist true randomness helps you with not accidentally generating the same parameters as other people. – SEJPM Aug 8 '19 at 8:04
  • @SEJPM I understand, but it's not a secret. Right? If it's not a secret, then why does it matter if I generate the same key as other people? – The Quantum Physicist Aug 8 '19 at 16:02
  • @TheQuantumPhysicist indeed, these parameters are no secrets and no immediate harm will come upon you if you use the same ones as others. So there's no cryptographic reason to force a strong random number generator to be used to generate DH parameters. However you still don't want everyone to use the same parameterset as then things like Logjam could ruin your day in the future. I suppose that the dovecot devs just went with the simplest solution for them which is to just throw a strong RNG at the problem. – SEJPM Aug 8 '19 at 18:14

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.

| improve this answer | |

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

| improve this answer | |
  • 1
    The session key is not exchanged. Otherwise all the DH stuff would be pointless. It is calculated independently by both parties. – Marquis of Lorne Mar 21 '17 at 4:11
  • And how do the parties make use of it as it must be known to each? – Sebi Mar 21 '17 at 13:38
  • 2
    @user207421 The algorithm involved is called "Diffie-Hellman key exchange". It is true that the session key is never transmitted, but "exchange" is the jargon. Sebi: The session key is calculate independently by both parties - but in a way that ensures they both calculate the same result (user207421 is using a rather more "plain English" meaning of "exchange"). – Martin Bonner supports Monica Mar 4 '19 at 11:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.