up:: Classical Cryptography MOC

Elliptic-Curve Diffie-Hellman (ECDH)

Elliptic-Curve Diffie-Hellman (ECDH) is a public-key key-agreement method that lets two parties derive the same shared secret over an open channel without ever sending that secret across it. It is the elliptic-curve version of Diffie-Hellman, and its security rests on the elliptic-curve discrete logarithm problem. ECDH establishes the session keys behind most of today’s encrypted traffic, from TLS on the web to Signal messages, which is exactly why it’s the most urgent thing to replace: Shor’s algorithm solves that math efficiently, so a future quantum computer recovers the shared secret and decrypts anything an adversary recorded years earlier.

The short version:

• ECDH lets two sides agree on a shared secret over a channel anyone can watch, then turn that secret into symmetric session keys. It’s key agreement, not encryption and not a signature.
• Its ephemeral form, ECDHE, generates fresh keys per session and gives forward secrecy, so stealing a server’s long-term key doesn’t unlock past sessions. TLS 1.3 uses only ephemeral (EC)DHE.
• ECDH’s security rests on the elliptic-curve discrete logarithm problem, which Shor’s algorithm solves in polynomial time on a large quantum computer. That’s a full break, not a weakening.
• It’s the number-one harvest-now-decrypt-later exposure: recorded ECDHE traffic can be decrypted later once a quantum computer exists, so the clock is already running on data captured today.
• The replacement is ML-KEM, deployed today in hybrid form as X25519MLKEM768 so classical and post-quantum protection stack during the transition.

What is ECDH?

Elliptic-Curve Diffie-Hellman is a key-agreement protocol: a way for two parties who have never met to compute an identical secret value using elliptic-curve math, even though every message they exchange is visible to an eavesdropper. That shared value is then run through a key derivation function to produce the symmetric keys that actually encrypt the conversation.

It belongs to the family of discrete-logarithm public-key schemes. Classical Diffie-Hellman does the same job using arithmetic in a large finite field; ECDH does it using points on an elliptic curve, which buys the same security at far smaller key sizes and higher speed. NIST specifies the elliptic-curve version as the “ECC CDH” primitive inside its discrete-logarithm key-establishment standard.

Source: NIST, “Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography,” SP 800-56A Rev. 3, April 2018, csrc.nist.gov.

Two things ECDH is not. It’s not a digital signature scheme, so it proves nothing about who you’re talking to on its own; that job belongs to ECDSA, Ed25519, or RSA signatures. And it’s not the cipher that encrypts your data; that’s a symmetric algorithm like AES. ECDH only produces the secret those other pieces depend on. On its own it gives you key agreement, so it’s paired with certificates and signatures to build an authenticated channel.

The everyday analogy: mixing paint

Picture two people who want a shared secret color while a spy watches everything they mail each other. They publicly agree on a common base paint, say yellow. Each privately picks a secret color and mixes it into the yellow: one makes a green, the other an orange, and they mail those mixtures across. Now each adds their own private color again to the mixture they received. Both end up at the exact same final color, because it’s the same three paints combined, just in a different order. The spy saw the yellow, the green, and the orange go by, but separating a specific paint back out of a mixture is the hard part, so the final shared color stays secret. ECDH is that trick done with elliptic-curve points instead of paint, where “un-mixing” is the elliptic-curve discrete logarithm problem.

How does ECDH work?

ECDH runs in a fixed sequence. Once both sides hold public agreement on the curve, the exchange is short:

1. Both parties agree on the elliptic-curve domain parameters: a specific curve, a base point G on it, and the group structure. These are public and usually baked into the protocol (P-256, X25519, and so on).
2. The first party picks a secret random scalar a (their private key) and computes their public key A = aG, which is G added to itself a times on the curve. They send A.
3. The second party picks a secret scalar b and computes B = bG. They send B.
4. The first party computes S = aB. The second computes S = bA.
5. Both land on the same point, because aB = a(bG) = b(aG) = bA = abG. That shared point (or a coordinate of it) is fed through a KDF to derive the symmetric session keys.

The security comes from the gap between how easy multiplication is and how hard reversal is. Computing A = aG from a is fast. Going the other way, recovering the secret scalar a from the public A and G, is the elliptic-curve discrete logarithm problem (ECDLP), which no classical algorithm solves efficiently for well-chosen curves. An eavesdropper sees G, A, and B, but computing abG from those without knowing a or b is the elliptic-curve Diffie-Hellman problem, which is believed just as hard.

