12
$\begingroup$

After reading this article, I started wondering how should I approach the problem of choosing p and g params in 1024-bit Diffie-Hellman key exchange.

In my project, I am going to establish keys between many users. Should I create different p and g for every one or e.g. every 100? Is there any tool that would generate me random and good p and g params (g to be generator of p group) which are considered cryptographically safe? Or is switching to 2048-bit the best solution?

$\endgroup$

1 Answer 1

17
$\begingroup$

I recommend avoiding Diffie-Hellman parameter generation. Instead, use a standardized DH group with a sufficiently large modulus (2048-bit or larger). For example, group #14 or #15 from RFC3526 (see sections 3 and 4) would be a good choice. Alternatively, switch to the elliptic curve variant of Diffie-Hellman and use Curve25519.

The article you linked to is based on a great paper that surveys a variety of problems with how Diffie-Hellman is used in the real-world. One part of the paper (section 4.2) describes how a well-funded attacker could feasibly break a 1024-bit Diffie-Hellman group. At a high-level, the attack works as follows:

  • The attacker chooses one Diffie-Hellman group.
  • The attacker performs some massive computation for that group.
  • The attacker uses the results of that computation to break any key exchanges made using that group.

The authors point out that a large portion of the web sites that support TLS with DHE use one of only five 1024-bit DH groups. They thus conclude that if a well-funded adversary performed five massive computations (one for each of the popular groups), the adversary could crack TLS Diffie-Hellman key exchanges cheaply and at a massive scale. This lead many to believe that standardized DH groups are a bad idea, and that we should be generating a new group whenever possible.

I think this is misguided for a number of reasons. First, group generation is hard to get right and can easily lead to much more disastrous vulnerabilities. That same paper discusses "weak and misconfigured groups", and points out that "failure to generate Diffie-Hellman primes according to best practices can result in devastating attacks".

Second, the attack they describe on 1024-bit DH groups can still be applied to randomly generated 1024-bit groups. The hope is that whatever key exchanges performed using your DH group just aren't interesting enough for anyone to bother spending the millions of USD required to break the group. This isn't much comfort though. In cryptography, we generally don't like "secure, except against rich people". We aim for a higher standard: "secure against the combined resources of the human race for the foreseeable future". DH groups with a large modulus can meet this higher standard, and it's OK if everyone uses the same large prime.

Note for TLS/SSL users: Use either ECDHE or DHE cipher suites (since these support forward secrecy). With DHE, follow the above advice on groups. With ECDHE, use the NIST P-256 curve (secp256r1), since Curve25519 is not yet supported.

$\endgroup$
4
  • 6
    $\begingroup$ I agree; use a standard 2048-bit group and you are fine. Alternatively (and probably better), use ECDHE with a 256-bit group. $\endgroup$ Commented Oct 19, 2015 at 8:00
  • $\begingroup$ I second the recommendation for elliptic curve DH over 2048-bit DH. Maybe you could add this to your answer? $\endgroup$
    – hakoja
    Commented Oct 19, 2015 at 9:09
  • $\begingroup$ Added some notes on ECDH. I agree that ECDH > 2048-bit DH. $\endgroup$
    – Tim McLean
    Commented Oct 19, 2015 at 18:17
  • $\begingroup$ Having recently read the weakdh (sorry I'm a few years behind the times), I'm still not sure why the take-away is "use bigger primes" instead of "use random primes." Is searching for a new $p=2q+1$ every once in a while that resource intensive? Having everyone use a handful of groups (when there are so many to choose from!) seems like a bad idea. $\endgroup$
    – yoyo
    Commented Apr 5, 2022 at 19:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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