Interactive Simulator

Simulate Diffie-Hellman Exchange

Enter parameters, set private keys and compute the shared secret step by step.

DH Parameters
Alice's Private Key (a)
Bob's Private Key (b)
⚠ Production Note

For real applications use 2048-bit+ primes (MODP groups from RFC 3526) or switch to ECDH with Curve25519. Select the MODP-2048 preset above. Never use small primes in production — they are trivially brute-forced.

Computed Key Material
Alice
Public Key A
—
Shared (A's calc)
—
Bob
Public Key B
—
Shared (B's calc)
—
🔒 Shared Secret
—
—
Step-by-Step Walkthrough
1
Public Parameters
Awaiting simulation…
Both parties agree on prime p and generator g (public)
2
Alice Computes Public Key
A = g^a mod p
A = g raised to Alice's private key a, mod p
3
Bob Computes Public Key
B = g^b mod p
B = g raised to Bob's private key b, mod p
4
Exchange Public Keys
Alice sends A → Bob | Bob sends B → Alice
Public keys are sent over an insecure channel
5
Alice Computes Shared Secret
S = B^a mod p
Alice uses Bob's public key B and her private key a
6
Bob Computes Shared Secret
S = A^b mod p
Bob uses Alice's public key A and his private key b
7
Verification
Both secrets must match
Mathematical proof: (g^a)^b ≡ (g^b)^a (mod p)
Export
// Run simulation to see JSON output
Features

Advanced DH Simulator Features

Everything you need to understand and test Diffie-Hellman key exchange.

BigInt Precision

All modular exponentiation uses JavaScript BigInt, enabling accurate computation with large primes including the 2048-bit MODP group from RFC 3526 — same as real TLS implementations.

Step-by-Step Walkthrough

Every computation is broken into 7 labelled steps showing exact formulas and numeric results — perfect for learning, teaching or verifying manual calculations.

DH Parameter Validation

Real-time validation checks that p is a prime, g is a valid generator, private keys are in the valid range, and warns when parameters are too small for production security.

RFC 3526 MODP Groups

Includes the production-safe MODP-2048 group (Group 14) from RFC 3526, the same prime used in OpenSSH, OpenVPN, TLS/SSL and IPsec implementations worldwide.

Shared Secret Verification

Automatically verifies that Alice and Bob independently arrive at the identical shared secret — proving the mathematical correctness of the Diffie-Hellman theorem.

JSON Export

Export the complete DH exchange — parameters, public keys, private keys and shared secret — as a structured JSON object for use in documentation, testing or research.

Process

How Diffie-Hellman Works

Four mathematical steps to establish a shared secret over a public channel.

Agree on Public Params

Both parties publicly agree on a large prime p and a primitive root g. These values are known to everyone including eavesdroppers.

Generate Key Pairs

Alice picks secret a, computes A = ga mod p. Bob picks secret b, computes B = gb mod p. Each sends their public value to the other.

Compute Shared Secret

Alice computes S = Ba mod p. Bob computes S = Ab mod p. The discrete log problem ensures these are equal even though neither knows the other's private key.

Derive Session Key

The shared secret S is hashed (e.g. SHA-256) to derive a symmetric session key for use in AES or ChaCha20 encryption of the actual communication channel.

What is Diffie-Hellman Key Exchange?

The Diffie-Hellman key exchange — published by Whitfield Diffie and Martin Hellman in 1976 — was the first publicly known protocol that solved one of cryptography's hardest problems: how can two parties securely agree on a shared secret when their entire conversation is visible to an adversary? The answer lies in the mathematical hardness of the discrete logarithm problem: computing gx mod p is easy, but reversing it to find x from gx mod p is computationally infeasible for large primes.

The Diffie-Hellman algorithm forms the backbone of modern internet security. It is embedded in every HTTPS connection (as ECDHE in TLS 1.3), every SSH session, OpenVPN tunnels, IPsec VPNs and Signal Protocol end-to-end encryption. The "E" in ECDHE stands for "ephemeral" — a new DH key pair is generated per session, ensuring perfect forward secrecy: compromise of long-term keys does not expose past session data.

A Diffie-Hellman calculator such as this one lets you explore the protocol hands-on — see exactly which values are public, which are secret, and why an eavesdropper who intercepts A and B cannot recover the shared secret without solving the discrete log. For educational purposes, small primes like p=23 make the numbers tractable; in production, 2048-bit safe primes (RFC 3526 MODP groups) or elliptic curves (Curve25519) provide security against even nation-state-level adversaries.

Key use cases include: TLS/HTTPS key exchange, SSH host authentication, encrypted messaging apps, VPN tunnel establishment, blockchain node communication, and IoT device provisioning. Best practices: always use ephemeral keys (DHE/ECDHE) for forward secrecy, authenticate public keys via certificates or pre-shared tokens to prevent MITM attacks, and prefer ECDH with Curve25519 over classic DH for performance and security in new implementations.

FAQ

Frequently Asked Questions

Common questions about Diffie-Hellman key exchange, security and applications.

Diffie-Hellman is a cryptographic protocol that allows two parties to securely agree on a shared secret over a public, insecure channel without any prior secret exchange. It relies on the computational hardness of the discrete logarithm problem — easy to compute one way, infeasible to reverse.
Even though the prime p, generator g, and public keys A and B are all visible to an eavesdropper, recovering the shared secret requires solving the discrete logarithm problem: finding a from g^a mod p. For 2048-bit primes, this is computationally infeasible with today's and foreseeable future hardware.
Perfect Forward Secrecy (PFS) means a new ephemeral DH key pair is generated for every session. If a long-term private key is later compromised, past session traffic encrypted with ephemeral keys cannot be decrypted. TLS 1.3 mandates PFS through ECDHE.
Classic DH uses modular arithmetic over a finite field with large prime numbers (requiring 2048-bit+ keys for security). Elliptic Curve DH (ECDH) uses the algebraic structure of elliptic curves, achieving equivalent security with much smaller keys (256-bit for Curve25519), making it faster and preferred for modern use.
Yes — raw DH without authentication is vulnerable to man-in-the-middle attacks. An attacker can intercept and substitute the public keys. This is why TLS uses DH together with digital certificates to authenticate the server's public key. SSH uses known host keys for the same purpose.
NIST recommends at least 2048-bit DH parameters, equivalent to 112-bit symmetric security. 3072-bit provides 128-bit security. For new systems, prefer Curve25519 ECDH which provides 128-bit security with 256-bit keys and is faster, simpler and resistant to several implementation attacks that affect classic DH.
Explore More Tools

Explore More Free Crypto Tools

Discover our complete suite of cryptography, AI and developer tools — all free, no sign-up required.

Crypto Tools 100+ AI Tools
⚠ Disclaimer: "Diffie-Hellman" is named after Whitfield Diffie and Martin Hellman. "RFC 3526" and MODP group specifications are published by the IETF. "Curve25519" was designed by Daniel J. Bernstein. This tool is an independent educational implementation and is not affiliated with or endorsed by any of these parties. Do not use small educational primes in production systems. Always use vetted cryptographic libraries for security-critical applications. See our Privacy Policy.