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?

2 Answers 2


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.

  • Are you sure your answer is correct? If I got it right, a 1024 bit DH key gets it's name from the size of the modulus being used. And that modulus is the prime number which is part of the DH params (the DH params are a generator and the prime modulus). Therefore only DH params of 2048 bit (modulus of 2048 bit) and RSA keys of 2048 are comparable. So I would argue that your statement "you're on the same level with respect to factorization with a 1024-bit DH prime versus a 2048 RSA key" is not correct.
    – 0x80
    Commented Dec 3, 2013 at 9:22
  • DH params contain two primes; one is typically 2 but sometimes 5, that's your generator. The other is the interesting prime, your modulus. It's the one that 1024 bits long. In RSA, your modulus is the product of two primes (p and q). A 2048-bit-key is the product of a pair of 1024-bit primes. In both cases, the primes are 1024 bits long.
    – tylerl
    Commented Dec 3, 2013 at 18:17
  • @0x80 while 1024-bit DH isn't exactly equal to 2048-bit RSA, it's 1024b DH is closer to 2048b RSA (considered unbreakable) than it is to 1024b RSA (considered unsafe). 1024b DH is considered unbreakable by current and foreseeable technology. Hence the rough equality.
    – tylerl
    Commented Dec 3, 2013 at 18:32
  • I'm not a mathematician, I just try to find an answer. :) But there seem to be different, conflicting answers. You are right that in both cases the primes are 1024 bits long. But while DH uses the prime as modulus, RSA doesnt - it uses the product of the two primes, which is n (as you said). Since the time to break DH and RSA seems to rely on the modulus length and since the algorithms to do that are "similar", both moduli need to be the same length. Therefore you can't compare the lenght of the prime numbers, but the moduli. I took this from here: security.stackexchange.com/a/5497
    – 0x80
    Commented May 16, 2014 at 12:45
  • 8
    You probably want to update this answer in light of weakdh.org ... at least remove the suggestion that it's OK to use the same prime as everyone else.
    – derobert
    Commented May 20, 2015 at 20:06

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.

  • 2
    There are rational reasons for using "safe" primes. The -dsaparam option requires the application to set the "single dh use" option. Details: openssl.org/news/secadv/20160128.txt
    – Nappy
    Commented Jan 28, 2016 at 15:29
  • And "is still unbroken" must be read as "noone has publically admitted to breaking it". Commented Jan 23, 2018 at 6:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .