Key Exchange (Diffie-Hellman, ECDHE)

Key exchange is the process by which two parties establish a shared secret over an insecure channel, without an eavesdropper being able to determine that secret. Diffie-Hellman (DH), invented in 1976, was the first practical solution: both parties exchange public values derived from their private secrets, and each independently computes the same shared secret using their own private value and the other’s public value. ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is the modern variant used in TLS — it uses elliptic curve math for smaller, faster operations and generates fresh keys for every session (ephemeral) to provide forward secrecy.

Why it matters

• Solves the bootstrap problem — two parties who have never communicated can establish a shared encryption key without a pre-existing secure channel. This is what makes TLS possible between a browser and a server that have never met.
• Forward secrecy — ephemeral key exchange (ECDHE) generates new key pairs for every session. Even if the server’s long-term private key is later compromised, past sessions remain encrypted because the ephemeral keys were discarded.
• TLS 1.3 mandatory — TLS 1.3 requires ECDHE (or DHE) for every connection. RSA key transport (encrypting the session key with the server’s RSA public key) is removed because it has no forward secrecy.
• Performance — X25519 key exchange takes ~50 microseconds on modern hardware. The cost of forward secrecy is negligible — there’s no performance reason to avoid it.
• Quantum vulnerability — classical DH and ECDHE are vulnerable to quantum computers (Shor’s algorithm). Post-quantum key exchange (ML-KEM/Kyber) is being deployed alongside ECDHE in hybrid mode for future-proofing.

How it works

Classical Diffie-Hellman:

1. Agree on public parameters: large prime p and generator g
2. Alice: picks private a, computes A = g^a mod p (sends A to Bob)
3. Bob: picks private b, computes B = g^b mod p (sends B to Alice)
4. Alice computes: shared_secret = B^a mod p = g^(ab) mod p
5. Bob computes: shared_secret = A^b mod p = g^(ab) mod p
6. Both have the same shared secret. Eavesdropper sees g, p, A, B but can’t compute g^(ab) (discrete logarithm problem).

ECDHE (Elliptic Curve variant):

1. Agree on curve parameters (X25519 or P-256)
2. Alice: picks private a, computes A = a × G (point multiplication on curve)
3. Bob: picks private b, computes B = b × G
4. Alice computes: shared_secret = a × B = ab × G
5. Bob computes: shared_secret = b × A = ab × G
6. Same shared secret. ECDLP prevents computing ab × G from A and B alone.

Ephemeral (the “E” in ECDHE):

• New a and b are generated for EVERY session
• After deriving the shared secret, ephemeral private keys are discarded
• Even if recorded, the session can’t be decrypted later — the keys no longer exist

In real systems

TLS 1.3 key exchange (X25519):

ClientHello:
  supported_groups: [x25519, secp256r1]
  key_share: x25519 public value (32 bytes)

ServerHello:
  selected_group: x25519
  key_share: x25519 public value (32 bytes)

# Both sides compute shared secret from ECDHE
# Shared secret → HKDF → handshake keys → application keys

Nginx — configuring preferred curves:

ssl_ecdh_curve X25519:P-256:P-384;
# X25519 first (fastest, most secure)
# P-256 fallback (widest compatibility)
# P-384 for high-security requirements

OpenSSL — generating ECDHE key pair:

# Generate X25519 private key
openssl genpkey -algorithm X25519 -out x25519_priv.pem

# Extract public key
openssl pkey -in x25519_priv.pem -pubout -out x25519_pub.pem

# Derive shared secret (given peer's public key)
openssl pkeyutl -derive -inkey x25519_priv.pem -peerkey peer_pub.pem -out shared_secret.bin

Verifying forward secrecy is active:

# Check negotiated key exchange
openssl s_client -connect example.com:443 2>/dev/null | grep "Server Temp Key"
# Output: Server Temp Key: X25519, 253 bits
# "Temp Key" = ephemeral = forward secrecy active

# If output shows "Server public key is 2048 bit" with no Temp Key
# → RSA key transport, NO forward secrecy (TLS 1.2 only)

Where it breaks

Static DH (no forward secrecy) — if the server reuses the same DH key pair across sessions (static DH, not ephemeral), compromising that key decrypts all past and future sessions. This defeats the purpose of DH. TLS 1.3 mandates ephemeral keys — but TLS 1.2 configurations with static DH parameters still exist in legacy systems. Always use ECDHE, never static ECDH.

Weak DH parameters — classical DH with small primes (512-bit or 1024-bit) is breakable. The Logjam attack (2015) demonstrated that 512-bit DH could be broken in real-time, and nation-state attackers could likely break 1024-bit DH. If using classical DHE (not ECDHE), use at least 2048-bit parameters. Better: use ECDHE exclusively and avoid classical DH entirely.

Key exchange without authentication — DH/ECDHE alone doesn’t authenticate the parties. An attacker can perform a man-in-the-middle: establish separate DH exchanges with both Alice and Bob, relaying messages between them. This is why TLS combines ECDHE with certificate-based authentication — the server signs the key exchange with its private key (CertificateVerify), proving the key share came from the legitimate server, not an attacker.

Operational insight

Forward secrecy has a subtle operational implication: you cannot decrypt your own past TLS traffic for debugging or compliance. With RSA key transport (no forward secrecy), you could record traffic and later decrypt it using the server’s private key — useful for troubleshooting and lawful intercept. With ECDHE, the ephemeral keys are gone — recorded traffic is permanently encrypted. If you need to inspect TLS traffic (for debugging, IDS, or compliance), you must do it in real-time at the termination point (TLS inspection proxy), or use SSLKEYLOGFILE to export session keys during the connection. Plan your monitoring architecture around this constraint before deploying forward secrecy everywhere.

Related topics

• Elliptic Curve Cryptography
• What is a TLS Handshake
• What are Cipher Suites
• What is Asymmetric Encryption
• TLS 1.3 vs TLS 1.2