Diffie-Hellman key exchange, explained simply

Diffie-Hellman key exchange lets two parties agree on a shared secret key over a network anyone can listen to, without ever sending the key. Each side combines its own private number with the other side's public value, and both arrive at the same secret, while an eavesdropper who saw every message cannot. A version of it, usually on elliptic curves and now often paired with a post-quantum algorithm, starts almost every HTTPS connection.

The problem: agreeing a key in public

Fast encryption such as AES is symmetric: both sides need the same secret key. That raises an awkward question. A student's phone and a course server have never met, and every packet between them crosses Wi-Fi routers, mobile networks and internet exchanges that neither controls. Send the key across that path and anyone watching has it too. Our guide to symmetric vs asymmetric encryption explains why this key-distribution problem held cryptography back for so long.

In 1976, Whitfield Diffie and Martin Hellman described a way out in their paper New Directions in Cryptography. Their insight was that two parties don't need to send a key at all. Each can compute the same key from a mix of public and private information.

The colour-mixing analogy

Imagine Asha and Ravi want to end up with the same secret colour, but anything they send each other can be seen by everyone.

1. They publicly agree on a base colour, say yellow.
   
   
2. Asha privately picks red. Ravi privately picks blue. Neither ever reveals their pick.
   
   
3. Each mixes their secret colour into the yellow and sends the mixture: Asha sends an orange mix, Ravi sends a green mix.
   
   
4. Asha adds her red to Ravi's green mix. Ravi adds his blue to Asha's orange mix. Both now hold yellow, red and blue in equal parts: the same final colour.
   
   

An eavesdropper sees the yellow, the orange mix and the green mix. To reach the final colour, she would have to separate a mixture back into its ingredients, which is easy to describe and hard to do. Diffie-Hellman replaces paint with arithmetic that has the same property: easy to combine, impractical to un-combine.

The maths with small numbers

Real Diffie-Hellman uses modular arithmetic. "mod 29" means "divide by 29 and keep the remainder", and 2^9 means 2 multiplied by itself nine times, which is 512. The numbers below are deliberately tiny so you can check them on a calculator; they are illustrative, not secure.

Both get 14 because each has computed 2 raised to the power 9 × 17, just in a different order. An eavesdropper, Eve, sees 29, 2, 19 and 21. To get 14 she needs Asha's 9 or Ravi's 17, which means answering the question: 2 to what power, mod 29, gives 19? That is the discrete logarithm problem. With 29 she can simply try all 28 possibilities. With a well-chosen prime 2,048 bits long, a number of 617 digits, no known classical method can solve it in any useful time.

Modern systems mostly use elliptic-curve Diffie-Hellman (ECDH), where the numbers are replaced by points on a curve. It reaches the same security with far smaller values. X25519, defined in RFC 7748, uses 32-byte public values and targets roughly 128-bit security, a level NIST equates with a 3,072-bit finite-field group. Our explainer on elliptic curve cryptography covers why smaller keys are enough.

Is Diffie-Hellman symmetric or asymmetric?

Asymmetric. Each side has a private value and a public value derived from it, which makes Diffie-Hellman a public-key technique. Its output, though, is a shared symmetric secret. In TLS 1.3, that secret goes through a key-derivation function to produce the AES or ChaCha20 keys that actually encrypt the traffic.

Diffie-Hellman doesn't encrypt anything itself; it is a key agreement method. Older TLS setups instead used RSA key transport, where the browser chose a secret and encrypted it to the server's RSA key. TLS 1.3 dropped that option, for the reason in the next section.

Ephemeral keys and forward secrecy

If a server used the same Diffie-Hellman private value for years, anyone who stole it could decrypt every session they had recorded. The fix is to make the values ephemeral: generate a fresh private value for every connection and delete it as soon as the session keys exist. That is the "E" in DHE and ECDHE.

The result is forward secrecy. Stealing a server's certificate key later doesn't expose past traffic, because the secrets that protected it were never stored. TLS 1.3 requires this: its certificate-based handshakes use only ephemeral Diffie-Hellman, and implementations must support the P-256 curve and should support X25519. Our guide to how SSL/TLS works walks through where the key shares sit in the handshake, and cipher suites explained covers the TLS 1.2 settings.

Man-in-the-middle: why the exchange needs authentication

Diffie-Hellman stops eavesdroppers. On its own it does nothing about impostors. Go back to the example and put Mallory between Asha and Ravi, able to change messages as well as read them.

1. Mallory picks her own secret, m = 5, and computes 2^5 mod 29 = 3.
   
   
2. She intercepts Asha's 19 and Ravi's 21, and sends 3 to each of them instead.
   
   
3. Asha computes 3^9 mod 29 = 21 and believes she shares 21 with Ravi.
   
   
4. Ravi computes 3^17 mod 29 = 2 and believes he shares 2 with Asha.
   
   
5. Mallory computes both, 19^5 mod 29 = 21 and 21^5 mod 29 = 2, then decrypts, reads and re-encrypts everything passing through.
   
   