Source: NIST, SP 800-56A Rev. 3, §5.7 (ECC CDH primitive), April 2018, csrc.nist.gov.

What is ECDHE, and how does it give forward secrecy?

ECDHE is ephemeral ECDH: instead of reusing a long-term key pair, each side generates a brand-new, throwaway key pair for every single session and discards it afterward. The “E” stands for ephemeral. This is the form that dominates modern protocols, and it’s what delivers forward secrecy.

Forward secrecy means that compromising a server’s long-term private key does not expose past sessions. Because each ECDHE handshake derived its secret from throwaway keys that were deleted once the session ended, there’s no stored key an attacker can steal to reconstruct yesterday’s traffic. Static ECDH, by contrast, reuses one long-term key pair, so cracking or stealing that one key would unlock every session it ever protected. That’s why static ECDH is largely retired in favor of ECDHE wherever confidentiality matters.

TLS 1.3 made this mandatory. It removed static RSA and static Diffie-Hellman key exchange entirely, so every TLS 1.3 handshake uses ephemeral (EC)DHE and every connection gets forward secrecy by default.

Source: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, August 2018, datatracker.ietf.org: “Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.”

One nuance worth holding onto: forward secrecy protects against a future key theft, but it does nothing against a future quantum computer. If an adversary recorded the ECDHE handshake, they can still recover that session’s secret later by breaking the curve math directly. That’s the harvest-now-decrypt-later problem below, and it’s why forward secrecy and quantum resistance are separate properties.

What is ECDH used for?

ECDH is the quiet workhorse of modern secure communications. It usually lives inside protocol negotiation and cryptographic libraries rather than showing up as a visible feature, so it’s everywhere and easy to overlook. The most common places it establishes session secrets:

1. TLS on the web and APIs. Nearly every HTTPS connection negotiates an ECDHE key exchange to set up the session, in both TLS 1.2 (via ECDHE cipher suites) and TLS 1.3 (where ephemeral (EC)DHE is the only option).
2. Secure messaging. Signal’s key agreement is built on ECDH over Curve25519. Its X3DH handshake performs three or four ECDH operations to bootstrap a conversation, and Signal has since layered a post-quantum KEM on top of that same ECDH in its PQXDH upgrade.
3. VPNs and tunnels. WireGuard, IPsec/IKEv2, and SSH all use elliptic-curve Diffie-Hellman to establish tunnel keys.
4. Service-to-service and platform traffic. Internal mesh traffic, mobile client-to-server sessions, and embedded and IoT device links routinely bootstrap their encryption with ECDH.

Sources: for TLS 1.2 ECDHE, Y. Nir, S. Josefsson, M. Pegourie-Gonnard, “Elliptic Curve Cryptography (ECC) Cipher Suites for TLS Versions 1.2 and Earlier,” RFC 8422, August 2018, datatracker.ietf.org; for Signal, “The X3DH Key Agreement Protocol,” Signal, signal.org and “The PQXDH Key Agreement Protocol,” Signal, signal.org.

The practical consequence: ECDH sits directly on the confidentiality of web traffic, API calls, messaging, VPN tunnels, and service links. When people picture “modern crypto,” ECDH is usually the part actually agreeing the secret.

Is ECDH quantum-vulnerable?

Yes, and completely. ECDH is broken by Shor’s algorithm, which solves the elliptic-curve discrete logarithm problem in polynomial time on a large fault-tolerant quantum computer. Because ECDH’s entire security rests on that problem being hard, a capable quantum computer recovers the private scalar a from the public key A = aG, reconstructs the shared secret, and reads the session. This is a structural break, not the kind of gradual weakening you fix with a bigger key.

Source: P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput. 26(5), 1997, arxiv.org.

There’s a counterintuitive twist here. Elliptic-curve algorithms fall to a smaller quantum computer than RSA of comparable classical strength. Resource estimates put breaking a 256-bit elliptic curve at roughly 2,330 logical qubits, fewer than the thousands needed to factor an equivalent-strength RSA modulus. The very efficiency that made ECC attractive, small keys for strong classical security, makes it a slightly easier quantum target than RSA. So “we use elliptic curves, we’re on the modern stuff” is not the safer position it sounds like.

Source: M. Roetteler, M. Naehrig, K. M. Svore, K. Lauter, “Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms,” ASIACRYPT 2017, arxiv.org.

To be exact about which quantum attack matters: ECDH is threatened by Shor’s algorithm, not Grover’s algorithm. Grover’s only speeds up brute-force search and merely dents symmetric ciphers and hashes like AES and SHA-256, which survive with larger parameters. Shor’s is the one that ends public-key schemes like ECDH outright.

