7

For a DHE cipher, nginx hard-codes the Diffie-Hellman parameters to use base 2 and a fixed 1024-bit prime (modulus) if no custom DH parameters are configured.

These parameters are public (sent in plaintext in the TLS ServerKeyExchange message), does changing the prime value somehow increase the security of the TLS connection? I am interested in the effect of having different prime numbers, not the number of bits.

Are there any other side-effects of changing the DH parameters, like compatibility issues with clients? (Apache speaks of issues resulting from using larger primes in Java 7 and earlier, but I cannot reproduce this in OpenJDK 1.7.0_40.)

  • 1
    May need an update in view of Logjam. – Deer Hunter May 25 '15 at 10:33
8

There is no known bad side-effect to sharing the same DH parameters with other people / servers. This is in fact the common case in elliptic-curve DH, because generating your own curve is substantially more difficult than generating your own prime modulus for classical DH, and usual implementation of elliptic curves are tied to a specific curve or a small set of curve (because this is easier and more efficient to write that way).

There has been some theoretical concern about how an attacker might invest a lot of work into "breaking" discrete logarithm modulo a specific prime and then reusing the intermediate calculations to quickly break many DH instances which work modulo that specific prime. In that sense, reusing common DH parameters might imply an extra power of nuisance for the attacker. But this kind of cost sharing does not work for all DL-breaking algorithms, and this also assumes that the attacker could break DL modulo the prime, i.e. that the prime was too short or "special form". This would be a much more pressing reason not to use that prime: not that it is shared, but that it is weak.

Thus, using existing, shared DH parameters is not a problem as long as you can make sure that the said parameters have not been specially "cooked" to allow for a fast(er) break. This usually means that the generating algorithm has been fully specified and can be verified to have been faithfully followed (e.g. see these ones).

Using custom DH parameters should work with all clients, because there is no implementation advantage to tying an implementation to a specific modulus (contrary to elliptic curves). As long as your modulus fits in the size requirements of a specific implementation, things ought to be fine (some older implementations have trouble with sizes beyond 1024 bits; other won't like a modulus whose size is not a multiple of 32 or 64 bits).

  • Is there a quick way to verify whether a generated modulus is weak or not? I guess not (this would be the advantage for the attacker)? – Lekensteyn Oct 4 '13 at 18:01
  • 1
    There is no known quick way. However, "special form" primes are extremely rare; you don't get them out of (bad) luck. This is why an open generation process is enough (with a good PRNG running from a publicly known seed). – Thomas Pornin Oct 4 '13 at 18:03
  • 2
    How does this piece of advice stand against Logjam? – Deer Hunter May 25 '15 at 10:33
  • 2
    If you use a weak modulus, then it is weak, and you get what you deserve. That's the essence of Logjam; the tricky part of Logjam is that they changed "weak" into "real-time weak". If you use a non-weak modulus, then sharing is not an issue. – Thomas Pornin May 25 '15 at 19:33
  • 1
    In an ideal world you would move away from 1024 bit DH completely but if you are forced to use 1024 bit DH your risk (for now) is much lower with custom parameters than well-known parameters. – Peter Green Oct 22 '15 at 16:07
5

1024-bit primes are within the computation range to be vulnerable to precomputation attacks from State-level actors.

https://weakdh.org/ describes the problem and also the logjam downgrade attack mentioned in comments on this question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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