There is a web site weakdh.org, whose name alone would certainly cause some feeling of uncertainty in using DH among people who are not experts IMHO. Could some knowledgeable person kindly say something of the current security status of DH, i.e. what are the major precautions, if any, that one has to be aware of in applications of DH today?
I'm especially interested in the minimum key size needed for use in SSL, but will appreciate additional information.
The weakdh.org Web site is about the Logjam attack. Contrary to what the Web site name may suggest to the unwary, this is not about DH being weak; it is more about doing things weakly when using DH.
Diffie-Hellman works in a multiplicative subgroup of integers modulo a given prime p. To do some DH, you use some DH parameters which are:
For DH to be safe, you need the following:
p must defeat attempt at discrete logarithm through Index Calculus. This means that p must be large enough, and also must not have any "special structure" such as being very close to a power of 2, because such structures allow for improvements in Index Calculus. It so happens that size requirements for DH are about the same as the size requirements for RSA, though the underlying reason for that is intricate and partly coincidental. So, basically, use a random p of 2048 bits, and you will be fine.
q should be prime or have a prime divisor whose size is enough to defeat generic algorithms for discrete logarithm. If the size (in bits) of the largest prime divisor of q is z, then generic algorithms have a cost in 2z/2. For best results, arrange for q to be a prime of 256 bits or more.
Systems that use the parameters to perform a DH key exchange must generate a random integer between 1 and q-1 uniformly, using a cryptographically strong source of randomness, of course. If q is prime and larger than 256 bits, it suffices to choose a 256-bit random value to achieve 128-bit of security. However, if q is not prime, things are more complex: if q has size r bits, and the largest prime divisor of q has size e bits, and e ≥ 256, then one may choose a random value x of size r-(e-256) bits to get the usual "128-bit security".
When p is a so-called "safe prime", then p = 2r+1 for a prime r, so for any generator g that is not 1 or p-1, the order of g will be either r or 2r, so it suffices to generate DH secret keys x as random 257-bit values. The "safe primes" are not actually any safer than other primes, except for that point: they tolerate the choice of relatively small DH secret keys for any generator.
Last but not least, DH is a key exchange algorithm that does not, inherently, provide authentication or confidentiality. DH is "safe" only when used within a protocol that uses DH and other algorithms with proper integration to achieve such sought after characteristics as data confidentiality and integrity.
Speaking of which, some (many) SSL/TLS implementations did things improperly, in that they gladly accepted to do DH with weak parameters, in particular a 512-bit modulus. The protocol itself is suboptimal in its handling of DH because the ServerKeyExchange message allows the server to send the DH parameters p and g to the client, but not q, leaving the client a bit in the dark. Thus, the client must either "play safe" and generate its key in the full 1..p-1 range, or try to use a shorter exponent (say, 256 bits, not 2048) for a reduced computational cost, but possibly at risk of weakness in case the subgroup order q is not prime. A better design would have allowed the server to send the value of q and the size of the biggest prime divisor of q. In that respect, the ECDHE cipher suites of SSL/TLS (DH translated to elliptic curves) have a better design.
For a practical answer if you are configuring your SSL/TLS server: you should use a modulus of at least 2048-bit, and a generator g such that the order of g is a prime q of at least 256 bits; alternatively, you may use a modulus p which is a "safe prime" (the order of g will then be either a very big prime, or twice a very big prime, which is almost as good). Some people feel safer when they generate their DH parameters "themselves"(*) instead of reusing existing values; if that's what it takes to allow you to sleep at night, then do it.
(*) People never generate their DH parameters themselves; they use a computer. But we are talking psychology here anyway.
First of all, don't panic, Diffie-Hellman's algorithm is totally fine if used right (with right set of parameters).
Let me explain some preliminaries:
It's the underlying protocol used in HTTPS that prevents eavesdropping and tampering of the data sent in the channel. It uses diffie-hellman protocol to exchange keys between client and server.
SSL/TLS protocol was made to be extensible, it is capable of using several algorithms for encrypting and signing the data, these interchangable packages are called cipher suites, you can have TLS_RSA_WITH_RC4_128_MD5 as your cipher suite which uses RSA for key exchange, RC4 for bulk data encryption and MD5 for signature.
Whats LogJam?
Now there are some of these cipher suites called EXPORT-GRADE (e.g TLS_RSA_EXPORT_WITH_RC4_40_MD5), they are intentionally weak due to US export regulations on cryptographic algorithms. These cipher suites have short key length and can easily be broken, if someone doesn't disable them on their server and the client uses them, the shared keys can be leaked and the encryption can be broken by an attacker. There was an attack on RSA named FREAK and one on Diffie-Hellman named LogJam.
Now if the client can be forced to use EXPORT-GRADE cipher suites and if the server happens to support them, an attacker can do a MITM attack by breaking the diffie-hellman algorithm due to the use of short key length. This is what LogJam is about.
There was also another vulnerability where some web servers used default diffie-hellman parameters of length 1024 which is also broken.
Note: it's all about parameters used in the algorithms, there's nothing wrong with Diffie-Hellman algorithm itself.
What to do now?
If you use modern browsers and keep them updated, by now they already prevent this attack from happening.
If you are running a webserver make sure you're using the best practices for configuring your SSL/TLS enabled versions and the underlying cipher suites.
As for the minimum key size, 1024 bits are out of reach of normal attackers, but not nation state. 2048 bit is safe. You could also use ECDHE which is diffie-hellman over elliptic curve and basically yields you the same level of security with shorter key length.
