# Diffie-Hellman Group Exchange and the Logjam Lessons **Source**: https://quantumsequrity.com/blog/dh-group-exchange **Category**: Cryptography Foundations --- [← Back to Blog](../../blog.html) Cryptography Foundations # Diffie-Hellman Group Exchange and the Logjam Lessons 12 min read In 1976, two researchers at Stanford published a paper that changed cryptography forever. Whitfield Diffie and Martin Hellman described a way for two strangers to agree on a secret key over a public wire, without ever meeting first and without sharing anything secret in advance. The trick relied on modular arithmetic and the difficulty of a math problem called the discrete logarithm. For nearly fifty years, that single idea has propped up TLS, SSH, IPsec, and almost every encrypted channel on the internet. The catch is that Diffie-Hellman, the original integer version, depends on choosing the right numbers. Choose weak ones and the whole thing collapses. The 2015 Logjam attack proved that millions of servers had been quietly using parameters small enough for a well-funded attacker to break. The story of how that happened, why named groups exist, and what comes next is the story of every aging crypto standard. ## How Diffie-Hellman Actually Works The original 1976 protocol is surprisingly short to describe. Two parties, call them Alice and Bob, agree publicly on two numbers: a large prime p and a generator g. Alice picks a random secret a, computes A equal to g raised to a, modulo p, and sends A to Bob. Bob picks a random secret b, computes B equal to g raised to b, modulo p, and sends B to Alice. Each side can now compute the same shared value: Alice raises B to her secret a, Bob raises A to his secret b, and the math works out so both end up with g raised to the product ab modulo p. The security rests on the assumption that an attacker watching the wire, who sees A and B but not a or b, cannot work backward to recover the shared secret. This is the discrete logarithm problem. For a properly sized prime, no classical algorithm can solve it in any reasonable time. In practice, p needs to be at least 2048 bits today, and the group needs structure that resists special-purpose attacks. That word "group" matters. Mathematicians use it to describe the set of numbers and the operation that combines them. Diffie-Hellman over the integers modulo a prime is one kind of group. Elliptic curve Diffie-Hellman uses a different kind, where the operation is point addition instead of multiplication. Both share the same handshake shape but live in different mathematical worlds. For a layman tour of the elliptic curve cousin, see [X25519 and Ed25519 Explained](x25519-ed25519-explained.html). ## The Group Exchange Variant Plain Diffie-Hellman fixes p and g in advance, often baked into the protocol or the certificate chain. SSH and TLS originally took this approach. The downside is obvious: if you bake in one prime, you commit every connection in the world to that single number. Crack it once, and every recorded handshake that used it falls. To soften the problem, IETF defined Diffie-Hellman Group Exchange. Instead of using a fixed prime, the server picks a prime from a list of choices, often based on a size the client requests, and sends it to the client. The client uses whatever the server offered. This was meant to allow gradual upgrades, where servers could introduce stronger primes without breaking older clients. The idea looked good on paper. In practice it created two problems. First, server admins rarely audited the primes their software shipped with. Second, the protocol let the server downgrade the size mid-handshake, and clients seldom checked. ## Logjam: When Old Choices Came Back In May 2015, a team of academics published the Logjam attack. They showed that an attacker on the network path could force a TLS server and client to negotiate a 512-bit "export-grade" Diffie-Hellman group, a holdover from 1990s US cryptography export rules. Once the client and server agreed on this weak group, the attacker could break the discrete logarithm in around a minute on commodity hardware, recover the session key, and read or modify every byte that followed. The deeper finding hit harder. The team discovered that a single 1024-bit prime, hardcoded in popular VPN and SSH software, was used by tens of thousands of servers. Breaking that one prime took serious resources, around a year of computation on a few thousand cores, but once broken, every connection that ever used it would be readable. They estimated that a nation-state attacker could realistically afford to break a 1024-bit prime and decrypt a substantial fraction of the world's TLS traffic. The number that mattered was not "how strong is 1024 bits in theory" but "how many servers share the same 1024-bit prime." Because so many shared the same one, the attacker only had to pay the cost once. This is the harvest-now-decrypt-later problem in a different costume. For more on that pattern see [Harvest Now, Decrypt Later](harvest-now-decrypt-later.html). ## The IETF Response: Named Groups Logjam pushed the IETF to clean up. RFC 7919, published in 2016, defined a fixed set of vetted finite-field Diffie-Hellman groups: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, and ffdhe8192. These primes are public, well analyzed, and chosen using a transparent method that anyone can reproduce. Servers and clients negotiate which group to use through a TLS extension, and downgrade to weaker groups becomes detectable. The shift from "pick your own prime" to "use a small set of named groups" turned out to be the right architectural choice. Elliptic curve TLS had already moved this way years earlier with named curves like P-256 and X25519. The finite-field side was just catching up. By TLS 1.3, the only Diffie-Hellman options left in the standard are these named groups, both finite-field and elliptic-curve. Custom primes are gone from the protocol entirely. ## CNSA 2.0 and the Quantum Sunset In 2022, the NSA published the Commercial National Security Algorithm Suite 2.0. CNSA 2.0 sets the timeline for moving US national security systems to post-quantum cryptography. Diffie-Hellman in any classical form, including ECDH, is on the deprecation track. By 2030 to 2033, depending on the system class, classical key exchange must be replaced or run in hybrid mode alongside a post-quantum mechanism. The reason is straightforward. Shor's algorithm, when run on a sufficiently large quantum computer, breaks the discrete logarithm problem in polynomial time. That means it breaks both finite-field Diffie-Hellman and elliptic-curve Diffie-Hellman. The estimates for "sufficiently large" keep dropping as quantum engineering improves. Recorded traffic encrypted today, if it stays sensitive past 2030, is at risk. The NIST replacement is ML-KEM, formerly Kyber, standardized in FIPS 203. To get a clear walkthrough see [ML-KEM Explained](ml-kem-explained.html). Best practice is to deploy hybrid key exchange now, where a classical mechanism like X25519 runs side by side with ML-KEM, and an attacker has to break both to recover the session key. See [Hybrid Encryption](hybrid-encryption.html) for the full picture. ## What Logjam Taught Us About Crypto Hygiene Logjam was not really a new attack. The math was known. The export-grade primes had been considered breakable for years. The reason it landed so hard was that nobody had actually checked which servers were running with which primes. The attack surface was hiding in plain sight, distributed across thousands of admins who had never thought to audit their cipher configurations. A few patterns from Logjam keep showing up in every later crypto incident: Default values stay forever. Whatever ships in the default config of OpenSSL, sshd, or Apache becomes the de facto standard for half the internet. If the default is weak, the internet is weak, regardless of what the standards say. Negotiation creates downgrade paths. Any time a protocol lets two sides agree on a parameter, an attacker in the middle gets a vote. TLS 1.3 cut a huge amount of negotiation surface for exactly this reason. Shared parameters multiply risk. Reusing the same prime across millions of servers turned a hard problem into a worthwhile one for a nation-state. Modern designs avoid this by using ephemeral keys and named-but-rotated groups. Crypto agility is hard. Even with named groups, getting the world to actually move from ffdhe2048 to ffdhe3072, or from finite-field DH to elliptic curve DH, took years. The post-quantum migration will take longer. ## How QNSQY Approaches Key Exchange QNSQY does not use plain Diffie-Hellman for file encryption. The threat model is different from a TLS session. Files are encrypted at rest and may be decrypted years later, so any classical key agreement is a liability. Instead, QNSQY uses ML-KEM in hybrid with X25519. The X25519 part gives you the strength of a well-vetted classical primitive in case ML-KEM ever has an unexpected weakness. The ML-KEM part gives you protection against quantum attackers harvesting traffic today. Symmetric encryption is handled by AES-256-GCM, covered in [AES-256-GCM Explained](aes-256-gcm-explained.html). Password-derived keys go through Argon2id, covered in [Argon2id Explained](argon2id-explained.html). The hash function is BLAKE3, covered in [BLAKE3 Hashing](blake3-hashing.html). The point is not that Diffie-Hellman was a bad design. It was a great design, ahead of its time. The point is that any single primitive, given enough decades, accumulates ways to fail. The way out is layered defense and clear migration paths, not faith in any single algorithm. ## Lessons for Future Cryptographic Migrations The Logjam story is more than a historical footnote. It is a template for understanding how cryptographic transitions actually work in practice, and the lessons apply directly to the post-quantum migration. Several patterns recur. First, the gap between "the algorithm is broken" and "the deployment is broken" can be decades. Export-grade DH was technically breakable in 1995. The Logjam paper made it operationally exploitable in 2015. The same gap will likely play out with classical DH and ECDH after the first cryptographically relevant quantum computers arrive: the algorithms will be technically broken but the deployments will linger for years. Second, default configurations control security in practice more than standards do. RFC 4419 (DH Group Exchange) was a fine standard. The deployments shipped with weak default groups for years because nobody changed the defaults. PQC migration depends entirely on default configurations in the major libraries (OpenSSL, BoringSSL, libsodium, mbed TLS) shifting to hybrid PQC as the new default. As of 2026 several libraries have made this shift in development branches; rolling it out to released production versions is the next step. Third, the lifecycle of an aging cryptographic primitive includes a long tail of legacy systems that cannot be upgraded. The 1024-bit DH groups that Logjam targeted are still active in some VPN appliances and embedded devices today, more than a decade after the published attack. The PQC migration will create a similar long tail. Operators should plan for compensating controls (network segmentation, additional access controls, log aggregation) for systems that cannot be migrated. Fourth, audit and visibility matter. Logjam happened in part because nobody ran systematic scans of internet-facing servers to enumerate the DH groups in use. Modern internet measurement projects (Censys, Shodan, Rapid7's Project Sonar) have made these scans routine. Operators should expect that PQC deployment progress will be measured and reported publicly the same way TLS deployment progress is measured today. ## Frequently Asked Questions **Is Diffie-Hellman still safe to use today?** For non-quantum threats, yes, as long as you use named groups of at least 2048 bits for finite-field DH or use elliptic-curve DH like X25519 or P-256. Custom primes, anything under 2048 bits, and export-grade groups should all be considered broken. For long-lived secrets that need to stay confidential past 2030, you should be running hybrid post-quantum already. **What is the difference between DH and DH group exchange?** Plain Diffie-Hellman uses a fixed prime baked into the protocol. Group Exchange lets the server pick a prime from a list, allegedly to allow flexibility. Logjam showed that the flexibility created downgrade attacks. RFC 7919 named groups solved this by making the choices public and vetted. **Why did Logjam matter if 512-bit DH was already known to be weak?** The export-grade weakness was known. What Logjam added was the network-level downgrade attack: an attacker could force two endpoints that both supported strong DH to negotiate a weak group. The endpoints did not check what they had agreed on. The combination of "we still ship export-grade" plus "we do not verify the negotiated group" was the actual vulnerability. **Does TLS 1.3 still use Diffie-Hellman?** Yes, but only the named-group form, with finite-field groups from RFC 7919 or elliptic-curve groups like X25519 and P-256. Custom primes are removed from the protocol. TLS 1.3 also requires forward secrecy, meaning every connection uses a fresh ephemeral key pair, so even if a long-term key leaks, past sessions stay protected. **When does Diffie-Hellman officially get retired?** Under CNSA 2.0, US national security systems must complete the transition to post-quantum key exchange by 2030 to 2033 depending on the system. Hybrid deployments, where DH runs alongside ML-KEM, are the recommended interim posture. NIST has not set a hard sunset date for civilian DH, but the direction is clear. **How do hybrid post-quantum handshakes interact with named DH groups?** The current IETF draft for hybrid TLS combines a classical key exchange (often X25519, sometimes a named finite-field DH group) with ML-KEM. The two key exchanges run in parallel, each producing a shared secret, and the secrets are combined through a key derivation function to produce the session key. An attacker must break both algorithms to recover the session key. The named-group discipline established by RFC 7919 carries forward into the hybrid handshake design: the classical side uses well-vetted public groups, not custom primes. **Does SSH have an equivalent of RFC 7919 named groups?** SSH has been moving toward fixed groups for similar reasons. RFC 8268 added Curve25519 and Curve448 as named curves for SSH key exchange. The diffie-hellman-group-exchange-sha256 method (which uses server-chosen primes similar to TLS DH-GEX) is still supported but increasingly considered legacy. Modern OpenSSH defaults favor curve25519-sha256 and similar named-curve methods for the same reasons TLS 1.3 mandates named groups. ## Sources 1. Diffie, W. and Hellman, M. "New Directions in Cryptography." IEEE Transactions on Information Theory, 1976. https://ee.stanford.edu/~hellman/publications/24.pdf 2. Adrian, D. et al. "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice." ACM CCS 2015 (Logjam paper). https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf 3. IETF RFC 7919. "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS." https://datatracker.ietf.org/doc/html/rfc7919 4. NSA. "Commercial National Security Algorithm Suite 2.0." 2022. https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF 5. NIST FIPS 203. "Module-Lattice-Based Key-Encapsulation Mechanism Standard." 2024. https://csrc.nist.gov/pubs/fips/203/final 6. IETF RFC 8446. "The Transport Layer Security (TLS) Protocol Version 1.3." https://datatracker.ietf.org/doc/html/rfc8446 7. IETF RFC 8268. "More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)." https://datatracker.ietf.org/doc/html/rfc8268 ## Related Articles - [What Is Post-Quantum Cryptography](what-is-post-quantum-cryptography.html) - [Why RSA-2048 Will Break](why-rsa-2048-will-break.html) - [ML-KEM Explained](ml-kem-explained.html) - [Hybrid Encryption](hybrid-encryption.html) - [Harvest Now, Decrypt Later](harvest-now-decrypt-later.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)