up:: Classical Cryptography MOC

Diffie-Hellman (DH)

Diffie-Hellman (DH) is the original public-key key-agreement method, published in 1976, that lets two parties who have never met derive the same shared secret over a channel anyone can watch, without ever sending that secret across it. Classical DH does this using arithmetic in a large finite field, and its security rests on the discrete logarithm problem being hard to reverse. It was the breakthrough that made secure sessions possible without pre-sharing a key, and it still establishes session keys in TLS, IPsec, and SSH. In the post-quantum world it matters because Shor’s algorithm solves the finite-field discrete log efficiently, so a large quantum computer recovers the shared secret and decrypts traffic recorded years earlier.

The short version:

• DH lets two sides agree on a shared secret over an open channel, then turn that secret into symmetric session keys. It’s key agreement, not encryption and not a signature.
• Its ephemeral form, DHE, generates fresh keys per session and gives forward secrecy, so stealing a server’s long-term key doesn’t unlock past sessions.
• Classical DH’s security rests on the finite-field discrete logarithm problem, which Shor’s algorithm solves in polynomial time on a large quantum computer. That’s a full break, not a weakening.
• Finite-field DH mostly gave way to ECDH, which reaches the same security with far smaller keys and more speed. Both rest on a discrete log, so both fall to Shor’s.
• The replacement is ML-KEM, deployed today in hybrid form so classical and post-quantum protection stack during the transition.

The everyday analogy: spinning to a shared number on a giant clock

Picture a clock face with a huge prime number of hour marks instead of twelve, and one agreed starting hand position that everyone, including an eavesdropper, can see. Each of two people privately picks a secret number of times to advance the hand around the clock, wrapping past the top over and over, and mails the resulting position to the other.

Now each person takes the position they received and advances it by their own secret number of spins again. Both land on the exact same final mark, because spinning by your number then by mine reaches the same place as spinning by mine then by yours. An eavesdropper saw the two intermediate positions go by, but figuring out how many spins produced a given mark on a clock this large is the finite-field discrete logarithm problem, and that’s the part nobody can do quickly. DH is that trick done with modular arithmetic, where the “clock” is the numbers below a large prime.

What is Diffie-Hellman?

Diffie-Hellman is a key-agreement protocol: a way for two parties to compute an identical secret value over a channel an eavesdropper can fully observe, using arithmetic in a large finite field. That shared value is then run through a key derivation function to produce the symmetric keys that actually encrypt the conversation. Whitfield Diffie and Martin Hellman introduced it in their 1976 paper “New Directions in Cryptography,” which solved the problem that had constrained cryptography for centuries, namely how two parties establish a shared key without first meeting to exchange one.

Source: W. Diffie and M. Hellman, “New Directions in Cryptography,” IEEE Transactions on Information Theory, vol. IT-22, no. 6, pp. 644-654, November 1976, ee.stanford.edu.

It belongs to the family of discrete-logarithm public-key schemes. Classical finite-field DH works in the multiplicative group of integers modulo a large prime p; ECDH does the same job over points on an elliptic curve, which buys the same security at far smaller key sizes. NIST specifies the finite-field version as the “FFC DH” 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 DH is not. It’s not a digital signature scheme, so on its own it proves nothing about who you’re talking to; that job belongs to RSA, ECDSA, or Ed25519 signatures. And it’s not the cipher that encrypts your data; that’s a symmetric algorithm like AES. DH only produces the secret those other pieces depend on, so it’s paired with certificates and signatures to build an authenticated channel.

How does Diffie-Hellman work?

Finite-field DH runs in a fixed sequence. Once both sides share the public parameters, the exchange is short:

1. Both parties agree on public parameters: a large prime p and a generator g of a subgroup of the integers modulo p. These are public and usually baked into the protocol.
2. The first party picks a secret random exponent a (their private key) and computes their public value A = g^a mod p. They send A.
3. The second party picks a secret exponent b and computes B = g^b mod p. They send B.
4. The first party computes s = B^a mod p. The second computes s = A^b mod p.
5. Both land on the same value, because B^a = (g^b)^a = (g^a)^b = A^b = g^(ab) mod p. That shared value is fed through a KDF to derive the symmetric session keys.

The security comes from the gap between how easy exponentiation is and how hard reversal is. Computing A = g^a mod p from a is fast. Going the other way, recovering the secret exponent a from the public A, g, and p, is the finite-field discrete logarithm problem, which no efficient classical algorithm solves for well-chosen parameters. An eavesdropper sees p, g, A, and B, but computing g^(ab) mod p from those without knowing a or b is the Computational Diffie-Hellman problem, which is believed just as hard.

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

What is ephemeral Diffie-Hellman (DHE), and how does it give forward secrecy?

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

Forward secrecy means compromising a server’s long-term private key does not expose past sessions. Because each DHE handshake derived its secret from throwaway exponents that were deleted once the session ended, there’s no stored key an attacker can steal to reconstruct yesterday’s traffic. Static DH, 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 DH is largely retired in favor of ephemeral DHE wherever confidentiality matters.

TLS 1.3 made this the rule. It removed static RSA and static Diffie-Hellman key exchange entirely, so every TLS 1.3 handshake uses ephemeral key exchange 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 is worth holding onto. Forward secrecy protects against a future key theft, and it does nothing against a future quantum computer. If an adversary recorded the DHE handshake, they can still recover that session’s secret later by breaking the finite-field 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 Diffie-Hellman used for?

Diffie-Hellman is a quiet workhorse of secure communications. It lives inside protocol negotiation and cryptographic libraries rather than showing up as a visible feature, so it’s easy to overlook even though it protects a great deal of traffic. The most common places finite-field DH establishes session secrets:

1. TLS on the web. Older and mixed environments negotiate finite-field DHE cipher suites (the DHE_RSA family) in TLS 1.2, and TLS 1.3 still registers the named ffdhe groups as a key-exchange option, though elliptic-curve exchange now carries most traffic.
2. VPNs and IKE. IPsec’s Internet Key Exchange has long used finite-field DH groups (the “MODP” groups) to establish tunnel keys, and many deployed VPN concentrators and appliances still offer them.
3. SSH. The SSH transport layer defines finite-field Diffie-Hellman group exchange for setting up an encrypted admin session, and legacy SSH configurations still rely on it.
4. Legacy middleware and appliances. Enterprise service buses, older secure-messaging layers, firewalls, routers, and long-lived operational-technology gateways frequently carry inherited finite-field DH defaults.

Sources: for the IKE MODP groups, T. Kivinen, M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” RFC 3526, May 2003, datatracker.ietf.org; for the named TLS finite-field groups, D. Gillmor, “Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS),” RFC 7919, August 2016, datatracker.ietf.org.

The practical consequence: finite-field DH sits directly on the confidentiality of VPN tunnels, administrative SSH sessions, and a slice of web and middleware traffic, often in infrastructure layers that take years to change.

Is Diffie-Hellman quantum-vulnerable?

Yes, and completely. Finite-field DH is broken by Shor’s algorithm, which solves the finite-field discrete logarithm problem in polynomial time on a large fault-tolerant quantum computer. Because DH’s entire security rests on that problem being hard, a capable quantum computer recovers the secret exponent a from the public value A = g^a mod p, reconstructs the shared secret, and reads the session. This is a structural break, not the kind of gradual weakening you fix with a bigger prime.

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.

To be exact about which quantum attack matters: DH 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 DH outright. Moving from a 2048-bit prime to a larger one raises the classical work factor but never crosses into quantum-safe territory, because the target problem is the same discrete log Shor’s solves regardless of size.

How does Diffie-Hellman relate to ECDH?

ECDH is the same idea moved onto a different kind of math. Finite-field DH does its arithmetic modulo a large prime; ECDH does it with points on an elliptic curve. The elliptic-curve version reaches the same classical security at far smaller keys and higher speed, which is why it largely replaced finite-field DH in modern deployments over the last two decades. A finite-field DH group needs roughly 3072 bits to match the strength of a 256-bit elliptic curve, so ECDH’s smaller keys and faster handshakes won out on the open web.

The relationship matters for the quantum transition because it’s a common source of false comfort. Both schemes rest on a discrete logarithm, and both fall to Shor’s algorithm. Migrating from finite-field DH to ECDH modernized performance, and it did nothing for quantum resistance. In fact, resource estimates suggest an elliptic curve of comparable classical strength falls to a slightly smaller quantum computer than an equivalent finite-field group, so “we already moved to elliptic curves” is not the safer position it sounds like. Both need the same post-quantum replacement.

Source: NIST, “Recommendation for Key Management, Part 1,” SP 800-57 Part 1 Rev. 5, §5.6.1 (comparable security strengths of FFC and ECC), May 2020, csrc.nist.gov.

Why is Diffie-Hellman a harvest-now-decrypt-later exposure?

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

Note the asymmetry with signatures. A forged signature only matters in real time, and you can’t retroactively forge your way into a conversation that already happened. A broken key exchange retroactively unlocks data captured years ago. That makes DH exposure a function of how long your data must stay secret, with the arrival of quantum computers setting only the moment recovery becomes possible. This is Mosca’s inequality made concrete: if the time your data must stay confidential plus the time to migrate your systems is greater than the time until a quantum computer exists, then data you’re transmitting right now over DH is already at risk. Legal communications, regulated records, and long-lived operational data moving over finite-field VPN tunnels are exposed the moment the capability lands.

What were Logjam and the weak-parameter attacks?

Logjam is a 2015 attack that showed finite-field DH also fails classically when it’s deployed with weak or shared parameters, well before any quantum computer arrives. A man-in-the-middle could downgrade a vulnerable TLS connection to 512-bit “export-grade” DH, then break that small group in close to real time to read or tamper with the traffic. At the time it affected a measurable share of popular HTTPS sites, and the research team estimated that a nation-state precomputation against a single common 1024-bit group would enable passive eavesdropping on a large fraction of DH-secured connections, because so many servers reused the same standard primes.

Source: D. Adrian, K. Bhargavan, Z. Durumeric, et al., “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice,” ACM CCS 2015, weakdh.org.

The lesson shaped how finite-field DH should be configured. The defenses are: retire export-grade and sub-1024-bit groups entirely, use groups of at least 2048 bits, and stop reusing tiny hand-rolled primes. RFC 7919 answered the reused-parameter risk directly by defining a set of named, well-vetted finite-field groups (ffdhe2048 through ffdhe8192) that a client and server negotiate explicitly, so an attacker can’t silently force a weak custom group. None of this is a post-quantum fix. A properly configured 2048-bit or larger group resists Logjam-style classical attacks and still falls to Shor’s algorithm.

Source: D. Gillmor, “Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS),” RFC 7919, August 2016, datatracker.ietf.org.

What replaces Diffie-Hellman?

The replacement is ML-KEM, the NIST-standardized, module-lattice key-encapsulation mechanism finalized in 2024. ML-KEM does the same job DH 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 finite-field DH “quantum-safe” by switching to a larger prime does not help, because every classical DH group 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 a classical method and ML-KEM together and derives the session secret from both, so the connection stays safe as long as either one holds. On the web the leading hybrid pairs elliptic-curve X25519 with ML-KEM-768 (registered as X25519MLKEM768), and standards work is underway to carry ML-KEM into IKEv2 for IPsec so VPN tunnels get the same protection. Hybrid is the pragmatic default because it hedges the newer lattice math against any surprise cryptanalysis while the ecosystem catches up, which is why crypto-agility and hybrid deployment are the operating model for the migration.

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.

Where does Diffie-Hellman sit on the migration timeline?

NIST’s transition guidance (NIST IR 8547) puts finite-field DH key establishment (the SP 800-56A schemes) on a published deprecation schedule alongside its elliptic-curve sibling, 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 finite-field DH
Now	Finite-field DH / DHE is approved at ≥112-bit strength; hybrid ML-KEM deployment is live and growing
After 2030	Finite-field DH at 112-bit strength is deprecated (usable, with acknowledged risk) per NIST IR 8547
After 2035	Finite-field 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 (Finite Field DH and MQC, SP 800-56A), November 2024, csrc.nist.gov.

