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. Commented May 25, 2015 at 10:33

2 Answers 2


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
    Commented Oct 4, 2013 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). Commented Oct 4, 2013 at 18:03
  • 2
    How does this piece of advice stand against Logjam? Commented May 25, 2015 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. Commented May 25, 2015 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. Commented Oct 22, 2015 at 16:07

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .