Diffie-Hellman Key Exchange Simulator
Simulate a Diffie-Hellman key exchange between Alice and Bob: pick a standard 1024, 2048 or 3072-bit group or your own prime, generate secure private keys and watch both sides arrive at the same shared secret.
100% client-side · Web Crypto API · Nothing is stored or sent
Alice
Bob
Shared secret
Security analysis
An eavesdropper sees only p, g, A and B. This is a learning simulator: never paste a production key here, and use a reviewed library for real systems.
How Diffie-Hellman Works
Diffie-Hellman works because exponentiation commutes: (gb)a = (ga)b mod p. Each side keeps an exponent private and only the results of raising g to those exponents cross the network.
- Agree on public parameters: a prime p and a base g, both known to everyone.
- Choose private keys: Alice picks a and Bob picks b, random numbers they never share.
- Compute public values: Alice computes A = ga mod p and Bob computes B = gb mod p.
- Exchange public values: Alice sends A to Bob and Bob sends B to Alice.
- Compute the shared secret: Alice computes Ba mod p and Bob computes Ab mod p; both equal gab mod p.
- Derive a key: real protocols run the secret through a key derivation function before encrypting anything.
This page does the arithmetic with your browser’s BigInt support and takes its randomness from the Web Crypto API, so the numbers you see are the real ones, not a toy approximation.
Standard Safe-Prime Groups
RFC 2409 and RFC 3526 groups of 1024, 2048 and 3072 bits, each with g = 2
Real Prime Checks
Custom primes are tested with Miller-Rabin, then checked for safe-prime form and for the kind of g
Secure Random Keys
Private keys come from the Web Crypto API, uniform in 2 to p − 2
Both Sides Computed
Alice and Bob each compute the secret from the other’s public value, and the page confirms they match
Honest Strength Estimate
Based on NIST SP 800-57 and limited by the weaker of the group and the private keys
Nothing Stored
Runs in your browser with no network requests and no history
Explore more free tools in our security tools collection, including our strong random password generator.
Frequently Asked Questions
1. What is the Diffie-Hellman key exchange?
Diffie-Hellman lets two parties create a shared secret over a channel that anyone can read. They publicly agree on a prime p and a base g. Alice picks a secret a and sends A = g^a mod p; Bob picks b and sends B = g^b mod p. Alice computes B^a mod p and Bob computes A^b mod p, and both equal g^(ab) mod p. An eavesdropper sees p, g, A and B, but would have to solve the discrete logarithm problem to recover the secret.
2. Is it secure against eavesdroppers and attackers?
Against a passive eavesdropper, yes, as long as the group is large enough. On its own it does not authenticate anyone: an active man-in-the-middle can run one exchange with each side and read everything. Real protocols such as TLS and SSH therefore sign the exchange with a certificate or host key, so each side knows who it is talking to.
3. Which prime size should I use?
Use at least 2048 bits, which gives about 112 bits of security in the NIST SP 800-57 table; 3072 bits gives about 128 bits. 1024-bit groups are legacy: the 2015 Logjam research showed that attackers with large resources can break the most widely shared 1024-bit primes, so do not use them for anything real. For new designs, elliptic-curve Diffie-Hellman (X25519) gives 128-bit security with much smaller keys.
4. Why does this page use safe primes and g = 2?
A safe prime has the form p = 2q + 1 with q also prime, so the group has only tiny subgroups of order 1 and 2 plus one large subgroup of prime order q. For the standard groups on this page (RFC 2409 and RFC 3526), g = 2 generates that large subgroup, which keeps the public values from leaking the parity of the private key and limits small-subgroup attacks. For a custom prime, the page tests that it is prime, tells you whether it is a safe prime, and reports what kind of element your g is.
5. How long should the private keys be?
A private exponent only needs to be about twice the security level you want, because the best generic attack costs roughly the square root of the key space. 256 bits is plenty for the 2048-bit and 3072-bit groups. The Recommended option uses 256 bits for groups of 2048 bits or more and 160 bits for 1024-bit groups. Private keys must come from a cryptographically secure random generator, as the Generate buttons use (the Web Crypto API), never from Math.random or a chosen password.
6. Should I use the shared secret directly as an encryption key?
No. The raw secret is a number with the length of the prime, not uniformly random key bytes. Protocols feed it through a key derivation function such as HKDF, together with the handshake context, before using it to encrypt anything. This page shows the shared secret itself and does not derive a key.
7. Is it safe to use real keys here? Are my keys stored or sent?
Everything runs in your browser, the page's content security policy blocks outgoing network requests, and nothing is saved: there is no history, and the only thing kept in local storage is your language choice. Still, treat this as a learning simulator. Keys generated here have no advantage over keys from a reviewed cryptographic library such as OpenSSL or libsodium, and you should never paste a production key into any web page.
8. How is Diffie-Hellman different from RSA?
Diffie-Hellman only agrees on a shared secret; it does not encrypt or sign anything by itself, while RSA can do both. Their security rests on different hard problems: the discrete logarithm problem for Diffie-Hellman and integer factoring for RSA. Modern protocols use ephemeral Diffie-Hellman or ECDH for forward secrecy, so that a stolen long-term key cannot decrypt past sessions, and use RSA or ECDSA/EdDSA signatures only to authenticate.