This is the final post in a series on what public-private keys actually do. The overview names the three primitives. We have covered encryption and signing. This one is the primitive almost nobody can name, even though it runs at the start of every HTTPS connection you have ever made: key exchange.
Why this is the one you are missing
Ask a room of engineers what public-private keys do and you will hear "encrypt" and "sign". Both correct. But there is a third operation that is conceptually distinct, and it is invisible precisely because it hides inside other tools. You never call it directly; TLS calls it for you, Signal calls it for you, your VPN calls it for you. So it never enters your mental model, and TLS stays a black box.
Once you see it, a question that should have been bugging you finally gets an answer: symmetric encryption needs both sides to share a secret key, but how do two strangers agree on a shared key over a network an attacker is watching? You cannot just send the key; the attacker would read it. Key exchange is the answer.
The job
Key exchange answers exactly one question:
How do two parties who have never met, communicating over a wire an attacker can fully observe, end up holding the same secret that the attacker cannot derive?
Notice it is neither encryption nor signing. Nobody is hiding a message or proving identity. They are jointly computing a shared number. That number then becomes a fast symmetric key for the actual conversation.
The paint analogy (this is the whole idea)
The classic way to feel why this works is mixing paint. Mixing paint is easy; un-mixing it to recover the original colours is practically impossible. That one-way-ness is the magic.
Diffie-Hellman as paint mixing: a shared public colour, two secret colours, one shared result
- Both sides agree, in public, on a common base colour (say yellow). The attacker sees it.
- Each side picks a secret colour and keeps it private. Alice picks red, Bob picks blue. Neither is sent.
- Each mixes their secret into the public base and sends the mixture. Alice sends yellow+red (orange); Bob sends yellow+blue (green). The attacker sees both mixtures.
- Each side now mixes their own secret into the colour they received. Alice mixes red into Bob's green; Bob mixes blue into Alice's orange. Both arrive at the same final colour: yellow+red+blue.
The attacker has yellow, orange, and green, but to reach the final shared colour they would need to un-mix one of those to recover a secret colour, and un-mixing is the hard part. So Alice and Bob share a secret the attacker cannot reconstruct, having sent nothing secret across the wire.
In real Diffie-Hellman, "colour" is a number and "mixing" is modular exponentiation (or elliptic-curve point multiplication). The one-way-ness is the discrete-log problem: easy to mix forward, infeasible to reverse.
One honest limit: this defeats an eavesdropper, someone who only watches the wire. It does not, on its own, stop an active man-in-the-middle who sits between Alice and Bob and runs a separate exchange with each, impersonating the other to both. Plain Diffie-Hellman gives you a shared secret with somebody; it does not prove who. That is why real protocols bolt authentication on top: TLS and SSH sign the exchange (with a certificate or a host key) so each side knows it agreed the secret with the right party and not an impostor. Key exchange handles secrecy; signing handles identity. You need both.
public: base g, modulus p (everyone sees these) Alice: secret a -> sends A = g^a mod p Bob: secret b -> sends B = g^b mod p shared: Alice computes B^a = g^(ba) mod p Bob computes A^b = g^(ab) mod p same number. never transmitted. attacker has g, A, B only.
Where this hides in your stack
Every TLS handshake (so every HTTPS request, API call, and git push over HTTPS) starts with a key exchange, today almost always the elliptic-curve variant, ECDHE:
A TLS handshake uses key exchange for the session key and a signature for server identity
- Key exchange (ECDHE) to derive a fresh shared symmetric key for this connection.
- A signature for identity, and it is actually two signatures working together. The server's certificate is signed by a CA, which binds its identity to its public key; and the server then signs the handshake transcript with that certificate's private key (TLS 1.3's CertificateVerify), proving it really holds the key rather than just replaying someone else's cert. That live signature is what actually stops the man-in-the-middle.
- Symmetric encryption (AES) using that shared key for the actual bytes, because symmetric is fast.
There it is: all three primitives in one handshake. Key exchange to agree a secret, signing to prove identity, symmetric to move data. The same combination powers end-to-end messengers like Signal.
Forward secrecy, the payoff you get for free
Here is why modern TLS bothers to do a fresh key exchange per connection (the "E" in ECDHE stands for ephemeral): the secret colours are thrown away after the handshake. That gives forward secrecy.
Imagine an attacker records all your encrypted traffic today and steals the server's private key a year later. With forward secrecy, that stolen key does not unlock the recorded sessions, because the session keys were never derived from the long-term private key. They came from ephemeral key-exchange secrets that no longer exist. Each conversation is sealed in its own moment.
This is also the cleanest way to see that key exchange is a different primitive from the cert's signing key. The certificate's job is only to prove identity. The session secret comes from the ephemeral exchange, which is why losing the long-term key later cannot retroactively decrypt the past.
The takeaway
Key exchange lets two strangers compute a shared secret over a fully-observed wire, by exploiting an operation that is easy forward and infeasible to reverse. They send only "mixed" public values; the shared result is never transmitted. TLS uses it to bootstrap a fast symmetric key (then signs to prove identity, then encrypts the data), and doing it ephemerally buys forward secrecy.
That completes the set. The three things public-private keys actually do:
- Encryption: public locks, private unlocks (secrecy).
- Signing: private signs, public verifies (authenticity).
- Key exchange: agree on a shared secret in the open.
Everything else (TLS, SSH, JWT, passkeys, Signal, your VPN) is these three, composed. Back to the overview.