What are the parameters and group sizes?

Finite-field DH runs over a specific group defined by a prime p, and the size of that prime sets both the classical security level and the size of the values exchanged. The named groups from RFC 7919 are the well-vetted modern choices; the older export-grade and sub-1024-bit groups are the ones Logjam broke.

Group	Prime size	Approx. classical security	Status	Primary source
512-bit “export”	512-bit	broken	retired, Logjam-vulnerable	weakdh.org
1024-bit (MODP group 2)	1024-bit	~80-bit	discouraged	RFC 3526
ffdhe2048	2048-bit	~103-bit	acceptable minimum	RFC 7919
ffdhe3072	3072-bit	~125-bit	recommended	RFC 7919
ffdhe4096	4096-bit	~150-bit	strong	RFC 7919

Sources: D. Gillmor, RFC 7919, August 2016, datatracker.ietf.org; D. Adrian et al., “Imperfect Forward Secrecy,” ACM CCS 2015, weakdh.org.

Note the theme across the whole table: every one of these rests on the finite-field discrete logarithm problem, so every one falls to Shor’s algorithm. Picking a bigger prime raises the classical security level and the quantum cost, and it never crosses into quantum-safe territory.

Common misconceptions

1. “We moved to a 2048-bit or larger group, so we’re fine.” You’re fine against Logjam-style classical attacks. You’re not quantum-safe, because a 2048-bit DH group still rests on the discrete log Shor’s algorithm breaks.
2. “We use elliptic curves now, so this doesn’t apply to us.” ECDH modernized performance and left quantum exposure untouched. Both DH and ECDH rest on a discrete log and both fall to Shor’s.
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 math directly.
4. “DH encrypts my data.” It doesn’t. DH 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. “TLS 1.3 removed Diffie-Hellman, so it’s gone.” TLS 1.3 removed static DH and RSA key exchange. It relies entirely on ephemeral key exchange, so DHE-style agreement is more central than ever, just always ephemeral.
6. “Logjam was the DH vulnerability, and it’s patched.” Logjam was a classical weak-parameter problem, and configuration fixed it. The quantum break from Shor’s algorithm is a separate, unfixed problem that no parameter choice solves.

Questions people ask

Is Diffie-Hellman still safe to use today? Yes, against every classical attacker, a properly configured DH group of at least 2048 bits remains secure. The risk is future and retroactive: traffic you protect with DH now can be decrypted later once a quantum computer exists, so long-lived confidential data is the real concern.

Do I have to replace Diffie-Hellman? Eventually, yes, for anything with a long confidentiality lifetime. NIST IR 8547 deprecates finite-field DH 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 key exchange rather than waiting for a hard deadline.

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

What’s the difference between DH and ECDH? Both are Diffie-Hellman key agreement resting on a discrete logarithm. Finite-field DH works modulo a large prime; ECDH works over an elliptic curve, reaching the same strength with much smaller keys, which is why it mostly replaced finite-field DH. Both are broken by Shor’s algorithm.

What’s the difference between DH and RSA? DH is key agreement, where both sides jointly derive a secret, resting on the discrete logarithm. RSA does key transport, where 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.

Was Logjam a break of Diffie-Hellman itself? No. Logjam exploited weak deployment (tiny export-grade groups and reused primes), not the math of DH at a proper size. It’s fixed by using 2048-bit or larger vetted groups. The quantum threat from Shor’s algorithm is separate and is not fixed by parameter size.

What replaces Diffie-Hellman, and is it ready? ML-KEM (finalized 2024) is the standardized replacement, and it’s ready. In practice it’s deployed in hybrid form, pairing a classical method with ML-KEM so you’re protected if either holds. Major browsers, TLS libraries, and CDNs already negotiate hybrid key exchange.

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 DH-protected long-lived confidential traffic (VPN tunnels, archived sessions) 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.