In SSL/TLS, the Client and the Server have the option to use an Ephemeral Diffie-Hellman exchange to establish a shared secret for which to seed the ensuing Master Secret and Session keys.

In the case of DHE being selected as the Key Exchange between two parties, how do they determine the DH ModP Group size (so that they can then agree upon a P and G number)?

3 Answers 3


When configuring a server for DHE you must generate Diffie Hellman parameters. You then configure OpenSSL/Apache/Nginx etc to use the DH parameters that you've generated.

The DH parameters to use are sent in the ServerKeyExchange message. After the ServerHello and Certificate messages, but before ServerHelloDone.

The ServerKeyExchange message contains the following:

   struct {
       select (KeyExchangeAlgorithm) {
           case diffie_hellman:
               ServerDHParams params;
               Signature signed_params;
           case rsa:
               ServerRSAParams params;
               Signature signed_params;
   } ServerKeyExchange;

Source: RFC2246 Section 7.4.3

  • It looks like this case statement would fall through. I assume that's not intentional?
    – forest
    Commented Dec 9, 2017 at 10:14
  • I don't think it is, but I just copied it straight from the RFC. I think their code examples are just pseudocode, and not expected to be used in production.
    – RoraΖ
    Commented Dec 9, 2017 at 16:18
  • @forest: it's not C and not even pseudocode because it cannot be executed even abstractly; instead it is part of the 'presentation' language' Commented Oct 12, 2023 at 3:35

With DHE cipher suites, the modulus size for DH is entirely chosen by the server, with no input from the client about acceptable sizes (this is indeed a defect in the TLS protocol with regards to DHE cipher suites).

Some historical clients (including the one shipped with Java up to and including Java 7) did not support DH modulus beyond 1024 bits. Thus induced some server implementations to stick to 1024-bit DH modulus. However, some others decided at some point that such sizes are too low. Apache+OpenSSL made that particular jump a few years ago; see this for details.

With ECDHE (the elliptic curve version), the elliptic curve to be used is still chosen by the server, but there is a ClientHello extension that allows the client to specify which curves it supports, thus allowing the server to make a truly informed decision.

  • Interesting. A follow on question: doesn't the client need to know the chosen group size before providing its public value in the Client Key Exchange record?
    – Eddie
    Commented Nov 3, 2015 at 20:42
  • 2
    The server sends the modulus, generator, and its public DH value in the ServerKeyExchange. The client then learns all of these; the client will send its public DH value in the ClientKeyExchange, which occurs later on in the handshake. (Note that the client must know the complete modulus, not just its size. In DH, all computations must be done modulo the same prime p.)
    – Tom Leek
    Commented Nov 3, 2015 at 20:45
  • Update: since RFC7919 in 2016 the former 'supported curves' extension is changed to 'supported groups' and client can suggest one or more standardized Oakley-like FFDH groups, but it's still up to server to choose. And since 2018 TLS1.3 (RFC8446) changes the protocol: now client MUST select standard groups and/or curves in ClientHello and MAY propose a 'share' (client-side public key) for one or more; server either agrees to such a proposal or sends RetryRequest to tell client which (one) group or curve to use (or aborts if no group or curve is mutually acceptable). Commented Oct 12, 2023 at 3:34

The server chooses the group and tells the client. The client provides no input to this process.

Most servers will ship with a default set of parameters (prime and generator) but it is reccomended to generate your own for two reasons.

  1. Some servers ship with a default prime that is only 1024 bit. This is now considerered too small.
  2. Much of the work in cracking dh is per-prime, not per session. So it is good practice to avoid using the same prime everyone else does.

Unfortunately Java 7 and older will fail the handshake if a server uses a prime larger than 1024 bits.

For Java 6 there is no good soloution to this. If you need to support Java 6 clients you have to pick your poison between no forward secrecy for clients that don't support ECDHE or weak 1024 bit DSA parameters.

For Java 7 you can avoid this problem by giving the ECDHE ciphersuites higher priority than the DHE ciphersuites.

You must log in to answer this question.

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