2

Reading about the Logjam attack, I learned that Diffie-Hellman exchanges often* rely on the same particular 1024-bit key. I understand that back when DH was invented, even 512-bit keys were considered secure for decades to come. But did it never occur to the designers, or to many of the programmers who have worked on DH implementations over the years, that reusing the same primes could lead to an eventual (catastrophic) vulnerability?

Am I missing something with the computational difficulty? Generating your own p and g once, at the initial configuration of the service, ought to be enough and should guarantee immunity from any flaws with the standardised primes.

*: As in, two-thirds of current worldwide implementations often.

detuur
  • 121
  • 3
  • This feels more on-topic at `http://crypto.stackexchange.com/`, but I'm not voting to move because- for all I know- their might be a physical or otherwise non-pure-math attack this makes easier. – Parthian Shot Jul 12 '16 at 20:39
  • The inherent strength is more important than the re-use; weakdh.org itself approves group14 from rfc3526, a fixed group of 2048 bits, for SSH. For people who pay attention to standards (not many) and will listen to the US government (even less), NIST guidance required minimum 2048 for DH, DSA, _and_ RSA since Jan 2014 -- and that was a relaxation from their original schedule of Jan 2011. – dave_thompson_085 Jul 13 '16 at 06:43

2 Answers2

1

You can look the following questions about difficulties in generating your own DH key exhcange parameters and also using the standard DH group parameters: Is it safer to generate your own Diffie-Hellman primes or to use those defined in RFC 3526? and Where do I get prime numbers for Diffie-Hellman? Can I use them twice?

For plain Diffie-Hellman, what you need is p, q and g, such that:

  • p is a big enough prime (2048 bits are more than enough nowadays);
  • q is smaller, but still big enough (say 256 bits), prime value which divides p-1 ;
  • g is a generator of a subgroup modulo p with an order that is a multiple of q.

In most situations, it is not easy, and also not applicable, to create a DH key exchange group before the actual key exchange occurs. Note that, logjam exploits small primes used in DH groups(512 bits). I think, you should be safe if you use a DH group with a p of 2048 bits even if the the group is used by others too.

Community
  • 1
Makif
  • 176
  • 1
  • 6
  • Huh? Most protocols (TLS usually, SSH always, VPN I believe always) generate ephemeral DH (or ECDH) _keys_ at each exchange, but the _group_ is done in advance, at least hours if not days to months. Although I agree with your result, as commented on the Q. Also http://security.stackexchange.com/questions/89783/do-diffie-hellman-parameters-need-to-be-recreated-regularly and http://security.stackexchange.com/questions/90407/must-a-diffie-hellman-group-value-persist are post-Logjam. – dave_thompson_085 Jul 13 '16 at 06:46
  • @dave_thompson_085 In my answer, i stated that generating DH group is not very efficient, i didn't mean that generating ephemeral DH keys is not easy. I know that using ephemeral DH is good for PFS and it is the case for most up-to-date protocols. Also, in my answer, i only considered DH not ECDH because i thought the question is only about DH. – Makif Jul 27 '16 at 14:48
  • For the ECDH case, the EC domain that two parties are using in key exchange is generated before the key exchange and most of the time one of the [named_curves](https://tools.ietf.org/html/rfc4492#section-5.4) are used(at least in TLS this is the case). However, similar to DH, in ECDH we can, and we should, create ephemeral keys for each key exchange. This is different than creating EC domain each time we do a key exchange which is not an easy job in the first place. – Makif Jul 27 '16 at 14:51
  • Your tense misled me. You wrote "it is ... not applicable to create [the] group before the actual key exchange occurs." I read that as "we don't generate the group before the time of key exchange" -- so we must generate the group _at_ the time of key exchange. Apparently you meant "we don't wait until the time of key exchange to generate the group" -- so we must generate (or obtain) it in advance. **I agree with the latter.** (and FWIW +1 for the inconvenience) – dave_thompson_085 Jul 29 '16 at 08:44
0

The two-thirds number you refer to is specific to VPN servers using IPsec. I would wager to guess this is a result of Sys Admins and Security Individuals not taking the time to modify any more of the default settings in their server than they absolutely need to during configuration.

Or, it very well could be an issue with the specific implementation of IPsec as it pertains to a specific subset of VPN servers, for instance if that two-thirds is how Cisco implements it into their VPN or ASA devices (Since they are likely the world leader in hardware-implemented VPNs), or how some version of Linux implemented it into their server builds, or Windows Server, etc... At any rate, it seems like it may be more of an implementation issue than an actual problem with DH or IPsec itself, since both have been extensively examined by Security and Crypto specialists for years. DH is just the algorithm, as long as it is supplied with a prime number of X bits, the algorithm will perform it's job. IPsec is a framework used to implement security. The implementation is what actually picks and supplies the prime number to the algorithm, via the framework.

Mortesil
  • 61
  • 3