Diffie-Hellman Ephemeral


Diffie-Hellman Ephemeral (DHE) is a modification of the Diffie-Hellman key-exchange that used static keys.

A cryptographic key is called ephemeral if it is generated for each execution of a Key-Exchange process.

In some cases ephemeral keys are used more than once, within a single session (e.g., in broadcast applications) where the sender generates only one ephemeral key pair per message and the private key is combined separately with each recipient's Public Key.

Diffie-Hellman Ephemeral is a modification of the Diffie-Hellman key-exchange that used static keys.

Diffie-Hellman Ephemeral is defined within RFC 5246.

Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)#

Traditional TLS 1.2 RFC 5246 offers a Diffie-Hellman Ephemeral (DHE) key-Exchange mode that provides forward secrecy for the connection. The client offers a cipher suite in the ClientHello that includes DHE, and the server offers the client group parameters generator g and modulus p.

If the client does not consider the group strong enough (e.g., p is too small, p is not prime, or there are small subgroups that cannot be easily avoided) or if it is unable to process the group for other reasons, the client has no recourse but to terminate the connection.

Conversely, when a TLS server receives a suggestion for a DHE Cipher Suite from a client, it has no way of knowing what kinds of DH groups the client is capable of handling or what the client's security requirements are for this key exchange session.

For example, some widely distributed TLS clients are not capable of DH groups where p > 1024 bits. Other TLS clients may, by policy, wish to use DHE only if the server can offer a stronger group (and are willing to use a non-PFS (Perfect Forward Secrecy) key-Exchange mechanism otherwise). The server has no way of knowing which type of client is connecting but must select DH parameters with insufficient knowledge.

Additionally, the DH parameters selected by the server may have a known structure that renders them secure against a small subgroup attack, but a client receiving an arbitrary p and g has no efficient way to verify that the structure of a new group is reasonable for use. RFC 7919 modification to TLS solves these problems by using a section of the "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to select common DH groups with known structure and defining the use of the "elliptic_curves(10)" extension for clients advertising support for DHE with these groups. RFC 7919 also provides guidance for compatible peers to take advantage of the additional security, availability, and efficiency offered.

Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)#

TLS also supports Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) Key-Exchanges as described in RFC 4492

More Information#

There might be more information for this subject on one of the following: