Additive Group Diffie-Hellman Break (Trivial Discrete Log in Additive Groups)
- •
What it is
- •
Diffie-Hellman's security depends specifically on the multiplicative group of a finite field (or another genuinely hard group, like a well-chosen elliptic curve) — not on "some abelian group with a repeated operation." If the "exponentiation" step is instead implemented as repeated addition (i.e. the public/shared values are computed via plain multiplication mod rather than modular exponentiation), the entire scheme collapses: the "discrete log" problem in an additive group is just ordinary division, trivially invertible using a modular inverse — no hardness at all.
- •
- •
When to apply
- •
A DH-flavored protocol computes public/shared values via a single modular multiplication () rather than modular exponentiation () — a direct tell that the "group operation" is addition, not multiplication, however the values are labeled.
- •
- •
Math
- •
(an ordinary modular inverse, computable via Fermat/extended Euclid); shared secret once is recovered.
- •
- •
Worked example
- •
Recovering from a real 2048-bit-class DH-style exchange that used multiplication instead of exponentiation — computing and then — reproduced the exact true shared secret both parties would have derived.
- •
- •
Python
- •
g_inv = pow(g, -1, p) a = (A * g_inv) % p # trivial "discrete log" -- just division shared_secret = (B * a) % p
- •
- •
- •
Cards
- •
Why does using addition instead of exponentiation completely break Diffie-Hellman's security?
- •
"Discrete log" in an additive group is just ordinary division — trivially solvable via a modular inverse, with no exponential hardness at all.
- •
- •
What's the tell in a protocol's computation that it's secretly using an additive rather than multiplicative group?
- •
Public/shared values computed via a single modular multiplication (A = g×a mod p) rather than modular exponentiation (A = g^a mod p).
- •
- •