Re: A question DH parameter generation and usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux