How Key Exchange Works — Sharing Secrets Over Insecure Channels

You want to communicate securely with a server you've never talked to before. You need a shared symmetric key for encryption. But you can't send the key in plaintext — anyone watching would copy it. You can't encrypt it — you don't have a shared key yet. This is the chicken-and-egg problem that key exchange solves.

Whitfield Diffie and Martin Hellman solved it in 1976: two parties can agree on a shared secret by exchanging only public values. An eavesdropper who sees everything that's exchanged still cannot compute the shared secret. This is Diffie-Hellman key exchange.

How Does Diffie-Hellman Work?

The protocol relies on the same principle as asymmetric encryption: operations that are easy forward and hard backward.

Both parties agree on a public elliptic curve (for ECDH) or a large prime and generator (for classical DH). Then:

1. Alice generates a private key a (a random number) and computes her public value A = a × G (where G is the generator point on the curve).
2. Bob generates a private key b and computes his public value B = b × G.
3. Alice sends A to Bob. Bob sends B to Alice. Both values are public — anyone can see them.
4. Alice computes shared = a × B = a × (b × G) = ab × G
5. Bob computes shared = b × A = b × (a × G) = ab × G

Both arrive at the same value: ab × G. An eavesdropper knows A, B, and G but cannot compute ab × G without knowing a or b. Finding a from A = a × G is the elliptic curve discrete logarithm problem — computationally infeasible.

The shared value is then fed through a key derivation function (KDF) to produce the actual symmetric encryption key.

What Is ECDHE?

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is what TLS 1.3 uses. Two critical properties make it the standard:

Elliptic Curve — uses elliptic curve math instead of classical modular arithmetic. Smaller keys (256 bits vs 2,048+ bits), faster computation, same security. Curve25519 (X25519) is the most common curve.

Ephemeral — both parties generate fresh key pairs for every connection. After the shared secret is derived, the ephemeral private keys are discarded. This provides forward secrecy.

What Is Forward Secrecy?

Forward secrecy means: if an attacker records all your encrypted traffic and later steals the server's long-term private key, they still cannot decrypt the past traffic.

Without forward secrecy (e.g., RSA key exchange in old TLS versions), the client encrypted the session key with the server's public key. If the server's private key is later compromised, the attacker decrypts the session key and all recorded traffic.

With ECDHE, each connection uses a fresh, random key pair. The ephemeral private keys are deleted after the connection. There's no long-term secret that can retroactively decrypt past sessions. Even if the server's certificate private key is compromised, past traffic remains secure.

TLS 1.3 mandates forward secrecy. Every connection uses ECDHE. There is no option to disable it.

How Does TLS Use Key Exchange?

The TLS 1.3 handshake combines authentication and key exchange in one round trip:

1. ClientHello — the client sends its ECDHE public value (along with supported parameters).
2. ServerHello — the server sends its ECDHE public value.
3. Both compute the shared secret from the exchanged values.
4. Key derivation — the shared secret is fed through HKDF (HMAC-based Key Derivation Function) to produce separate keys for: client-to-server encryption, server-to-client encryption, and authentication.
5. Server authenticates — the server proves its identity by signing the handshake transcript with its certificate's private key.

After one round trip, both parties have a shared symmetric key, the server is authenticated, and forward secrecy is established. All subsequent data is encrypted with AES-GCM or ChaCha20-Poly1305.

What About Static Key Exchange?

Before TLS 1.3, some modes used RSA key exchange: the client generated a random secret, encrypted it with the server's RSA public key (from its certificate), and sent it. The server decrypted it with its private key. Both had the shared secret.

This works but has no forward secrecy. If the server's RSA key is later compromised, every past session can be decrypted. This is the "harvest now, decrypt later" threat — nation-state actors record encrypted traffic and wait for the key to become available.

TLS 1.3 removed RSA key exchange entirely. Only ECDHE is supported.

What Is the Post-Quantum Threat?

Post-quantum cryptography is the looming challenge. If a large quantum computer is built, Shor's algorithm could break both RSA and elliptic curve math — making current key exchange insecure.

NIST selected ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism, formerly Kyber) as the first post-quantum key exchange standard in 2024. TLS implementations are beginning to support hybrid key exchange: ECDHE + ML-KEM together. If one is broken, the other still protects the connection.

Chrome and Cloudflare have already deployed hybrid key exchange experimentally. The transition will take years, but the direction is clear: future key exchange will combine classical and post-quantum algorithms.

Where Is Key Exchange Used?

TLS — every HTTPS connection, every database connection, every API call over TLS starts with ECDHE. Billions of key exchanges happen every second.

SSH — the SSH handshake uses Diffie-Hellman (or ECDH) to establish the session key. ssh-keygen -t ed25519 generates an Ed25519 key pair; the handshake uses X25519 for key exchange.

WireGuard — uses X25519 for key exchange. Each peer has a static key pair and generates ephemeral keys per handshake.

Signal Protocol — the double-ratchet algorithm uses Diffie-Hellman key exchanges at every message to provide forward secrecy at the individual message level, not just the session level.

Next Steps

This completes the cryptography learning path. You now understand the five primitives:

• How Hashing Works — one-way fingerprints
• How Symmetric Encryption Works — encrypt with a shared key
• How Asymmetric Encryption Works — encrypt with public/private keys
• How Digital Signatures Work — prove authorship and integrity
• How Key Exchange Works — agree on a shared key over an insecure channel

These primitives combine to build TLS (key exchange + symmetric encryption + signatures), certificates (hashing + signatures), password storage (hashing), and every other security system.