DH Parameter Injection — tamper with (p, g) themselves to make the exchange breakable

If the handshake transmits the group parameters (p, g) themselves — not just the public values A/B — without integrity protection, an attacker who can tamper with the wire can swap them for weak ones (a smooth or composite p, a small-order g, or a degenerate public value) so the resulting discrete-log problem collapses to something trivial.

The signal that gives it away

- The parameters p and/or g are inputs, not hard-coded constants: a challenge server accepts client-supplied group parameters, a "bring your own group" handshake, or a proxy/relay where you control one leg of the wire. - No parameter validation step is visible: the target never checks that p is prime, that p-1 has a large prime factor, that g has large order, or that the received public value is in a sane range. - Framing language like "send your own group", "custom DH parameters", or a challenge that explicitly asks you to *make* the exchange breakable rather than just eavesdrop on it — that's the tell this is parameter injection, not DH Man-in-the-Middle — unauthenticated exchange lets an active attacker relay two separate keys (which tampers with the public keys A/B on an otherwise honest group).

How to exploit it

Three concrete injections, in increasing order of how much of the protocol you control:

1. Inject a smooth prime `p`. Build (or find) a prime where p - 1 factors into small primes only. The DLP in a group of smooth order is easy: recover any exponent with Pohlig-Hellman — solving the discrete log when the group order is smooth (solve mod each small prime-power factor, CRT-recombine), instead of attacking a hard prime-order subgroup.

``python p_evil = build_smooth_prime() # p-1 = product of small primes, e.g. via # multiplying small primes together and # testing p = product + 1 for primality ``

2. Inject a `g` of small order. Even with a legitimate large prime p, if you control g you can pick an element whose order is a small divisor of p-1. The shared secret is then confined to a tiny subgroup — recover the exponent modulo that small order directly (see DH Small-Subgroup Attack — confining the secret to a tiny subgroup to leak it mod that order for the confine-and-brute-force mechanics).

``python g_evil = element_of_small_order(p) # find q | p-1 small, set g = h^((p-1)/q) ``

3. Inject a degenerate public value. If you can also touch the public value (not just the group), the cheapest win of all:

``python A_evil = 1 # shared secret = 1^b = 1, regardless of the other side's secret b A_evil = p - 1 # A_evil ≡ -1 mod p, so shared secret = (-1)^b = +1 or -1 ``

No factoring, no subgroup arithmetic — the shared secret is a known constant before any exponentiation happens on the other side.

Which sub-attack you reach for depends entirely on what you're allowed to tamper with: full (p, g) control routes to (1) or (2), public-value-only control routes to (3) or to DH Man-in-the-Middle — unauthenticated exchange lets an active attacker relay two separate keys's degenerate-value variant. Defenders close this by validating what they receive: confirm p is a safe prime (p = 2q + 1 for prime q), which guarantees the only elements of small order are 1 and p - 1 themselves; and bound-check every public value with 1 < A < p - 1 (NIST SP 800-56A phrases this as 2 ≤ y ≤ p - 2, plus checking the *shared secret itself* is ≠ 1 after computing it — a defense-in-depth catch for exactly the A_evil = 1 case). A challenge server missing any of these checks is your opening.

What does NOT work

- Assuming any visible parameter-validation code means you're safe from this. Naive checks (e.g. "is p prime", "is 1 < A < p") do not by themselves catch a *maliciously crafted* prime that passes primality testing yet has smooth or otherwise weak subgroup structure baked in — published work has constructed 1024-bit finite-field parameters that pass OpenSSL's own DH validation while still being solvable at ~2^64 effort. Don't stop at "does it look like it validates" — check what it actually validates (primality alone is not enough; it needs to rule out smooth p-1 and small-order g specifically). - Injecting a smooth `p` when the target hard-codes standard/well-known groups (RFC 3526 MODP groups, NIST curves' analogues, etc.) and only accepts *public values* over the wire. If p and g are never transmitted, there is nothing to inject — you're in DH Man-in-the-Middle — unauthenticated exchange lets an active attacker relay two separate keys or DH Small-Subgroup Attack — confining the secret to a tiny subgroup to leak it mod that order territory instead (tamper with A/B, or exploit a peer-supplied low-order value), not this attack. - Expecting the trivial `A_evil = 1` / `p - 1` shortcut to survive a spec-following implementation. Any endpoint that bound-checks the public value (1 < A < p-1) or checks the computed shared secret against 1 rejects this instantly — you fall back to the smooth-p or small-order-g routes, which require you to actually control the group parameters, not just the public value. - Forgetting that a composite (non-prime) `p` is a different, stronger primitive than a smooth prime `p`. A smooth *prime* still requires Pohlig-Hellman per factor; a composite modulus splits the problem by CRT into independent, often much easier subproblems — that's DH Composite Modulus — splitting the discrete log by CRT when the modulus isn't prime, a distinct and more powerful injection if the target never even checks primality.

Related

DH Man-in-the-Middle — unauthenticated exchange lets an active attacker relay two separate keys Pohlig-Hellman — solving the discrete log when the group order is smooth DH Small-Subgroup Attack — confining the secret to a tiny subgroup to leak it mod that order DH Composite Modulus — splitting the discrete log by CRT when the modulus isn't prime Key-Exchange Methodology — triage any DH/ECDH challenge before reaching for heavy DLP machinery Diffie-Hellman Fundamentals — what to audit first in any DH challenge