6

As the question already states, I'd like to know if the dh1024.pem file, generated by ./build-dh in openvpn, is dependent on the ca.(crt|key) file.

The reason was that I needed to ./clear-all the keys, but kept the dh1024.pem file open in an editor, and re-saved it after clearing the keys. Then I went on with creating the ./build-ca, ./build-key-server and ./build-client.

For that matter, could the dh*.pem file be dependent on the server key, or on anything else? Or is it just a file with a chunk of well-computed data with no dependencies?

Kind regards.

  • dh1024.pem is used on the server side. It is what negotiates authentication as per RFC2631 (ietf.org/rfc/rfc2631.txt). You can get rid of it, but you'd need to regenerate it, otherwise connections will fail – munkeyoto Nov 4 '14 at 15:07
  • @munkeyoto thanks, so it doesn't depend on any of the files generated by any of the ./build-*.sh scripts? Do any of those generated files depend on the dh*.pem file? – Daniel F Nov 4 '14 at 15:12
  • The file is only generated to negotiate authentication. If you deleted the other files, and are recreating everything from scratch, it only makes sense to regenerate that file as well – munkeyoto Nov 4 '14 at 15:32
12

That file has no dependency on any certificate or private key. It is not secret either. It can even be shared between various servers that don't necessarily trust or even know each other.

The dh1024.pem file contains Diffie-Hellman parameters. The DH key exchange is an algorithm played in a given finite group; namely, integers modulo a prime p. For a successful DH:

  • There are known parameters p (a big prime) and g (a conventional integer in the 2 to p-2 range, known as the generator).
  • Party A generates a random secret value a, computes ga mod p, and sends that to party B.
  • Party B generates a random secret value b, computes gb mod p, and sends that to party A.
  • Party A computes (gb)a mod p (raising the value received from B to its secret exponent a).
  • Party B computes (ga)b mod p (raising the value received from A to its secret exponent b).

The magic of DH is that both A and B end up with the same value, that eavesdropper cannot recompute from the two values that were sent across the wires.

In all of this, the p and g values are the "parameters" and must be known to both parties; but they are not secret. Security is ensured as long as:

  • p is large enough (at least 1024 bits; arguably, 2048 bits would be better).
  • p was not generated with a "special structure" that makes discrete logarithm easier.
  • g generates a subgroup of integers modulo p whose size is a multiple of a big enough prime (the order of g modulo p is the smallest integer r ≥ 1 such that gr mod p = 1; it is required that the greatest prime divisor of r has length at least 160 bits, preferably 256 bits or more).

The whole World could use the same parameters; but many people prefer to generate their own parameters, just to be sure that their parameters were not "cooked". This is what build-dh does. The resulting file (dh1024.pem) contains p and g, but nothing else. These values are not secret. They do not depend upon any external element, neither certificate, private key, or anything else.

| improve this answer | |
  • Thanks, and none of the ./build-key(-server) scripts depend on it? This means that I could replace the dh*.pem file with a new one at any time? – Daniel F Nov 4 '14 at 16:00
  • 2
    You should be able to replace it at any time, although you must probably restart the server software to make it take the new file into account. OpenVPN uses a TLS handshake for each new client, and the DH parameters are used by the server (and sent to the client) during that handshake. However, there is little point in changing the file; you can, but there is no known security issue that such a change would solve. – Tom Leek Nov 4 '14 at 16:25

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.