Introduction
Two parties who have never met need to agree on a shared secret over a channel that an eavesdropper is monitoring. That is the problem Diffie and Hellman solved in 1976, and it changed cryptography forever. This tool simulates the exchange live: pick a prime and generator (or use the default RFC 3526 MODP-2048 group), choose private exponents for Alice and Bob, and watch both sides compute the same shared secret without ever transmitting it. An eavesdropper sees g, p, g^a, and g^b but cannot recover the shared secret without solving the discrete logarithm problem. The tool also supports ECDH on NIST P-256, P-384, and P-521 curves via the Web Crypto API.
What this tool does
- Simulate classical Diffie-Hellman key exchange with a configurable prime modulus p, generator g, and optional private exponents a and b for Alice and Bob, using BigInt arithmetic
- Default to the RFC 3526 MODP Group 14 safe prime (2048-bit) with generator g = 2, or paste your own prime and generator
- Verify that p is prime using the Miller-Rabin test before running the exchange, and display the result as a badge
- Compute and display Alice's public value A = g^a mod p, Bob's public value B = g^b mod p, and both shared secrets, confirming they match
- Support ECDH (elliptic curve Diffie-Hellman) on NIST P-256, P-384, or P-521 using the Web Crypto API, with PEM-formatted public keys and hex shared secrets
- Generate random private exponents in [2, p-2] if you do not provide your own, using cryptographically secure random values
How this tool works
In classical mode, the tool takes a prime p, a generator g, and optional private exponents a and b. If you leave a or b blank, the tool generates a cryptographically secure random value in [2, p-2] using `crypto.getRandomValues`. Before running the exchange, it checks that p is prime with 12 rounds of Miller-Rabin. If p is composite, it shows an error and refuses to proceed.
The exchange itself is four modular exponentiations using BigInt. Alice computes A = g^a mod p and sends A to Bob. Bob computes B = g^b mod p and sends B to Alice. Alice computes her shared secret s = B^a mod p. Bob computes his shared secret s = A^b mod p. Both equal g^(a*b) mod p by the rules of modular arithmetic, and the tool displays both values side by side with a badge confirming they match.
In ECDH mode, the tool calls `crypto.subtle.generateKey` with the `ECDH` algorithm and the selected NIST curve (P-256, P-384, or P-521). It generates two key pairs (Alice and Bob), exports both public keys to SPKI/PEM format, then calls `crypto.subtle.deriveBits` to compute each party's shared secret. Alice derives bits using Bob's public key and her private key; Bob does the same with Alice's public key. The resulting shared secrets are displayed as hex and verified to match.
The tool shows a clear explanation below the results: in classical DH, an eavesdropper seeing g, p, g^a, and g^b cannot recover g^(ab) without solving the discrete logarithm problem. In ECDH, the same holds for the elliptic curve discrete logarithm problem, which is harder for equivalent key sizes.
How Diffie-Hellman works (Diffie-Hellman 1976)
Diffie-Hellman was published by Whitfield Diffie and Martin Hellman in their 1976 paper New Directions in Cryptography. Ralph Merkle independently developed the same concept around the same time (the Merkle puzzle). The protocol was the first to show that two parties with no prior shared secret could establish one over a public channel, an idea that underpins TLS, SSH, VPNs, and Signal's double ratchet.
The security rests on the discrete logarithm problem (DLP): given a prime p, a generator g, and a value y = g^x mod p, finding x is believed to be computationally infeasible for large p. Computing g^x mod p is easy (square-and-multiply, O(log x) multiplications). Reversing it is hard. The best known generic algorithm for DLP is baby-step giant-step (Shanks, 1971), which runs in O(sqrt(n)) time and space, where n is the group order. For a 2048-bit prime, that is 2^1024 steps, far beyond any computer.
For finite-field DH, the parameters must be chosen carefully. The prime p should be a safe prime (p = 2q + 1 where q is also prime), and g should be a generator of a large subgroup. Using a small subgroup allows small-subgroup attacks that leak bits of the private exponent. RFC 7919 defines named DH groups for TLS that avoid these pitfalls. The tool defaults to the RFC 3526 MODP-2048 group, a well-studied safe prime.
ECDH replaces the multiplicative group of integers mod p with the group of points on an elliptic curve. The discrete logarithm problem on elliptic curves has no known sub-exponential algorithm (unlike finite-field DLP, which has the number field sieve). This means a 256-bit elliptic curve provides the same security as a 3072-bit RSA key. NIST P-256 (secp256r1) is the most common curve in TLS 1.3, X.509 certificates, and Apple's Secure Enclave.
Unauthenticated DH is vulnerable to man-in-the-middle attacks: an attacker can intercept both public values and establish separate shared secrets with each party. Real protocols authenticate the exchange with digital signatures (as in TLS 1.3 with X25519) or pre-shared keys. See the ECDSA Signature Tool for how signatures provide that authentication.
How to use this tool
- Choose a variant: Classical DH (mod p) for the textbook integer-based exchange, or ECDH for elliptic curve key agreement
- For classical DH, the prime p defaults to the RFC 3526 MODP-2048 safe prime and g defaults to 2. You can paste your own values if you want to experiment with a different group
- Optionally enter private exponents for Alice (a) and Bob (b). If left blank, the tool generates random values in [2, p-2] using crypto.getRandomValues
- For ECDH, select a curve: P-256 (most common, TLS 1.3), P-384, or P-521 (highest security)
- Click Run exchange. The tool computes both public values and both shared secrets
- Verify that the shared secrets match. The badge turns green if Alice's and Bob's computed secrets are identical, red if they differ (which would indicate a parameter error)
- Copy either shared secret to use as a symmetric key. In practice, you would feed this into a KDF (like HKDF) before using it as an AES key
Real-world examples
Textbook DH with small numbers
Set p = 23, g = 5, a = 6, b = 15. Alice computes A = 5^6 mod 23 = 8. Bob computes B = 5^15 mod 23 = 19. Alice's shared secret: 19^6 mod 23 = 2. Bob's shared secret: 8^15 mod 23 = 2. Both match. An eavesdropper sees 5, 23, 8, and 19 but must solve 5^x = 8 mod 23 (the discrete log) to find a = 6. With p = 23 this is trivial, but with a 2048-bit prime it is infeasible.
Running the default RFC 3526 MODP-2048 group
Leave the default prime (2048-bit safe prime from RFC 3526) and generator g = 2. Leave private exponents blank so the tool generates random ones. Click Run exchange. The tool verifies p is prime via Miller-Rabin, generates random a and b, and computes A = g^a mod p and B = g^b mod p (each a 2048-bit number displayed in decimal). Both shared secrets match and are also 2048-bit numbers. This is the same group used in TLS 1.2 with DHE-RSA cipher suites.
ECDH on P-256
Switch to ECDH mode and select P-256. Click Run exchange. The tool generates two EC key pairs via the Web Crypto API, displays both public keys in PEM format (65 bytes uncompressed point, base64-encoded), and derives the shared secret as 32 bytes of hex. Both parties get the same 32-byte secret. This is exactly what happens in a TLS 1.3 handshake when the server selects the secp256r1 key exchange group.
Why p must be prime
Set p to a composite number like 21 and g = 2. The tool runs Miller-Rabin, detects that 21 is not prime, and shows an error: DH requires a prime modulus. If p were composite, the group structure would be different, and small-subgroup attacks could leak the private exponent. This is why real DH groups use safe primes (p = 2q + 1) verified by primality testing.
Man-in-the-middle vulnerability
Run the exchange and note that the tool does not authenticate either party. An attacker who intercepts Alice's public value A and sends their own A' to Bob can establish a separate shared secret with each party. Neither Alice nor Bob would notice. This is why real protocols sign the DH exchange with a private key (as in TLS, where the server signs its ephemeral DH public value with its RSA or ECDSA certificate key). See the ECDSA Signature Tool for how this works.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Classical DH (MODP-2048) | 2048-bit prime, DLP hardness | TLS 1.2 DHE cipher suites, legacy VPNs |
| ECDH P-256 | 256-bit curve, ECDLP hardness | TLS 1.3, Signal, Apple Secure Enclave |
| ECDH P-384 | 384-bit curve, ~192-bit security | High-assurance TLS, government systems |
| ECDH P-521 | 521-bit curve, ~256-bit security | Highest security, rare in practice |
| X25519 (Curve25519) | 255-bit Montgomery curve | TLS 1.3 default, WireGuard, SSH (not in this tool) |
| RSA key transport | 2048+ bit modulus, factoring hardness | TLS 1.2 RSA key exchange (deprecated in 1.3) |
Limitations or considerations
Unauthenticated Diffie-Hellman is vulnerable to man-in-the-middle attacks. The tool does not sign the exchange or verify either party's identity. An attacker positioned between Alice and Bob can replace their public values with their own and establish two separate shared secrets. Real protocols solve this by signing the ephemeral DH public value with a long-term private key (TLS 1.3) or by using a pre-shared key. See the ECDSA Signature Tool for how signatures authenticate key exchanges.
The classical DH mode uses BigInt arithmetic, which is slower than native big-integer libraries. With the default 2048-bit prime, the exchange completes in under a second, but pasting a very large prime (4096+ bits) will take noticeably longer. The Miller-Rabin primality check on a 2048-bit prime takes a few hundred milliseconds.
The tool does not implement authenticated key exchange (AKE) or forward secrecy protocols like Signal's double ratchet. It shows the core DH computation only. For a production key exchange, use a library that implements the full protocol with transcript hashing, signature verification, and key derivation (HKDF).
The tool does not support X25519 or X448, the Montgomery curves recommended for TLS 1.3. The Web Crypto API does not expose these curves. For X25519, use libsodium or the `@noble/curves` library. The ECDH mode here covers NIST curves only (P-256, P-384, P-521).
Frequently asked questions
What is the discrete logarithm problem and why does it matter for DH?
Given a prime p, a generator g, and a value y = g^x mod p, the discrete logarithm problem is finding x. Computing g^x mod p is fast (square-and-multiply), but reversing it is believed hard for large p. DH's security depends on this asymmetry: an eavesdropper sees g, p, g^a, and g^b but cannot compute g^(ab) without solving the DLP. Try the Discrete Logarithm Calculator to see how brute-force DLP works on small groups.
What is the difference between DH and ECDH?
Classical DH operates in the multiplicative group of integers modulo a prime. ECDH operates in the group of points on an elliptic curve. The math is analogous (both use a one-way exponentiation-like operation), but the elliptic curve discrete logarithm problem has no known sub-exponential algorithm, while finite-field DLP has the number field sieve. This means ECDH with a 256-bit key provides the same security as classical DH with a 3072-bit prime, with much smaller keys and faster computation.
Why does the tool check if p is prime?
Diffie-Hellman requires p to be a prime so that the integers modulo p form a field, and the multiplicative group has the right structure. If p is composite, the group may have small subgroups that leak bits of the private exponent through small-subgroup attacks. The tool runs Miller-Rabin with 12 rounds before proceeding. For production, p should be a safe prime (p = 2q + 1 where q is also prime), as the RFC 3526 groups are.
What is a safe prime and why does the default use one?
A safe prime is p = 2q + 1 where q is also prime. The default prime in the tool is from RFC 3526 MODP Group 14, a 2048-bit safe prime. Safe primes ensure that the only subgroups of the multiplicative group mod p are trivial (order 1, 2, q, or 2q), which prevents small-subgroup attacks. Using a non-safe prime requires careful subgroup validation that this tool does not perform.
Can an eavesdropper break DH by seeing both public values?
No, not with classical computers and properly chosen parameters. The eavesdropper sees g, p, A = g^a mod p, and B = g^b mod p. To compute the shared secret g^(ab) mod p, they need either a or b, which requires solving the discrete logarithm problem. With a 2048-bit safe prime, the best known attack (number field sieve) is infeasible. On a quantum computer, Shor's algorithm would break both DLP and ECDLP, which is why NIST is standardizing post-quantum key exchange (ML-KEM).
How is the shared secret used after the exchange?
The raw shared secret (g^(ab) mod p or the ECDH derived bits) is not used directly as an encryption key. It is fed into a key derivation function like HKDF (RFC 5869) to produce one or more symmetric keys, IVs, and MAC keys. This extracts uniform randomness and allows deriving multiple keys from a single exchange. The tool shows the raw shared secret for educational purposes; production code always runs a KDF on it.
Conclusion
Diffie-Hellman is the foundation of modern key agreement, from TLS 1.3 to Signal to WireGuard. This tool shows both the classical integer-based exchange and elliptic curve ECDH, with the shared secret computed and verified live. To understand the hardness assumption that protects DH, try the Discrete Logarithm Calculator and the Baby-Step Giant-Step Demo. For signing DH exchanges to prevent man-in-the-middle attacks, see the ECDSA Signature Tool. For the asymmetric encryption counterpart, see the RSA Encrypt / Decrypt tool.