OpenVPN dhparam

Question

One of the steps for setting up OpenVPN is running the command openssl dhparam -out dh1024.pem 1024. The man page tells me this 1024 value refers to the number of bits.

• Why is the value 1024 suggested by the examples?
• Should I use a larger value like 4096?
  • What value should I use, how many bits are enough, why?
  • RSA 1024 bit keys are now considered weak, and it is often suggested that to use 2048 bit or higher. Does this type of situation apply to this dhparam file as well?
• The command to generate this file seems takes ~10 hours on the appliance I that I will be using as the OpenVPN server. Is it safe to generate this file on a faster machine machine and transfer it over, or should I treat it like most private keys, and keep it on that host only? How secret should this file be?

Answer 1

Much of this has been addressed before. See my answer and Thomas's answer to a related question for more info about DH and DH parameters.

The parameters are just primes, not keys. They don't need to be unique or secret, but they must also not be specially crafted by an attacker. The bit length refers to the size of the prime not a key, so it's not directly comparable to RSA. Note that an RSA key of 2048 bits is composed of a pair of 1024-bit primes, so you're on the same level with respect to factorization with a 1024-bit DH prime versus a 2048 RSA key.

As Thomas's answer linked above points out, the number doesn't need to be unique or secret, and in fact your crypto library may provide a DH prime that will work just fine (assuming you trust the source of the library). Or you can generate one yourself.

Additional Detail In Light of Recent Discoveries

First of all, the advice about prime size is largely still correct -- 512 is too small, and 1024 is probably good enough^{(some caveats apply)} while 2048 is definitely secure.

Additionally, though, a precomputation attack was demonstrated such that if you know the primes ahead of time, you can do the majority of the work of cracking a given DH exchange beforehand. It's a ton of calculation and takes a huge amount of time to compute all the possible vectors for a given set of primes, but if a single set of primes is used everywhere, then there's an incentive to spend the time and money because the result will be so widely useful.

This means that using the same primes as everyone else is something of a liability, because it's more likely that the precomputation will have been done by your attacker. So you probably will want to generate your own unique primes to keep yourself out of the attack pool. Further, if you, yourself, are such an attractive target that an adversary is willing to spend millions per month to attack you (e.g. Facebook-size targets) then rotating out your primes on a regular basis may be warranted.

As for the cost and effort required for doing this precomputation, the work for 512-bit primes can be done by a dedicated individual, for 1024-bit primes by a nation-state, and 2048-bit primes by perhaps an advanced alien civilization.

Answer 2

DH security relies on the hardness of Discrete Logarithm. For a randomly chosen prime p, that hardness increases with the size of p, using the best known algorithms. By some semi-freakish chance, it so happens that the best known algorithm for discrete logarithm has a lot in common with the best known algorithm for integer factorization (GNFS) and the same asymptotic running cost. Thus, a 1024-bit prime modulus for DH provides a security level that is very roughly equivalent to that of a 1024-bit RSA key.

If we look at the details, a 1024-bit modulus is a bit stronger than a 1024-bit RSA key, because through GNFS-for-discrete-logarithm and GNFS-for-factorization are very similar, their final step (linear algebra in a huge matrix) is harder for DL (the bottleneck is the matrix size; for factorization, matrix elements are single bits, while for DL they are integers modulo p, i.e. a thousand times bigger). To this date, RSA-1024 is still unbroken, and 1024-bit DH even more so.

Yet breaking 1024-bit DH is not completely unrealistic; it would take a non-negligible amount of dollars (billions) and the building of a dedicated, special purpose machine, and running time would still be counted in months or even years. But that is doable without invoking help from sci-fi concepts (helpful "very advanced" aliens) or theology (helpful deities). In that sense, yes, you should endeavour to use a larger modulus.

---

You don't want to use an oversized modulus because usage CPU cost rises quite sharply with that size (it should rise quadratically, but for some implementations it is rather cubic, i.e. 4096-bit costing 8 times more than 2048-bit). 2048 bits are fine.

An additional and quite vexing issue is that there are some widespread implementations of SSL that don't support DH modulus larger than 1024 bits. If using OpenVPN then you know that both client and server are OpenVPN, so you should not have interoperability issues.

The prime p and the generator g are not secret; they can also be shared. See this answer for details. You can perfectly generate them on some machine and use them on another. You can also set all appliances to use the same DH parameters; this implies no additional security issue.

---

Generation of the DH parameters with OpenSSL can take a lot of time because OpenSSL insists, for no good rational reasons, in generating so-called "safe primes", i.e. a prime p such that (p-1)/2 is also a prime. This is overkill and multiplies generation time by a huge factor (several hundreds). What is needed for DH is that p is prime and p = qr+1 for some large enough q; a 256-bit q would already be quite fine. Going to a "safe prime" (i.e. q of size 1023 bits for a 1024-bit p) does not make things safer, despite the name (this is a piece of old lore that transformed into a myth because of poor terminology).

"Safe primes" have a minor performance advantage (upon usage, not upon generation) in that they allow the use of g = 2 as generator; but that advantage is slight (it matters only for one half of the DH key exchange, and it is mostly nullified by window-based optimizations on the modular exponentiation).

If you really wanted to generate DH parameters on each appliance (which is not useful), then you could add the flag "-dsaparam" to the command-line to generate DH parameters without insisting on having "safe primes":

openssl dhparam -dsaparam -out dh2048.pem 2048

This should be vastly faster. But generating the DH parameters on a PC and simply hardcoding them in all your appliances is even simpler, and it is safe.