15

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?

Vilican
  • 2,703
  • 8
  • 21
  • 35
graywolf
  • 385
  • 3
  • 10
  • 2
    I believe it is standard to use ECDH these days. – timuzhti Dec 20 '15 at 13:01
  • Regarding "overkill": Depends; what are you trying to kill? (This is not actually facetious. Who's your expected/intended adversary?) – Eric Towers Dec 20 '15 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 '15 at 01:09
  • @Paladin, browser don't even support 8192bit DH ... – J-16 SDiZ Dec 21 '15 at 05: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 http://security.stackexchange.com/questions/42415/openvpn-dhparam and http://security.stackexchange.com/questions/95178/diffie-hellman-parameters-still-calculating-after-24-hours – dave_thompson_085 Dec 23 '15 at 05:43

3 Answers3

17

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.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • 2
    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. – CodesInChaos Dec 22 '15 at 15:23
  • You're right. I should have said that. – StackzOfZtuff Dec 22 '15 at 18:23
11
  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.

Community
  • 1
otus
  • 657
  • 6
  • 13
3
  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.

Michał Staruch
  • 396
  • 2
  • 4
  • 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 '15 at 09: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](https://en.wikipedia.org/wiki/Shor's_algorithm) for big numbers will appear in news. – Michał Staruch Dec 22 '15 at 11:54
  • @Paladin it will be a lot faster if you just use a [strong prime](https://en.wikipedia.org/wiki/Strong_prime) instead off a [safe prime](https://en.wikipedia.org/wiki/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 '15 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 09 '17 at 10:13