A Diffie Hellman key exchange lets two machines agree a shared secret over a connection anyone can read, without ever sending the secret. Each side keeps a private number, derives a public value from it, and sends that.
Each then combines their own private number with the value they received, and both arrive at the same result. An observer sees both public values and cannot compute what they agreed.
- The secret is computed at both ends, never transmitted
- It agrees a key and does not authenticate anybody
- Ephemeral values give forward secrecy, and TLS 1.3 requires them
- Elliptic curve reaches the same security with far smaller keys
- Its security rests on the discrete logarithm problem staying hard
On this page
The intuitionThe idea, with paint
The standard explanation uses colors of paint, and it is standard because it works.
Two people want a shared color that a watcher cannot reproduce. They agree publicly on a starting color, yellow, and everyone including the watcher knows it. Each of them privately picks a secret color and mixes it with the yellow. They exchange the mixtures openly.
Each then adds their own secret color to the mixture they received. Both end up with yellow plus both secrets, which is the same color. The watcher has the yellow and both mixtures, and cannot get to that final color, because separating a mixture back into its components is far harder than mixing was.
That asymmetry, easy in one direction and hard in reverse, is the whole of it. The mathematics replaces paint with modular exponentiation, where raising a number to a power modulo a large prime is fast, and working out which power was used is not.
Worked exampleThe same thing with numbers
Cryptography papers name the two parties Alice and Bob, and the arithmetic is small enough to follow by hand if the numbers are small. Real deployments use numbers hundreds of digits long, and nothing else changes.
Alice and Bob agree publicly on a prime modulus and a generator. Say the prime is 23 and the generator is 5. Both numbers are public and the eavesdropper has them.
public: prime p = 23, generator g = 5
Alice picks a = 6, in secret Bob picks b = 15, in secret
A = 5^6 mod 23 = 8 B = 5^15 mod 23 = 19
Alice sends 8 to Bob ------->
<------- Bob sends 19 to Alice
Alice: 19^6 mod 23 = 2 Bob: 8^15 mod 23 = 2Both arrive at 2, and neither ever sent it. The eavesdropper saw the prime, the generator, the 8 and the 19, and to get to 2 would have to work out that 8 came from an exponent of 6, or that 19 came from 15.
With a prime of 23 that is trivial by trying every value. With a prime of 2048 bits there is no known method that finishes in any useful amount of time, and that gap is the whole security of the algorithm.
The problem an attacker faces has a name, the discrete logarithm problem, and the security of the exchange rests entirely on it staying hard. Nobody has proved that it is hard. Forty years of cryptography research has failed to make it easy, which is the strongest statement anybody can make about a problem of this kind.
The exchangeWhat actually happens on the wire
A Diffie Hellman key exchange is four steps and only two messages.
Agree the parameters. Both sides need the same prime modulus and generator, which cryptography standards publish as named groups. These are public, and either sent in the handshake or named by reference.
Each side generates a private value at random and keeps it. This never leaves the machine.
Each computes a public value from the private one and the shared parameters, and sends it. This is the message the watcher sees.
Each computes the shared secret by combining their own private value with the other side's public value, modulo the agreed prime. Both computations produce the same number.
That number is not used directly as an encryption key. It goes through a key derivation function, which stretches and separates it into the several keys a connection actually needs: one for each direction of data, and separate keys for encryption and integrity.
A Diffie Hellman key exchange costs two messages and a few milliseconds of arithmetic, and one happens at the start of every HTTPS connection, every SSH session and every VPN tunnel you open.
AuthenticationThe gap it leaves, and how it is filled
Diffie-Hellman agrees a key with whoever is at the other end. It says nothing about who that is.
That is a real security vulnerability, not a theoretical one. An attacker positioned in the middle runs a separate key exchange with each side: one with the client while pretending to be the server, another with the server while pretending to be the client.
Both ends believe they have a secure connection. The attacker holds both keys, decrypts everything, and re-encrypts it onward. Nothing about the exchange itself detects this.
Every real protocol closes the gap with authentication layered on top.
TLS signs the exchange with a certificate. The server signs its Diffie-Hellman public value with the private key belonging to its certificate, and the client checks that signature against a certificate chain it trusts. An attacker cannot produce that signature without the server's private key.
SSH pins the host key. The first connection records the server's key, and every later connection checks it before the exchange is trusted. That is what the warning about a changed host key is protecting, and dismissing it is dismissing exactly this security control.
IPsec authenticates with a certificate or a pre shared key before or during the exchange, depending on the mode.
The rule worth carrying: Diffie-Hellman without authentication is secure against passive eavesdropping and completely open to an active attacker in the path. It is half of a solution, and the other half is always a certificate or a key you already trusted.
Forward secrecyEphemeral, and why forward secrecy matters
The distinction between static and ephemeral is the most consequential thing on this page.
Static Diffie Hellman reuses the same private values across many connections. It works, and it means anyone who eventually obtains those values can compute the shared secret for every session they recorded, including data captured years ago.
Ephemeral Diffie-Hellman generates fresh private values for every connection and discards them afterward. There is nothing left to steal. Traffic recorded today cannot be decrypted by compromising the server tomorrow, because the key that protected it no longer exists anywhere.
That property is forward secrecy, and it is the reason ephemeral exchange became mandatory rather than recommended. TLS 1.3 removed the non ephemeral options entirely: every TLS 1.3 connection has forward secrecy and there is no configuration that turns it off.
The practical instruction on any server you run: prefer the cipher suites with DHE or ECDHE in the name, and disable static RSA key exchange, which has no forward secrecy at all. On TLS 1.3 this is already done for you.
Elliptic curveElliptic curve, which is what actually runs
Classic Diffie Hellman over a prime modulus needs large numbers to be secure. 2048 bits is the current minimum and 3072 is the safer choice, and the modular arithmetic at that size is expensive enough to matter on a busy server.
Elliptic curve Diffie Hellman does the same thing over the mathematics of a curve rather than a prime field and a mod operation, and it reaches equivalent security with far smaller numbers. A 256 bit curve key is roughly comparable to a 3072 bit classic key, and the computation is faster.
The result is that ECDHE is what nearly every current connection uses. Curve25519, designed with implementation safety in mind, has become the common choice and is what OpenSSH and WireGuard use by default.
Classic Diffie-Hellman is not broken, and it survives in older configurations and in some VPN deployments. If you are choosing today, choose the curve.
| Classic Diffie-Hellman | Elliptic curve | |
|---|---|---|
| Key size for good security | 3072 bit | 256 bit |
| Computation cost | Higher | Lower |
| Used by new deployments | Rarely | Nearly always |
| Named in cipher suites as | DHE | ECDHE |
| Common in | Older VPNs | TLS, SSH, WireGuard |
PitfallsWhere it goes wrong
Small or shared parameters. The Logjam research showed that a small number of 1024 bit primes were shared by a very large share of servers, and that precomputation against one group makes every server using it cheaper to attack. Use 2048 bit at absolute minimum, prefer a curve, and generate your own parameters rather than reusing a well known group.
Static exchange, or no forward secrecy at all. A server still offering static RSA key exchange is a server where every recorded session can be decrypted later with one stolen key. Turn it off.
Trusting the exchange without checking identity. Accepting a certificate warning, or clicking through a changed SSH host key, removes the authentication that stops an active attacker. The exchange itself will complete happily either way.
Reusing an ephemeral value. The point of ephemeral is one use. An implementation that caches the private value for performance has quietly turned ephemeral back into static, and it has happened in shipped software more than once.
Assuming the algorithm encrypts anything. Diffie Hellman agrees a key. The encryption of the data is done by a separate cipher using that key. They are different steps, and confusing them makes the rest of a security configuration harder to reason about.
Ignoring the quantum question, or panicking about it. A sufficiently large quantum computer would break the discrete logarithm problem this rests on, and none exists.
What matters now is that recorded data could be decrypted later, so protocols are adding post quantum key agreement alongside the classical exchange. TLS and SSH have already started, and this is a migration in progress rather than an emergency.
ComparisonEphemeral key exchange, static RSA and a pre shared key, on what each protects
| Criterion | Ephemeral Diffie-Hellman | Static RSA key exchange | A pre shared key |
|---|---|---|---|
| Forward secrecy | Yes | No | No |
| Works between strangers | Yes | Yes | No |
| Needs prior contact | No | No | Yes |
| Survives the server key being stolen | Yes | No | No |
| Authenticates the other side | No | Partly | Yes |
| Allowed in TLS 1.3 | Yes | No | Yes, for resumption |
| Right for a public web server | Yes | No | No |
| Right for two devices you control | Yes | No | Workable |
The first and fourth rows are why the middle column is gone from modern TLS. Everything static RSA did, ephemeral exchange does, and it also protects the traffic already recorded.
FAQFrequently asked questions
What is the Diffie Hellman key exchange in simple terms?
A way for two machines, conventionally Alice and Bob, to agree on a secret over a connection anyone can read, without either of them ever sending the secret.
Is the shared secret ever transmitted?
No. Each side computes it locally from its own private value and the other side's public value. Only the public values cross the wire.
Does Diffie Hellman encrypt data?
No. The algorithm agrees a key. A separate cipher then uses that key to encrypt the data, and a key derivation function usually sits between the two.
Is it vulnerable to a man in the middle attack?
On its own, yes, completely. That is why every real protocol authenticates the exchange with a certificate or a previously trusted key.
What is perfect forward secrecy?
The property that recorded traffic cannot be decrypted later even if the server's long term key is stolen. Ephemeral Diffie-Hellman provides it because the keys are discarded.
What is the difference between DH and DHE?
The E is ephemeral. DHE generates fresh values per connection and gives forward secrecy. Plain DH reuses them and does not.
What is ECDHE?
Elliptic curve Diffie-Hellman, ephemeral. The same exchange over elliptic curve mathematics, which reaches the same security with much smaller keys and less computation.
How big should the key be?
2048 bit as an absolute minimum for classic Diffie-Hellman, 3072 preferred. On a curve, 256 bits, which is what Curve25519 uses.
What was Logjam?
Research showing that many servers shared a small set of 1024 bit primes, and that attacking one prime once made every server using it cheaper to break. It is why generating your own parameters, or using a curve, matters.
Is Diffie Hellman still secure?
Yes, at current key sizes and with ephemeral values. The known weaknesses are all about small groups, parameter reuse, or missing authentication rather than the algorithm itself.
Will quantum computing break it?
A large enough quantum computer would, and none exists. Recorded traffic is the real concern, which is why post quantum key agreement is being added alongside the classical exchange rather than after a break.
Where does it actually run?
At the start of every HTTPS connection, every SSH session, every IPsec tunnel and every WireGuard handshake. It is one of the most executed algorithms on the internet.
Keep readingRelated concepts
Read next · Remote access What Is an IPsec VPN? The IKE phase of an IPsec tunnel is a Diffie-Hellman exchange with authentication wrapped around it. Open this next11 min- Identity and access · 16 min What Is MFA? Key exchange secures the channel. Authentication decides whether the person on it is who they claim.
- Remote access · 14 min WireGuard Explained WireGuard uses an elliptic curve exchange on Curve25519, with no negotiation at all.
- Cryptography · 11 min Encryption Algorithms, and the Two Families They Fall Into Which algorithms do the work once the key is agreed, and why the honest answer to what a system uses names two of them.
- Cryptography · 11 min Hash Functions, and Why the Right One Depends on the Job The other piece of cryptography an administrator meets weekly, where the mistake that matters is not choosing a weak algorithm.
- Ports · 10 min Port 80 and 443, and Why You Still Cannot Close 80 The same protocol on 80 and 443, and what the handshake in front of one of them changes.