Neither side sees anything wrong. The defence is to authenticate the public values, so each side knows whose key share it received:

• In TLS, the server signs a summary of the handshake, including both key shares, with the private key behind its certificate. The browser checks that signature against a certificate chain it trusts. That is the job of PKI and certificate authorities.
  
  
• In messaging apps with end-to-end encryption, users can compare codes. WhatsApp shows a QR code and a 60-digit security number; Telegram's secret chats show an image generated from the key. If the codes match on both phones, no one is sitting in the middle.
  
  

Diffie-Hellman groups: choosing the parameters

A Diffie-Hellman group is the named set of public parameters both sides use: a prime and generator for finite-field Diffie-Hellman, or a specific elliptic curve. Using standard named groups avoids weak home-made parameters. You will meet them in TLS settings and, with numbers attached, in VPN configuration screens.

The VPN status column follows RFC 8247, which makes group 14 mandatory for IPsec's key exchange and marks groups 1, 2 and 5 as unsafe. Small groups are dangerous for a practical reason. In 2015, researchers behind the Logjam attack showed that servers still accepting 512-bit "export" groups could be downgraded and broken, and that because millions of servers shared the same few primes, one large precomputation against a prime could break many connections. They estimated a nation-state could do this for a 1,024-bit prime.

Post-quantum hybrid key exchange

A large enough quantum computer running Shor's algorithm would solve the discrete logarithm problem, for both finite fields and elliptic curves. No such machine exists yet, but traffic recorded today could be decrypted later, which is why the key exchange is the first thing being upgraded.

The replacement, ML-KEM, is a key encapsulation mechanism rather than a Diffie-Hellman variant. The client sends an encapsulation key, and the server uses it to wrap a fresh secret and sends back the result. It does the same job differently. Because ML-KEM is new, browsers run it alongside X25519 and combine both results, so the connection stays safe as long as either part holds. RFC 10024, published in August 2026, standardises this hybrid for TLS 1.3 as X25519MLKEM768. The cost is size: the client's key share grows from 32 bytes to 1,216. Current Chrome, Edge, Firefox and Safari use it by default. Our guide to post-quantum cryptography covers the wider migration.

Where you meet Diffie-Hellman

Every TLS 1.3 handshake with a certificate, SSH logins, IPsec VPNs, and messaging protocols such as Signal's, which WhatsApp builds on, all start with a Diffie-Hellman exchange. For a course platform, it means every login, payment and lesson request from a student's app travels inside a TLS connection whose session keys came from an ECDHE or hybrid exchange. That protects data on its way to the device. It does nothing about what happens once a video is on screen, which is why protecting paid lectures takes more than encryption.

Key takeaways

• Diffie-Hellman lets two parties compute the same secret from public and private values, without sending the secret.
  
  
• Its security rests on the discrete logarithm problem, in finite fields or on elliptic curves such as X25519.
  
  
• It is a public-key technique whose output becomes a symmetric key.
  
  
• Ephemeral keys give forward secrecy; TLS 1.3 requires them.
  
  
• Without authentication it is open to man-in-the-middle attacks, so TLS pairs it with certificates and signatures.
  
  
• Browsers now combine X25519 with post-quantum ML-KEM to protect today's traffic from tomorrow's quantum computers.
  
  

Frequently asked questions

What is Diffie Hellman used for?

It is used to agree on a shared secret key over an untrusted network. That key then encrypts the real data with a fast symmetric cipher such as AES. Diffie-Hellman runs inside TLS for HTTPS, in SSH logins, in IPsec VPNs and in messaging protocols such as Signal's. Modern systems use the ephemeral elliptic-curve version, ECDHE, increasingly combined with ML-KEM, and pair it with certificates or security-code checks to stop impostors.

What is Diffie Hellman group?

A group is the named set of public parameters both sides use: a large prime and generator for finite-field Diffie-Hellman, or a specific elliptic curve. VPNs number them, so IKE group 14 is a 2,048-bit prime group, group 19 is the P-256 curve and group 31 is Curve25519. TLS calls them named groups, such as x25519 and secp256r1. Avoid groups of 1,536 bits or fewer.

What is Diffie Hellman in cryptography?

In cryptography, Diffie-Hellman is a key agreement protocol published by Whitfield Diffie and Martin Hellman in 1976. Two parties each combine their own private value with the other's public value and reach the same secret, relying on the discrete logarithm problem being hard to reverse. It is an asymmetric technique that produces a symmetric key, and it remains the basis of key exchange in TLS, SSH and VPNs.