Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?
share|improve this question

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

share|improve this answer
    
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 Dec 3 '13 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 Dec 3 '13 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 Dec 3 '13 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 May 16 at 12:45

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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