Ephemeral Diffie-Hellman and What Forward Secrecy Actually Buys

The original Diffie-Hellman paper described an exchange in which both parties contribute an exponent and neither transmits it. The shared value is $g^{ab} \bmod p$, computed by each side from the other’s public value and its own secret. As a mechanism for agreeing on a key it works, and it works without any prior shared secret. What it does not do, on its own, is authenticate anything — and the way implementations use it, with fresh exponents per session, has a consequence for stored traffic that is worth understanding precisely.

The exchange, and the two ways to run it

Static Diffie-Hellman fixes the exponents. Alice’s private value $a$ is part of her long-term key material, and her public value $g^a$ is published or certified. Bob does the same. Every session between them derives the same shared secret, because the secret is a function of the two long-term keys only.

Ephemeral Diffie-Hellman generates $a$ and $b$ fresh for each session and discards them when the session ends. The public values are transmitted in the handshake, used once, and forgotten.

The difference is not in the arithmetic; it is in what happens to recorded traffic later. Under static DH, an attacker who records a session and later obtains Alice’s private exponent can recompute the shared secret and decrypt everything. The long-term key is the single point that unlocks all history. Under ephemeral DH, the exponents used for a given session exist only in the memory of the two endpoints during that session. Compromising the long-term signing key later does not help, because the exponents that produced the session keys are gone.

That property is forward secrecy, sometimes called perfect forward secrecy. The “perfect” qualifier is historical; the guarantee is simply that a future compromise does not retroactively decrypt past sessions, provided the ephemeral secrets were actually erased and were not themselves captured.

Authenticating an unauthenticated exchange

Diffie-Hellman alone is vulnerable to a straightforward man-in-the-middle. An attacker who sits between the parties runs two independent exchanges, one with each side, and relays the resulting traffic. Both sides believe they share a key with each other; in fact each shares one with the attacker, who decrypts, reads, re-encrypts, and forwards.

The fix is to bind the exchange to identities. In the common design, each endpoint signs the transcript of the handshake — the ephemeral public values and the negotiated parameters — with its long-term signing key, and the peer verifies the signature against a certificate. The signature covers the ephemeral values, so an attacker who substitutes its own cannot produce a signature that matches. This is the structure TLS 1.3 uses: an ephemeral key agreement, then a signature over the handshake hash, with the certificate chain providing the binding from the signing key to a name.

The ordering matters. The signature must cover the entire parameter set that the key depends on, including the group, the peer’s ephemeral value, and any downgrade-relevant negotiation. Signing only the peer’s public value leaves the group choice unauthenticated, which allows an attacker to force a weaker group. TLS 1.3 ties the group to the key share rather than negotiating it as a free-floating parameter: the client sends key shares for the groups it expects, and a server that wants a different group must send a HelloRetryRequest, which is covered by the transcript hash and therefore by the signature. A silent substitution of the group is not available.

From shared secret to keys

The raw output of the exchange is not usable as a key. For finite-field Diffie-Hellman the shared value is an element of a prime field, so its byte representation is a number in $[0, p-1]$ with a distribution that is far from uniform and biased in the high bytes when $p$ is not a power of two. For elliptic curve Diffie-Hellman the shared value is an x-coordinate, which is uniform over the field but still not a key: it is a group element, and using it directly as an AES key would expose it to related-key and structural issues.

Both cases are handled by a key derivation function. The standard approach hashes the shared value together with context: the identities of both parties, the transcript, and a protocol label. X25519 as specified in RFC 7748 is defined to output the shared secret for use with a KDF; the raw 32 bytes are explicitly not a key. HKDF, specified in RFC 5869, is the common choice: extract the shared value with a salt into a pseudorandom key, then expand into as many output keys as the protocol needs.

Binding the context into the derivation is what prevents key-reuse attacks across sessions. If two sessions happen to produce the same shared value — possible only under a repeated ephemeral key — the derived keys still differ because the transcripts differ. Without the binding, a repeated key would produce repeated session keys, and the attacker who caused or observed the repetition could decrypt both.

shared  = X25519(my_ephemeral_private, peer_ephemeral_public)
prk     = HKDF-Extract(salt=handshake_hash, ikm=shared)
key     = HKDF-Expand(prk, info="session key", length=32)

The exact labels and the number of derived keys are protocol-specific. The invariant is that no protocol uses the raw group element as a key.

What the extra exponentiations cost

Ephemeral DH adds work relative to static DH, and the cost depends on the group.

For finite-field groups, each side performs one full-size exponentiation per handshake, on the order of three thousand modular multiplications for a 2048-bit group, using the analysis in Modular Exponentiation and the Cost of One Key Operation. That is the same cost as an RSA private operation, and it is paid on every connection rather than amortised over a long-lived key. A server handling many short connections pays it repeatedly, which is why connection reuse matters for CPU budget.

For elliptic curve groups the numbers are much smaller. X25519 uses a 255-bit field, so a scalar multiplication involves 255 ladder steps over 4-limb numbers rather than 2048-bit numbers. The practical effect is that an ephemeral X25519 exchange costs a small fraction of a 2048-bit finite-field exponentiation, which is the main reason the modern default is an elliptic curve group rather than a MODP group. The arithmetic behind that gap is covered in Elliptic Curve Point Arithmetic and Validation.

There is a second, less obvious cost: the server must keep the ephemeral private value until the handshake completes, and must erase it after. Holding it in memory for the duration of the handshake is unavoidable; retaining it in a session cache defeats the purpose, because a compromise of the cache recovers exactly the secrets that forward secrecy was supposed to eliminate. Implementations that resume sessions by storing the master secret rather than a ticket-encrypted copy give up forward secrecy for the resumed session. TLS 1.3’s resumption design encrypts the ticket state under a key held by the server, so the ticket is a bearer token rather than a stored secret.

Replay, and why freshness is not optional

An exchange with fresh exponents also resists replay of a recorded handshake, because the peer’s contribution is new each time and the derived key differs. A protocol that accepts a replayed key exchange message would let an attacker force a session key it already knows, so the freshness of the ephemeral value must be checked: the peer’s public value must not be a repeat of a previously seen value for that peer.

The check is cheap — a comparison against recent values — but it is not universal. Protocols that omit it rely on the signature over the transcript, which does not prevent replay of an entire signed handshake if the signature has no freshness component. The usual fix is a nonce in the signed data, which the protocol supplies and the peer echoes.

Where ephemeral key agreement is the wrong tool

Ephemeral DH requires the peers to be online simultaneously; it is an interactive protocol. A sender who wants to encrypt a message to a recipient who is offline cannot run it. This is the case RSA encryption handles, and it is also the case a KEM handles: the sender encapsulates to the recipient’s public key without interaction. The trade-off between the two is the subject of Hybrid Encryption and the Cost of Encrypting Long Messages.

The other limitation is that ephemeral DH gives no non-repudiation. A signature proves that the holder of a key approved a message; a key agreement proves only that two parties agreed on a value, and either party could have produced the transcript. Where a recipient must be able to convince a third party that a specific party sent something, a signature is required and a key exchange is not a substitute.