I've finally ran SSL server test on my server and was presented with:

This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.

So I tried to generate stronger using openssl dhparam 8196, but it didn't finished even after a day. So, two questions:

  1. Is it an overkill and is 4096 sufficient for now?

  2. Can I make openssl dhparam run on multiple cores?

  • 2
    I believe it is standard to use ECDH these days.
    – timuzhti
    Dec 20, 2015 at 13:01
  • Regarding "overkill": Depends; what are you trying to kill? (This is not actually facetious. Who's your expected/intended adversary?) Dec 20, 2015 at 22:45
  • ssllabs.com/ssltest :) was complaing about weak DH. In real world though? Mostly worried about ISPs injecting html/javascript into traffic.
    – graywolf
    Dec 21, 2015 at 1:09
  • @Paladin, browser don't even support 8192bit DH ...
    – J-16 SDiZ
    Dec 21, 2015 at 5:06
  • 2
    (and @Josef) openssl can generate large DH params much faster if you say -dsaparam to use the DSA rule: instead of a maximal subgroup (P-1)/2, a 256-bit subgroup which is well matched in strength to 3k and close enough to 4k but not very much more. See security.stackexchange.com/questions/42415/openvpn-dhparam and security.stackexchange.com/questions/95178/… Dec 23, 2015 at 5:43

3 Answers 3


Edit 2015-12-23Wed.: I'm not happy with this answer anymore. While I still think that 8k DHParams are misplaced effort and overkill (and you're better off with ECDH) the explanation that I gave was bogus. Turned into "Community Wiki" mode for now. May rework in future. Old post below.

1) is it an overkill and is 4096 sufficient for now?

Generally, yes. I don't think that there is a lot of use in making that key longer than the key in your certificate. And 8k certs are very uncommon at the moment. 2k or 4k are the norm.

A cipher suite uses several crypto mechanisms plugged together. (Public keys for the ephemeral exchange. Public keys for the certificates. Hash functions/MAC functions for the certificate. Hash functions/MAC functions for the session encryption. Symmetric cryptography for the session encryption, etc.) They work something like links in a chain. And like a chain: it's the weakest link that counts. Any effort spent hardening the non-weakest link is likely effort wasted.

(Now the several crypto parts that make up a cipher suite are not immediately comparable but there is a rough consensus. KeyLength.com offers a calculator for that.)

(I think there is even a word for the "make every link equally hard" approach. But I can't remember at the moment.)

2) can I make openssl dhparam ran on multiple cores?

No idea. Don't think so. But I don't think you'd need to either. So bullet 1.

  • 3
    Keys used for confidentiality need remain secure for as long as the data needs to remain confidential. Keys used for authentication only need to be secure for as long as they're in use. So it makes sense to use bigger keys for confidentiality. Dec 22, 2015 at 15:23
  • You're right. I should have said that. Dec 22, 2015 at 18:23
  1. Is it an overkill and is 4096 sufficient for now?

Yes. Even 2048 is considered enough.

  1. Can I make openssl dhparam run on multiple cores?

The code works by looking for random safe primes. You can run it several times in parallel and when one finishes you have your parameter set.

  1. Is it an overkill and is 4096 sufficient for now?

Depends on what security level you aim. 8192-bit dhparam is roughly equivalent of 192-bit symmetric key encryption. If you'd like to have 256-bit grade encryption, then 8192-bit dhparam will be too weak to meet that requirement. If you're fine with 128-bit encryption, then 4096-bit dhparam is enough.

You might want to take a look at Keylength page for detailed tables with key length recommendations for symmetric, discrete logarithm, and ECC algorithms from different organizations.

  • so for 256-bit encryption I would need even stronger then 8192-bit? But that would take forever to generate, won't it?
    – graywolf
    Dec 22, 2015 at 9:55
  • 1
    @Paladin You could use additional entropy generators to speed up the process (hardware devices, haveged, etc.). But in my opinion you'll be fine with 4096-bit dhparam - a bit over 128-bit symmetric key equivalent is pretty reasonable security level for next couple of years. We might start to worry about it when machines able to execute Shor's algorithm for big numbers will appear in news. Dec 22, 2015 at 11:54
  • @Paladin it will be a lot faster if you just use a strong prime instead off a safe prime like openssl dhparam does. Since almost no software supports more than 4096bit DH parameters and ECDH is more secure (probably) and way faster, there is also no point. You probably won't find software supporting such lagre primes for DH but no ECDH.
    – Josef
    Dec 22, 2015 at 14:09
  • @MichałStaruch The process has nothing to do with how long it takes to gather entropy. In fact (for the ssh-keygen implementation, at least), it gets a random value once and increments it, checking for primality along the way. It is so slow because it is running a whole bunch of primality tests!
    – forest
    Dec 9, 2017 at 10:13

You must log in to answer this question.

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