Diffie-Hellman key agreement is usually introduced as a single clever trick: two parties each keep a private number, exchange public values, and arrive at the same shared secret that never crossed the wire. The trick is real, but its security is not a property of the trick alone. It depends on which mathematical group the arithmetic runs in, on which public values a party is willing to accept from the other side, on whether anything proves who that other side is, and on whether the private numbers are thrown away afterwards. Each of these has failed in deployed systems, sometimes on a very large scale. This article takes them one at a time, using small numbers you can check, and separates three different hardness problems that are often blurred together. It ends with the checks and configuration choices that practitioners, and the artificial intelligence (AI) agents whose connections depend on them, should insist on.

Three problems, not one

Diffie-Hellman, named after Whitfield Diffie and Martin Hellman, works on a clock that wraps around at a prime number p, using a public starting value g called the generator. Alice keeps a private number a and publishes g raised to the power a, wrapped at p. Bob does the same with b. Each raises the other's public value to their own private number, and both arrive at g raised to a times b. The question is what an eavesdropper would have to do to get that shared value, and the honest answer is that there are three different problems hiding in it.

The discrete logarithm problem asks: given g and g to the a, find a. If you can do that, you can compute anything Alice can. The computational Diffie-Hellman problem asks something weaker: given g to the a and g to the b, find g to the a times b, without necessarily finding a or b. The decisional Diffie-Hellman problem asks something weaker still: given g to the a, g to the b and some candidate value, tell whether the candidate is the real shared secret or just a random group element.

These form a ladder. Anyone who can solve discrete logarithms can solve the computational problem, and anyone who can solve the computational problem can solve the decisional one. Security arguments for real protocols usually need the top of the ladder: that the shared secret looks completely random, so it can be fed into a key derivation function and used as key material. In some groups that strongest assumption simply fails even though finding the discrete logarithm stays hard, and the next section shows one with numbers you can check.

Solving the base breaks every level above it, so assuming the apex is hard is the strongest and most fragile assumption. A ladder of assumptions Decisional DHsecret looks random Computational DHcannot compute the secret Discrete logarithmcannot find the private number stronger assumption breaking flows up
Solving the base breaks every level above it, so assuming the apex is hard is the strongest and most fragile assumption.

A small group with a leak

Take the classic toy setting: the prime 23 and the generator 5. The powers of 5 visit all 22 nonzero positions on the 23-clock before returning to 1, so 5 generates the whole group. Alice picks 6 and publishes 8; Bob picks 15 and publishes 19. The shared secret is 2. So far, nothing is wrong.

Now look at which numbers are perfect squares on this clock, that is, which are the result of squaring something. Exactly half of the nonzero values are squares: 1, 2, 3, 4, 6, 8, 9, 12, 13, 16 and 18. There is a fast test for squareness, known since Euler, that anyone can run on a public value. And a power of the generator 5 is a square exactly when the exponent is even. Alice's public value 8 is a square, so anyone can see that her private number is even. Bob's 19 is not, so his private number is odd. Each public value leaks one bit of its private number.

That leak does not reveal the shared secret directly, but it does break the decisional problem: an observer can predict whether the shared secret is a square, because it is a square unless both private numbers are odd, and can therefore tell the real secret from a random value more often than chance. For a protocol whose security proof assumes the shared secret looks random, that is a real failure, even though the discrete logarithm is as hard as ever.

The leak comes from the structure of the group. The full group on the 23-clock has 22 elements, and 22 factors as 2 times 11. Any factor of the group size gives a subgroup and a small piece of information that can leak. The standard cure is to work only inside a subgroup whose size is a large prime. On the 23-clock, the generator 2 produces exactly 11 values before repeating: 2, 4, 8, 16, 9, 18, 13, 3, 6, 12 and 1. Every one of them is a square, so the squareness test reveals nothing. With Alice keeping 6 and Bob keeping 9, they publish 18 and 6 and share 12.

The subgroups inside the 23-clock, and what each size means for an exchange.
Subgroup sizeExample elementWhat it means
11A fixed point; the shared secret would always be 1
222Only 1 or 22; reveals one bit of a private number
112Large prime size; the safe place to work
225The whole group; leaks squareness

Choosing the group: safe primes and named parameters

The 23-clock is a safe prime in miniature. A safe prime is a prime p for which p minus 1, divided by 2, is also prime. Then the group has only four subgroup sizes, 1, 2, a large prime q and twice that prime, and working in the subgroup of size q avoids both the squareness leak and the small subgroups. Real safe primes are at least 2,048 bits long, so q is about 2,047 bits.

