Shared DH Group, Fresh Secrets: Why the Attack Gets Cheaper

Group parameters are public by design, and that publicness is exactly what makes them easy to ignore. In finite-field Diffie-Hellman the modulus and generator are shared, while the private exponents and the resulting session keys are not. The expensive stage of a number-field-sieve attack depends on the group rather than on one exchange, so a single weak group used everywhere becomes a shared liability. Calling the parameters public is accurate and beside the point, because the cost that gets reused is the cost of attacking that group.

The public half is not the vulnerable half, and that is the trap

The usual half-argument says the parameters are published in a standard, so an attacker already knows them and hiding them would change nothing. Both clauses are true, and neither one follows from the other. A shipped default group is public, and a private group you generated last week is also visible to anyone who completes the handshake. Secrecy was never the control; strength and validation are.

What does change is how many places share the same weakness. One organisation generating its own 2048-bit group pays for its own attack cost, while a protocol default chosen by millions gets one cost amortised across all of them. That is the sense in which an uncommon group is not automatically better. An unusual group that is too small is simply a smaller shared secret with fewer eyes on it.

Validation matters as much as size. A peer that sends a modulus with small factors, or one that is not the shape the protocol expects, can leak information about the private exponent even when the bit length looks respectable. Libraries that reject malformed parameters on the way in are doing real work, which is why hand-rolled parameter parsing is a bad place to save effort.

What the precomputation actually buys an attacker

The number-field sieve has a stage that depends only on the prime, and its output is reusable against every exchange that uses that prime. That is the whole mechanism behind the historical concern: the expensive part is paid once, and the marginal cost of each further session drops. Fresh exponents still protect each individual exchange from a passive observer, as long as the group is large enough to make the sieving infeasible. The two statements are compatible, and most arguments on this topic come from picking one and dropping the other.

The 2015 Logjam paper demonstrated a downgrade to 512-bit export-grade Diffie-Hellman and estimated what larger, widely reused groups would cost to attack with significant resources. The demonstration was concrete, the estimates were estimates, and neither was evidence that a particular VPN session had been decrypted.

Cite the paper for the mechanism and for the demonstrated downgrade, not as a measurement of your deployment. Old statistics about how many servers shared a default group describe the internet of that year, not a network you can inspect today. The useful carry-over is the question, which is whether your devices still negotiate a group that is small or weakly validated.

Standardised is not the same as weak

RFC 7919 defines named finite-field groups so that both ends agree on a group by identifier and apply a consistent policy. Being standardised is a feature, because it removes negotiation ambiguity and lets an implementation refuse unsupported sizes. A named group is weak only when its size sits below the policy you claim to follow, not because it appears in a document. The same logic applies to elliptic-curve groups, which have a different structure and different failure modes.

Keep constructions apart when you reason about them. A conclusion about finite-field Diffie-Hellman says nothing about X25519, and a conclusion about a 1024-bit MODP group says nothing about a 3072-bit one. Strength policy is per mechanism, per size and per protocol version, which is why the phrase strong crypto is not a reviewable statement.

Authentication is the other half, and it does not substitute. A strong group with no peer verification leaves an attacker in the middle, and a valid certificate cannot rescue a 768-bit exchange. Review them as two independent lines, then confirm that both are actually negotiated.

Read the negotiated group on a real connection

Read the negotiated group from the device rather than from the configuration template. Templates describe intent, and the interesting value is the one both peers agreed on during the last handshake. On an IPsec endpoint the status output usually prints the selected proposal, including the MODP group.

Capture that line before and after a policy change, and keep both in the change record. The comparison is the evidence.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

If the status still shows the old group after the change, the connection did not renegotiate and the configuration edit proved nothing. Restart the peer or clear the security association, then read the status again. A policy enforced only on new connections will leave long-lived tunnels on the old parameters for as long as they stay up.

Check the group and the peer identity separately

Separate what the group protects from who is on the other end. Record the key-exchange method, the group size and the authentication method as three fields, because they fail independently. A tunnel that negotiated a 3072-bit group but accepts any certificate is not the same risk as one that pins a peer and uses a 2048-bit group.

Write the acceptance criteria down before the review starts, so the result is a comparison rather than an opinion. A minimum group size per protocol version, a named-group allow list and mandatory peer verification are enough to make the decision mechanical. Ambiguity in that list is what turns a review into an argument, and arguments do not get remediated. Then the output is a list of endpoints that fail a stated rule.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Close the loop by re-reading the negotiated values after remediation. A compliant configuration file is not evidence that a tunnel picked it up. The status output and one fresh handshake are the evidence, and collecting them takes less time than the meeting about whether they are needed.