Why is ECDH the biggest harvest-now-decrypt-later exposure?

Because ECDH protects confidentiality and its failure is retroactive. An adversary can record encrypted traffic today, store the visible handshake material, and simply wait. Once a cryptographically relevant quantum computer exists, they run Shor’s algorithm against the recorded ECDHE exchange, recover the session secret, and decrypt everything that session carried. This is harvest-now-decrypt-later, and ECDH is its canonical target because it establishes the secret behind so much recorded traffic.

Note the asymmetry with signatures. A forged signature only matters in real time; you can’t retroactively forge your way into a conversation that already happened. But a broken key exchange retroactively unlocks data captured years ago. That makes ECDH exposure a function of how long your data must stay secret, with the arrival of quantum computers setting only the moment recovery becomes possible. Recorded TLS sessions, archived messaging traffic, and captured service-to-service links protecting long-lived secrets are all exposed the moment the capability lands.

This is Mosca’s inequality made concrete. If the time your data must stay confidential (X) plus the time to migrate your systems (Y) is greater than the time until a quantum computer exists (Z), then data you’re transmitting right now over ECDH is already at risk. The parallel is exact history: the Venona project showed that ciphertext collected in the 1940s stayed useful to codebreakers for decades, decrypted long after the senders assumed it was safe forever.

What replaces ECDH?

The replacement is ML-KEM, the NIST-standardized, module-lattice key-encapsulation mechanism finalized in 2024. ML-KEM does the same job ECDH did, establishing a shared secret over an open channel, but it rests on a lattice problem that no known quantum algorithm solves efficiently. Trying to make ECDH “quantum-safe” by switching to a bigger curve does not help; every classical curve rests on the same discrete-log problem Shor’s algorithm breaks.

Source: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, csrc.nist.gov.

In practice the transition is happening in hybrid form rather than a hard cutover. A hybrid key exchange runs ECDH and ML-KEM together and derives the session secret from both, so the connection stays safe as long as either one holds. For TLS 1.3 the leading hybrid is X25519MLKEM768, codepoint 0x11EC, which combines X25519 elliptic-curve Diffie-Hellman with ML-KEM-768. It’s registered in the IETF’s ECDHE-MLKEM draft and already carries real traffic.

Source: K. Kwiatkowski et al., “Post-quantum hybrid key agreement X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 for TLS 1.3,” draft-ietf-tls-ecdhe-mlkem, datatracker.ietf.org.

Hybrid is the pragmatic default for two reasons. It hedges the newer lattice math against any surprise cryptanalysis, since the battle-tested X25519 component still protects you if ML-KEM is later weakened. And it eases interoperability while the ecosystem catches up. This is why ECDH’s own successor deployment keeps ECDH in the loop during transition rather than ripping it out, and why hybrid cryptography and crypto-agility are the operating model for the migration.

Where does ECDH sit on the migration timeline?

NIST’s transition guidance (NIST IR 8547) puts elliptic-curve Diffie-Hellman on a published deprecation schedule, and CNSA 2.0 already requires ML-KEM for national-security systems. The federal target for completing PQC migration is 2035, set by National Security Memorandum 10.

Milestone	What it means for ECDH
Now	ECDH / ECDHE is approved and everywhere; hybrid ML-KEM deployment is live and growing
After 2030	Elliptic-curve DH at 112-bit strength is deprecated (usable, with acknowledged risk) per NIST IR 8547
After 2035	Elliptic-curve DH is disallowed for federal key establishment at all strengths per NIST IR 8547
By 2035	NSM-10 target to complete federal migration to quantum-resistant cryptography

Source: NIST, “Transition to Post-Quantum Cryptography Standards,” NIST IR 8547 ipd, Table 4 (Elliptic Curve DH and MQC, SP 800-56A), November 2024, csrc.nist.gov.

What are the curves and parameters?

ECDH runs over a specific named curve, and the curve determines both the classical security level and the key sizes. The common ones fall into two families: the NIST prime curves and the modern Montgomery curves.

Curve	Family	Classical security	Public key size	Primary source
P-256 (secp256r1)	NIST prime	~128-bit	65 bytes (uncompressed)	SP 800-186
P-384 (secp384r1)	NIST prime	~192-bit	96 bytes	SP 800-186
P-521 (secp521r1)	NIST prime	~256-bit	132 bytes	SP 800-186
X25519 (Curve25519)	Montgomery	~128-bit	32 bytes	RFC 7748
X448 (Curve448)	Montgomery	~224-bit	56 bytes	RFC 7748

