124

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?

-----BEGIN DH PARAMETERS-----
MIICCAKCAgEAsb8mBiOtYJZ3XR7f/rCXQwpAAnUPXf7l9pwjYxxy30A7rIzMTrsz
bXuhhEmzroJcDqKbu2nIzOBNO6HuyQ3n9x/ZbY5kiEt6q7UrB5jC9LwyPASZhd/F
6xLC7yqFs9sdCaXzuyMS4Ep5sPH6lOvftdsuGZZF9HriTepv/lpD1cPtab+3vHZX
IELVc2WBwVzvNRGd/SQB8RJ+NNF8IseCV/pb/tb67O1p7sn+JsD5xgNB7Lte/XjD
QBXv86aNuI2Z6zAuCiQsQ4rJuWcdnyAz0+zW9DRHz0osB1+IfHYcf4tNmvMKbC8E
u/vI+Q2WsMXkbTyhWibV2zH8cXdfsj5xpIgtbxm4G1ELGFgqyX9LD0IddXE7Md86
qwoKSTBNOyCIEZwwNfKDXY0b7zzObv7b3//J7gM323bAcm9g3uVaYBxF7ITd/jGm
AxpnF55mfhAOYemPZtNinnPAdvqf6BhZe29wfVC1yCIhg7ec9spRaFn2GgW0eL3d
q/+Ux8DJBtzKE10YyLa7bh1Dhml/xtA7rpqLL4+jg5c6lLEvSGmAZtm879NYS0za
33/2LN0/KB4z46Ro5hwqq3UIIe8oDsxdlNGb0mb9F0lKw5//J24PK/t11qMt8yuG
oKUE7TkDfwXlEBxd/ynW2/kLIjhG1JG55Vz8GWet8+ZGzfl/VQeUb9MCAQI=
-----END DH PARAMETERS-----
user
  • 7,670
  • 2
  • 30
  • 54
Ben Richard
  • 3,006
  • 5
  • 16
  • 18
  • 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 – 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 04 '20 at 06:57

3 Answers3

97

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.

SEJPM
  • 9,500
  • 5
  • 35
  • 66
  • 13
    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 07 '19 at 20:36
  • @TheQuantumPhysicist true randomness helps you with not accidentally generating the same parameters as other people. – SEJPM Aug 08 '19 at 08: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 08 '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 08 '19 at 18:14
  • @SEJPM Got it. Thanks for the explanation. :-) – The Quantum Physicist Aug 08 '19 at 21:26
  • @SEJPM 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 04 '20 at 06:42
  • @nuclear I updated my answer. The TL;DR is that the client guesses from a standardized set and if that fails, the server sends back the actually supported parameters. – SEJPM Oct 04 '20 at 08:48
  • @SEJPM Is client sends parameters and public key in key_share extension(32 bytes)? Could you give me where these standardized set defined in? Thank you!! – nuclear Oct 04 '20 at 13:16
  • @nuclear It's actually more of a "send a public key for every supported parameter set that is likely to be supported server-side" which is not a standardized list. However choices like secp256r1 and curve25519 should be common. And yes the key_share extension contains the chosen parameter sets as well as the according public keys. – SEJPM Oct 04 '20 at 13:31
  • @SEJPM Thank you, Does the following safe prime(https://en.wikipedia.org/wiki/Safe_and_Sophie_Germain_primes) are used in TLS 1.3? :) – nuclear Oct 04 '20 at 15:05
  • @nuclear usually, TLS 1.3 does not use FFDH anymore but rather elliptic curves, so it's highly unlikely that any parameter set from that article would end up in a client's first round of tries. – SEJPM Oct 04 '20 at 15:16
  • @nuclear+ in TLS1.3 IF you use FFDHE at all (which as SEJPM says is now rare, ECDHE is better and ubiquitous) you only use the groups from RFC7919 Appendix A, as referenced by RFC8446 4.2.7, and all of those are 'safe' primes (p=2q+1) as well as 'NUMS' (nothing up my sleeve), but none of them are in wikipedia. – dave_thompson_085 Oct 05 '20 at 04:02
11

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.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
4

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

Sebi
  • 1,391
  • 9
  • 16
  • 1
    The session key is not exchanged. Otherwise all the DH stuff would be pointless. It is calculated independently by both parties. – user207421 Mar 21 '17 at 04: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 04 '19 at 11:22