On a wiki page, archived by now, Mozilla switched from recommending self generated DH groups to the ones predefinded in RFC 7919.

The recommendation was accompanied by the statement

These groups are audited and may be more resistant to attacks than ones randomly generated.

Unfortunately, this – often cited – statement comes without any reasoning as to why these groups need an audit to be more resistant. A specification of how probable "may" is, is missing, too.

Can you explain why one should prefer RFC 7919 groups over self generated ones? What might be the reasoning behind this change? How likely is it that a self generated group is worse than one of the predefined ones? In particular, I am wondering because predefined keys are so much more likely to be precomputated by someone.

Edit: The parameters are assumed to be generated with (a recent version of) OpenSSL which is ubiquitous in publications about TLS setup: openssl dhparam 2048 which generates safe primes (p = 2 q + 1).

I am asking this question more for academic interest than for an actual real world application.

There is another question which gives some insight into the topic but it is focused on the question if 1024-bit parameters are enough while this question is about using self generated random DH groups or pregenerated ones.

  • $\begingroup$ Note that the predefined ones would also be more likely targets for specialized optimizations. It also seems easier to show resistance for these general groups against specialized attacks like SNFS and Pohlig-Hellman than to trust the somewhat dynamic parameter generation where a client has to trade latency for verification thoroughness. $\endgroup$
    – SEJPM
    Commented Jul 20, 2020 at 15:05
  • 3
    $\begingroup$ Does this answer your question? What Diffie-Hellman parameters should I use? $\endgroup$
    – kelalaka
    Commented Jul 20, 2020 at 17:33
  • $\begingroup$ My answer addresses the question "why dynamically generated DH groups doesn't make sense for Mozilla"; if you are in charge of the generation of DH groups (which Mozilla is not), their reasons would not apply to you. I'd still suggest EC groups, though... $\endgroup$
    – poncho
    Commented Jul 22, 2020 at 13:51
  • $\begingroup$ Ok, so it looks like a misunderstanding, indeed. The page is not about a Mozilla design decision but a recommendation to users how to set up their server for TLS. $\endgroup$
    – wedi
    Commented Jul 22, 2020 at 14:01
  • $\begingroup$ @kelalaka no it doesn't. I have updated the question to reflect that. $\endgroup$
    – wedi
    Commented Jul 22, 2020 at 14:04

1 Answer 1


Well, it's one less thing for the server to get wrong; I'll be giving my answer in the context of TLS 1.2 (as that was the context Mozilla assumed); remember, in TLS 1.2, it is the server that proposes the group, and Mozilla makes clients.

  • A "randomly generated group"; there are a number of ways of generating such a group, and they vary both in complexity, and (less obviously) the security. Depending on the algorithm, you could generate a random prime, a "DSA prime"[1], a "Lim-Lee prime" [2], or a safe prime [3]; I have arranged the types of primes in order of both increasing security and increasing cost to generate.

  • The group includes the generator - how is that selected? Ideally, we want to select a generator with a large prime suborder; does the server do that?

  • When you use the group, will you ever reuse the private exponent? If you do, well, DSA primes can be weak in that scenario.

So, depending on the algorithm the server uses, the group has variable security characteristics; worse yet, the TLS 1.2 protocol does not give the client enough information to vet the proposed group (it can determine whether the server proposed a safe-prime, but since TLS 1.2 doesn't mandate safe-primes, there's little it can do with that information); in particular, it cannot determine the order of the proposed generator.

Hence, if Mozilla supported server-generated groups, they'd be trusting that random servers did this rather subtle process correctly (without any way for them to verify it). In contrast, the 7919 groups are known to be correctly generated, so that's one less thing they need to depend on.

And, if you're worried about someone computing a factor base, I recommend you switch to ECC groups.

Also, I should list things which were likely not a part of the Mozilla decision:

  • The possibility that the server could accidentally select an SNFS-friendly group, that is, a group where the Special Number Field Sieve algorithm was applicable (which would allow computation of discrete logs considerably faster than the standard GNFS (aka NFS) algorithm can). However, the probability that a SNFS-friendly group is selected is sufficiently tiny that, in practice, we don't need to worry about it.

  • The possibility that a malicious server could generate an "easy to solve" group. However, there are lots of other ways a malicious server could foil security (for example, by selecting the private exponent in a guessable way, or just publishing the symmetric encryption keys); we need to assume that the server is honest (and so we need to protect only against accidental errors).

[1]: DSA prime is my terminology of a prime of the form $kq+1$, for $q$ a prime of perhaps 256 bits (and $k$ being an arbitrary even integer of the appropriate size). The point of this is that it generates a group with a subgroup of a known size, and are essentially as cheap to generate as a random prime.

[2]: A Lim-Lee prime is a prime of the form $2qr+1$, for $q, r$ both primes about the size of half of the full prime. The point of this is that it gives you most of the security advantages of safe primes, and are much cheaper to generate.

[3]: A safe prime is a prime of the form $2q+1$, for prime $q$. This is standard and common terminology (compared to the other two); since I did define the other two, I thought I'd define this as well.

  • $\begingroup$ Thank you for your elaborate answer! Unfortunately, I didn't mention it in my question: on the same page it was recommend to use openssl dhparam 2048 to generate the primes so it's save to assume that the result uses a safe prime. $\endgroup$
    – wedi
    Commented Jul 22, 2020 at 11:38
  • 2
    $\begingroup$ I'm wondering if something needs to be said about precomputation attacks that are at least feasible for smaller groups. Or domain separation possibly. There are also some advantages possible by using separate groups I presume. $\endgroup$
    – Maarten Bodewes
    Commented Jul 22, 2020 at 11:57
  • $\begingroup$ @wedi the result of openssl dhparam 2048 is most likely a safe prime, while with RFC7919 params we know they are safe primes (as we have primality certificates for them); also because the specific algorithm used to select them, we know that they are not vulnerable to SNFS, with dhparam you may get a prime susceptible to SNFS $\endgroup$ Commented Jan 18, 2021 at 15:44
  • $\begingroup$ does adding -check to the openssl command solve this issue? Or is currently the most secure way to just use RFC7919 instead of a random dhparam? $\endgroup$
    – K. Frank
    Commented Feb 12, 2021 at 17:32
  • $\begingroup$ @HubertKario I'm pretty sure dhparam checks both that $p$ is prime and that $(p - 1)/2$ is prime. Or are you referring to the fact that it uses a probabilistic test? Because $2^{-64}$ is enough for me. $\endgroup$
    – forest
    Commented Mar 8, 2021 at 2:00

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.