Sources: NIST, “Recommendations for Discrete Logarithm-Based Cryptography: Elliptic Curve Domain Parameters,” SP 800-186, February 2023, csrc.nist.gov; A. Langley, M. Hamburg, S. Turner, “Elliptic Curves for Security,” RFC 7748, January 2016, datatracker.ietf.org.

X25519 is the most widely deployed curve for key exchange in modern protocols, prized for its speed and its resistance to certain implementation mistakes. Note the theme across the whole table: every one of these rests on the elliptic-curve discrete logarithm problem, so every one falls to Shor’s algorithm. Picking a bigger curve raises the classical security level and the quantum cost, but it never crosses into quantum-safe territory.

Common misconceptions

1. “We use modern elliptic-curve crypto, so we’re quantum-safe.” Modern and quantum-safe are unrelated here. X25519 is state-of-the-art against classical attackers and completely broken by Shor’s algorithm, the same as an old NIST curve.
2. “Elliptic curves are stronger than RSA, so they’ll last longer against quantum.” The opposite. Because ECC packs strong security into small keys, breaking a curve takes fewer qubits than breaking comparable-strength RSA, so it’s a marginally easier quantum target.
3. “Forward secrecy already protects my recorded traffic.” Forward secrecy defeats a future theft of a long-term key. It does nothing against a future quantum computer that breaks the recorded handshake’s curve math directly.
4. “ECDH encrypts my data.” It doesn’t. ECDH only agrees the secret; a symmetric cipher like AES-256 does the encrypting, and that symmetric layer stays quantum-resilient with a large key.
5. “Switching to a larger curve like P-521 buys quantum protection.” It buys a bigger classical margin and a higher quantum cost, but no classical curve is quantum-safe, because all of them rest on the discrete logarithm Shor’s algorithm solves.
6. “If we just double the ECDH key we’re fine, like with AES.” The double-the-key fix works for symmetric algorithms weakened by Grover’s search. ECDH is broken outright by Shor’s, so upsizing doesn’t rescue it; it has to be replaced.

Questions people ask

Is ECDH still safe to use today? Yes, against every classical attacker, ECDH and ECDHE remain secure and are the current standard. The risk is entirely future and retroactive: traffic you protect with ECDH now can be decrypted later once a quantum computer exists, so long-lived confidential data is the real concern.

Do I have to replace ECDH? Eventually, yes, for anything with a long confidentiality lifetime. NIST IR 8547 deprecates elliptic-curve key establishment after 2030 and disallows it for federal use after 2035, and NSM-10 sets 2035 as the federal migration target. Most teams are moving to hybrid X25519MLKEM768 rather than waiting for a hard deadline.

What’s the difference between ECDH and ECDHE? ECDH is the general method; ECDHE is its ephemeral form, which generates a fresh throwaway key pair per session. ECDHE is what provides forward secrecy, and it’s the only key-exchange mode TLS 1.3 allows.

What’s the difference between ECDH and RSA? ECDH is key agreement (both sides jointly derive a secret) resting on the elliptic-curve discrete logarithm; RSA does key transport (one side encrypts a secret to the other’s public key) resting on integer factoring. Both are public-key, both are broken by Shor’s algorithm, and both need replacing.

Does ECDH replace the encryption of my actual data? No. ECDH establishes the session secret, and a symmetric cipher such as AES-256 encrypts the data itself. Only the ECDH key-agreement step needs a post-quantum replacement; the symmetric layer carries forward with an appropriate key size.

What replaces ECDH, and is it ready? ML-KEM (FIPS 203, finalized 2024) is the standardized replacement, and it’s ready. In practice it’s deployed as the hybrid X25519MLKEM768, which pairs classical X25519 with ML-KEM-768 so you’re protected if either holds. Major browsers, TLS libraries, and CDNs already negotiate it.

Is X25519 post-quantum safe because it’s newer? No. X25519 is a modern, fast, well-designed elliptic curve, and it’s just as broken by Shor’s algorithm as any older curve, because it rests on the same discrete-log problem. Newer does not mean quantum-resistant.

How urgent is this for my organization? It depends on how long your data must stay secret. Apply Mosca’s inequality: if secrecy-lifetime plus migration-time exceeds the time until a quantum computer arrives, data you send today is already exposed, which pushes ECDH-protected long-lived confidential traffic to the front of the queue.

---

Everything here is the map, given freely. When your team needs its own key-exchange exposure found, prioritized, and sequenced onto a real migration plan, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.