Generating good parameters is slow and easy to get subtly wrong, and a party that accepts parameters chosen by the other side has to verify them, which is slower still. So modern practice is to use named groups: fixed, published safe primes that everyone agrees on. Request for Comments (RFC) 7919 defines finite-field groups for Transport Layer Security (TLS), named ffdhe2048 through ffdhe8192, and TLS version 1.3 only allows named groups. Custom or server-chosen groups were one of the routes by which weak parameters reached production.

Named groups bring one consideration of their own, which the next section explains: when millions of servers share the same prime, any work an attacker does that depends only on the prime is shared too.

Precomputation: why sharing a prime has a price

The best known classical method for computing discrete logarithms in these groups is the number field sieve. Its costly part depends only on the prime p, not on any particular exchange. An attacker can run that precomputation once for a given prime and then, in a much shorter descent step, solve individual discrete logarithms for any exchange that uses that prime.

In 2015 a team of researchers presented the Logjam attack and its accompanying analysis, Imperfect Forward Secrecy. They showed that many servers still supported deliberately weakened 512-bit export groups, a leftover from 1990s export rules, that an active attacker could trick some connections into using them, and that the precomputation for a 512-bit prime was within reach of academic resources. They also observed that a large share of servers used a small number of common 1,024-bit primes, and estimated that precomputation for one such prime, while far beyond academic budgets, could be within reach of a nation-state, after which a large volume of traffic would become readable.

The lesson is not that named groups are dangerous. It is that a group's size has to be judged against an attacker who can amortise work across everyone who uses it. That is why 1,024-bit groups were retired, why 2,048 bits is today's minimum for finite-field Diffie-Hellman, and why many systems have moved to elliptic-curve Diffie-Hellman, where no comparable shared-precomputation shortcut is known.

The expensive stage depends only on the prime, so one precomputation is reused against every exchange that shares that prime. Number field sieve economics Pick a popular primeshared by many servers Precompute oncevery costly, depends on the prime only Descent per exchangecomparatively quick Read many sessionssame prime, same table target reusable table repeat
The expensive stage depends only on the prime, so one precomputation is reused against every exchange that shares that prime.

The peer is part of the security

Diffie-Hellman's arithmetic assumes that the value the other side sends is a legitimate member of the right subgroup. Nothing forces an attacker to send one. Suppose Alice keeps the same private number across many exchanges, which some protocols and many embedded devices do, and an attacker sends her the value 22 instead of a real public value. Because 22 belongs to the subgroup of size 2, Alice's shared secret becomes either 1 or 22, depending only on whether her private number is even or odd. If the attacker can see anything Alice does with that secret, such as a message she encrypts or a confirmation she sends, they can test both possibilities and learn one bit of her private key.

This is called a small-subgroup attack. In a group whose size has many small factors, an attacker can repeat the trick with values from several small subgroups, learn the private number modulo each small size, and combine the pieces with the Chinese remainder theorem until the whole private number falls out. Degenerate values are even simpler: sending 1 forces the shared secret to 1, and sending 0 or p minus 1 has similar effects in careless code.

The defence is public-key validation, and it is cheap. A receiver checks that the value lies strictly between 1 and p minus 1, and, for full validation as described in the National Institute of Standards and Technology (NIST) Special Publication 800-56A, that raising it to the subgroup size q returns 1, which proves it lies in the prime-order subgroup. Using fresh private numbers for every exchange also limits the damage, because a leaked bit of a key used once is worth almost nothing.

An attacker sends a value from the size-2 subgroup; Alice's secret then depends only on her key's parity, which the attacker can test. A small-subgroup probe Attackerchooses the value Alicereuses her private key 1. sends 22 as its public value 2. 22 to her key: 1 if even, 22 if odd 3. uses secret 1 or 22 4. tests both: learns the parity Repeat with other small subgroups to learn more of a reused key
An attacker sends a value from the size-2 subgroup; Alice's secret then depends only on her key's parity, which the attacker can test.
⚠️
Validate before you compute. Reject any peer value outside 2 to p minus 2, and confirm subgroup membership before using it, especially when private keys are reused.

Binding the exchange to an identity and a transcript

Even a perfectly validated exchange only proves that both sides computed the same secret, not who the other side is. An attacker in the middle can run one exchange with Alice and another with Bob and relay between them. The standard fix is to authenticate the exchange: one or both sides sign the values exchanged with a long-term signing key that a certificate or a pinned key ties to an identity.

What gets signed matters as much as whether anything is. Logjam's downgrade worked against older TLS because the server's signature did not cover the client's request for which kind of group to use, so an attacker could alter the negotiation and the signature still checked out. TLS 1.3 signs a hash of the entire handshake transcript, every message from the first hello onward, so changing any negotiated parameter makes the signature fail. The general rule is that the signature must cover the group choice, both public values and the identities, so nothing about the exchange can be swapped without detection.

Erasure, reuse and forward secrecy

