Elliptic-curve Diffie–Hellman

ECDHE is how your browser agrees on a secret key with almost every website it talks to. It keeps the idea behind classic Diffie–Hellman but swaps the arithmetic for points on a curve, which gives the same security with far smaller numbers.

Same idea, different maths

This lesson builds on Diffie–Hellman key exchange. There, Alice and Bob each mixed a private number into a public value using modular exponentiation, swapped the results, and mixed in their private number again. Both ended up with the same secret, and an eavesdropper who saw everything couldn't work backwards.

Elliptic-curve Diffie–Hellman (ECDH) follows exactly the same steps. Only the one-way operation changes. Instead of raising a number to a power, Alice and Bob multiply a point on a curve by their private number.

The final E in ECDHE stands for ephemeral: a fresh key pair for every connection. We'll come back to why that matters.

What an elliptic curve is

Despite the name, an elliptic curve has nothing to do with ellipses. It's the set of points that satisfy an equation of this shape:

y² = x³ + ax + b

Pick values for a and b and you get a smooth curve that's symmetric about the x-axis. What makes these curves useful is that you can add two points together and land on a third point that's also on the curve.

The rule is geometric. Draw a straight line through P and Q. It will cross the curve at exactly one more point. Flip that point over the x-axis, and the result is P + Q. To add a point to itself, you use the tangent line at that point instead.

Notice that the answer doesn't look like it has much to do with P and Q. Move P a little and P + Q can jump a long way. That unpredictability is the property cryptography relies on.

Multiplying a point by a number

Once you can add points, you can multiply a point by a whole number. k × G just means G added to itself k times: G + G + G and so on. This is the one-way operation at the heart of ECDH.

It's fast in one direction because you don't need k separate additions. You double repeatedly and add where the binary digits of k say to. Here's 13 × G, with 13 written in binary as 1101:

G               start
2G   = G + G     double
3G   = 2G + G    add     (bit 1)
6G   = 3G + 3G   double  (bit 0)
12G  = 6G + 6G   double
13G  = 12G + G   add     (bit 1)

Five steps instead of twelve. For a real 256-bit private key, this double-and-add method takes a few hundred steps instead of more additions than there are atoms in the universe.

Going backwards is the hard part. If someone gives you G and a point Q and asks “what k gives k × G = Q?”, there's no shortcut known. This is the elliptic-curve discrete logarithm problem. A common way to picture it is a billiard ball bouncing around a table: if you see where it started and where it stopped, you still can't tell how many bounces it took.

Curves over a finite field

Real cryptography doesn't use the smooth curve above. Decimal numbers need rounding, and a smooth curve has too much structure, because points that are close together behave similarly. Instead, every calculation is done with whole numbers modulo a prime p, the same wrap-around arithmetic as classic Diffie–Hellman.

The curve stops being a line and becomes a scatter of points that looks almost random. The addition rule still works; the formulas are the same, with division replaced by multiplying by a modular inverse:

slope  m  = (y₂ − y₁) / (x₂ − x₁)    mod p
       x₃ = m² − x₁ − x₂              mod p
       y₃ = m(x₁ − x₃) − y₁           mod p

The demo below uses a tiny curve, y² = x³ + 3x + 2 modulo 97. It has exactly 103 points, counting a special “point at infinity” that acts like zero. Real curves have about 2²⁵⁶ points.

The exchange, step by step

Alice and Bob agree publicly on the curve and a base point G. Each picks a private number, multiplies G by it, and sends the resulting point. Then each multiplies the point they received by their own private number. Because a × (b × G) and b × (a × G) are both just (a × b) × G, they land on the same point.

On this toy curve Eve finds the key instantly, because there are only 103 possibilities. On X25519, the curve most browsers use, there are about 2²⁵². The best known attack, Pollard's rho, still needs around 2¹²⁶ steps, far beyond any computer that exists.

Only the x-coordinate of the shared point is used. It's fed through a key derivation function to produce the actual encryption keys, so the raw point never touches your data.

Why the E matters

Nothing stops a server from keeping one ECDH key pair for years and reusing it with every visitor. That's called static ECDH, and it has a serious weakness. If an attacker records your encrypted traffic today and steals the server's private key next year, they can work out every past shared secret and decrypt everything they recorded.

Ephemeral ECDH generates a brand new key pair for every connection and deletes the private key as soon as the handshake finishes. There's nothing left to steal. Each session's secret existed only briefly, in memory, on two machines. This property is called forward secrecy.

Smaller keys, same strength

The reason elliptic curves replaced classic Diffie–Hellman is efficiency. The best attacks on the classic discrete logarithm problem get faster as numbers grow, so the keys have to grow quickly to keep up. The best attacks on elliptic curves are much weaker, so curve keys can stay small.

Comparable strengths from NIST SP 800-57. At the common 128-bit level, an X25519 public key is 32 bytes, while the equivalent classic Diffie–Hellman value is 384 bytes. Smaller keys mean less data on the wire and much faster calculations, which matters on phones and busy servers.

ECDHE in a TLS 1.3 handshake

When your browser opens an HTTPS connection, ECDHE happens in the very first messages. Two curves cover almost all traffic: X25519, designed by Daniel J. Bernstein over the prime 2²⁵⁵ − 19, and P-256, standardised by NIST.

1. Client hello with a key share Your browser generates a fresh key pair on its preferred curve and sends the public key straight away, guessing which curve the server will accept. This guess saves a whole round trip compared to TLS 1.2.
2. Server hello with its key share The server generates its own fresh key pair on the same curve and replies with its public key.
3. Both compute the shared secret Each side multiplies the other's public point by its own private key. The result goes through HKDF, a key derivation function, to produce the keys that encrypt the rest of the handshake. Even the server's certificate is sent encrypted.
4. The server proves who it is The server signs a summary of the whole handshake with its certificate's private key. That ties the key shares to the real server, so a man in the middle can't swap in their own.
5. Private keys are thrown away Once the session keys are derived, both ephemeral private keys are deleted. The connection is encrypted with keys that were never sent and can never be recreated.

Why this matters

• Same handshake, better maths. ECDH follows the Diffie–Hellman recipe exactly, with point multiplication as the one-way step.
• Small and fast. A 256-bit curve matches the strength of 3072-bit classic Diffie–Hellman, with keys about a tenth of the size.
• Ephemeral keys protect the past. Fresh key pairs per connection mean a stolen server key can't unlock recorded traffic.
• It's everywhere. Nearly every HTTPS connection, along with Signal, WhatsApp, SSH and WireGuard, agrees its keys with elliptic-curve Diffie–Hellman.