DH Man-in-the-Middle — unauthenticated exchange lets an active attacker relay two separate keys

Textbook (unauthenticated) Diffie-Hellman verifies no party's identity, so an active attacker sitting on the wire can run two independent exchanges — one with each victim — and transparently decrypt-and-re-encrypt everything passing between them.

The signal that betrays it

Look for an active position plus no authentication step, not just "DH is used somewhere":

- The challenge hands you (or a proxy/relay service) control over traffic between the two DH parties — you can intercept, substitute, or replay the public values in transit. Framing like "intercept the channel," "you are the relay," or a man-in-the-middle proxy harness is the tell. - DH runs with no signatures, certificates, or pre-shared authentication binding a public value to an identity. If the protocol never asks "is this really Bob's key," it's exploitable this way regardless of how strong p and g otherwise are. - Both endpoints are independently reachable from your position (you can send to Bob *and* to Alice), which is what lets you complete two separate exchanges instead of just eavesdropping on one. - A cheaper variant of the same signal: the challenge lets you (or the relay) inject the *public value itself* — watch for whether it's ever checked against 0, 1, or p-1 before use.

How to exploit it

General MITM — substitute your own exponent toward each side. You don't need to break the DLP at all; you just run DH twice, once per victim, with yourself as the counterparty each time:

``python e = random_exponent() E = pow(g, e, p) send_to_bob(E) # impersonate Alice send_to_alice(E) # impersonate Bob sA = pow(A, e, p) # shared secret with Alice (A = Alice's real public value) sB = pow(B, e, p) # shared secret with Bob (B = Bob's real public value) # derive session keys from sA and sB, decrypt with one, re-encrypt with the other ` Alice thinks she shares a secret with Bob; she actually shares sA with you. Bob thinks he shares a secret with Alice; he actually shares sB` with you. Every message you relay gets decrypted under one key and re-encrypted under the other — full read/write access, both directions, without ever solving a discrete log.

Degenerate-value shortcut — no key juggling required. If you can inject the public value directly (rather than running a full relay), forcing it to 0, 1, or p-1 collapses the shared secret to a *known constant* for any exponent on the other side:

- Public value 0 → shared secret 0^b mod p = 0. - Public value 1 → shared secret 1^b mod p = 1. - Public value p-1 (i.e. -1 mod p) → shared secret is +1 or -1 mod p, depending only on the parity of the other party's private exponent — check both.

This is strictly cheaper than the full active-relay dance: no session bookkeeping, no live proxy, just substitute the degenerate value and derive the session key from the known constant. Always test these three values first when you have any ability to tamper with a transmitted public key, even if the challenge doesn't look like a "relay" scenario on the surface.

Related building blocks

the degenerate-value shortcut and DH Small-Subgroup Attack — confining the secret to a tiny subgroup to leak it mod that order are different attacks that happen to share a root cause — neither side validates the incoming public value before using it — but they exploit that gap in different ways. The degenerate-value shortcut forces the public value itself (0, 1, or p-1) so the shared secret collapses to a known constant directly; the small-subgroup attack instead sends a public value of small order and uses Pohlig-Hellman to brute-force the *other* party's private exponent modulo that small order, then CRT-combines several such residues to recover it. One hands you the session key outright, the other extracts bits of a private key you still have to reassemble. Start any DH challenge from Diffie-Hellman Fundamentals — what to audit first in any DH challenge and the triage in Key-Exchange Methodology — triage any DH/ECDH challenge before reaching for heavy DLP machinery before committing to the full MITM relay.

What does NOT work

- Trying this against authenticated DH (signed public values, certificate-bound exchange, or a pre-shared MAC over the exchange transcript). If either side verifies the other's identity or the exchange transcript before deriving keys, substituting your own value is detected, not silently accepted — the fix for MITM *is* authentication, and once it's present this whole technique is closed. - Skipping validation checks on your own end if you're auditing rather than attacking: checking for 0/1/p-1 after the fact doesn't help — the defense has to reject those values (and any other public value outside the expected subgroup) *before* deriving the shared secret, not just refuse to use a secret of 0 or 1 once computed. - Confusing this with tampering the group parameters. Forcing a degenerate *public value* (this technique) is a different move from forcing a smooth p or a small-order g (that's DH Parameter Injection — tamper with (p, g) themselves to make the exchange breakable) — the former needs only write-access to the exchanged keys in transit, the latter needs write-access to p/g themselves, earlier in the protocol. Don't reach for a full parameter-injection setup when the simpler degenerate-value substitution is already sitting there. - Assuming you need to solve the discrete log at all. The whole point of both the full relay and the degenerate-value shortcut is that you never touch the hard DLP; if a writeup for a DH challenge starts computing discrete logs, that's a sign it's not actually a MITM-shaped challenge, or that the intended path is elsewhere (e.g. DH Static-Key Reuse — turning a persistent secret exponent into a leaking oracle or DH Small-Subgroup Attack — confining the secret to a tiny subgroup to leak it mod that order against a genuinely validated modulus).

Related

DH Parameter Injection — tamper with (p, g) themselves to make the exchange breakable Diffie-Hellman Fundamentals — what to audit first in any DH challenge DH Static-Key Reuse — turning a persistent secret exponent into a leaking oracle DH Small-Subgroup Attack — confining the secret to a tiny subgroup to leak it mod that order Key-Exchange Methodology — triage any DH/ECDH challenge before reaching for heavy DLP machinery