The last dependency is time. If both private numbers are generated fresh for one connection and erased as soon as the session keys are derived, then stealing a server's long-term signing key later cannot decrypt recorded traffic, because the numbers needed to recompute the shared secret no longer exist. This property is called forward secrecy, and the 'E' in the cipher-suite name DHE stands for exactly this ephemeral use.

Implementations sometimes trade it away for speed by reusing a private number across many connections for minutes or hours. That widens the window in which a single memory leak exposes many sessions, and it makes small-subgroup and timing attacks more valuable. The Raccoon attack, published in 2020, showed how TLS 1.2's handling of leading zero bytes in a reused Diffie-Hellman secret could create a timing side channel. Session resumption mechanisms can also keep derived keys alive longer than the connection, quietly extending exposure.

The shared secret should never be used directly as a key. It goes through a key derivation function, such as the HMAC-based Extract-and-Expand Key Derivation Function (HKDF), together with the transcript, producing separate keys for each direction and purpose.

Decisions for practitioners and AI agents

The practical checklist follows the four dependencies. Use only named groups of at least 2,048 bits, or prefer elliptic-curve Diffie-Hellman; never accept custom parameters from a peer. Validate every received public value, with range and subgroup checks, inside a mature library. Authenticate the full transcript, not just a public value. Generate fresh private numbers per connection, erase them promptly and derive keys through HKDF.

For AI agents these are not abstract. Every call an agent makes to a tool server, a model endpoint or another agent starts with a key agreement whose safety depends on the library and its configuration, not on the agent's prompt. Platform teams should enforce TLS 1.3 on agent egress, disable finite-field suites with custom groups on any internal tool servers that still offer them, and treat certificate verification as non-negotiable, because an agent talking privately to the wrong party will faithfully act on false tool results. Code assistants that are asked to 'add a secure handshake' may produce a hand-rolled exchange with a hard-coded prime and no validation; that code will interoperate in testing and fail every check in this article.

Thinking of these defences as layers makes gaps visible: if any one layer is missing, the exchange can be undermined without touching the hard problem at all.

Each layer closes a different failure; missing any one lets an attacker bypass the hard problem entirely. Four layers around the exchange Group choicenamed, prime-order, 2,048+ bits Peer validationrange and subgroup checks Transcript signaturebinds identity and parameters Fresh keys, erasedforward secrecy via HKDF weak group bad peer value impostor later key theft Logjam small subgroup downgrade recorded traffic
Each layer closes a different failure; missing any one lets an attacker bypass the hard problem entirely.
  • Named groups only, 2,048 bits or more, or elliptic-curve Diffie-Hellman.
  • Validate every peer value: range, then subgroup membership.
  • Sign the whole transcript, including the group choice.
  • Fresh private numbers per connection, erased after HKDF.
  • Enforce TLS 1.3 and certificate checks on all agent traffic.

Key takeaways

  • Diffie-Hellman rests on three separate problems: discrete logarithm, computational and decisional Diffie-Hellman, and protocols usually need the strongest, decisional one.
  • In the full group modulo a prime, every public value leaks whether its private number is even, which breaks the decisional assumption; prime-order subgroups fix it.
  • Safe primes and named groups of at least 2,048 bits avoid weak structure, but shared primes invite precomputation, as the Logjam research showed for 512- and 1,024-bit groups.
  • A peer can send values from small subgroups to extract key bits, so every received public value must pass range and subgroup checks.
  • Signing the entire transcript prevents downgrades and impersonation, and fresh, erased private numbers give forward secrecy.
  • For AI agents, safety comes from enforced TLS 1.3, validated libraries and certificate checks, never from hand-rolled exchanges.

Glossary

Discrete logarithm problem
Given a generator and one of its powers on a clock, find the exponent that produced it.
Computational Diffie-Hellman
Given two public values, compute the shared secret without necessarily finding either private number.
Decisional Diffie-Hellman
Given two public values and a candidate, decide whether the candidate is the real shared secret or random.
Subgroup
A smaller set of values inside a group that is closed under multiplication, whose size divides the group size.
Safe prime
A prime p for which (p minus 1) divided by 2 is also prime, leaving only tiny subgroups besides one large one.
Number field sieve
The fastest known classical method for factoring and finite-field discrete logarithms, with a large reusable precomputation.
Small-subgroup attack
Sending public values from small subgroups to learn a reused private key piece by piece.
Forward secrecy
The property that stealing long-term keys later cannot decrypt traffic recorded earlier.
HKDF
The HMAC-based Extract-and-Expand Key Derivation Function, which turns a shared secret into separate working keys.

Further reading

  1. Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice (D. Adrian et al., ACM CCS 2015)
  2. RFC 7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS (IETF)
  3. SP 800-56A Rev. 3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography (NIST)
  4. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (IETF)