[openssl-users] A question DH parameter generation and usage

Jayalakshmi bhat bhat.jayalakshmi at gmail.com
Wed Dec 6 10:57:19 UTC 2017

Hi Jakob and Paul,

Thank you so much for the reply. We have the RSA certificates. I wanted to
understand how generally DH parameters are generated. Thanks for the
detailed answers.


On Wed, Dec 6, 2017 at 12:48 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> On 06/12/2017 07:02, Jayalakshmi bhat wrote:
>> Hi,
>> We are planning to use DHE_RSA TLS ciphers into our product. I have few
>> questions on using DH parameter. We would like to use DH-2048.
>> our product includes both TLS client and server applications. Thus any
>> time there will be considerable number of active connectioons.
>> I believe we can use same DH parameter for all the server connections. Is
>> my understanding correct? Is there any risk in using same parameter for all
>> the server connections.
>> Another question is what is guidelines/document should be followed to
>> derive DH parameter.
>> Any input is appreciated.
>> In TLS and SSL 3 (current versions, not sure about GoogleTLS 1.3),
> DHE parameters are chosen exclusively by the server, so most rules
> will be about servers.
> Current best practice on clients is to reject parameters of less
> than 1000 bits, parameters with fewer bits than they pretend (e.g.
> parameters claiming to be 1024 bits, but the most significant 32
> bits are all 0, making them really less than 993 bits), parameters
> that are glaringly non-prime (e.g. even numbers) and parameters
> that cause the DHE calculation to result in an unreasonably number
> such as 1 (indicating rigged parameters).  I hope that OpenSSL
> client code already does such checks by default, otherwise someone
> should point out how to make it do so.
> Current best practice on servers is to use DHE parameters such as
> those generated by openssl dhparam, or the equivalent API function.
> Current best practice on general purpose servers is to use at least
> 2048 bit DH parameters except when talking to clients that can't do
> that, such as the TLS code in Oracle Java 6.  Going above 2048 bits
> is good, but some common clients don't work significantly above
> that number (for example, some versions of the Mozilla NSS code
> have a built in maximum of 2236 bits).
> Current best practice on servers is to use DHE parameters that are
> used by few other servers, at least in a given timespan.  Thus for
> servers that will be deployed in small numbers, just generate your
> own parameters at build time using
>    openssl dhparam -C xxxx > dhxxxx.inc
> then include dhxxxx.inc in your source code.  For servers that will
> be deployed in large numbers, load the dh parameters from files in
> the format generated by
>   openssl dhparam xxxx > dhxxxx.pem
> and include scripts or other code that will replace the file
> contents daily or weekly (overwriting the old parameters only after
> the new ones are ready).  The exim mail server does this if you
> follow the instructions.
> Enjoy
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171206/f9890e9b/attachment.html>

More information about the openssl-users mailing list