Key Exchange
Simulate Diffie-Hellman key exchange
100% free. Runs entirely in your browser - your files and data never leave your device and nothing is uploaded to any server.
Public Parameters
About this tool
Simulates the Diffie-Hellman key exchange - a foundational cryptographic method that lets two parties agree on a shared secret key over an insecure channel, without ever transmitting the key itself. It's an educational visualization of how the math behind this widely-used protocol actually works, step by step.
How to use this tool
- Set public parametersChoose shared prime and generator used by both communicating parties.
- Generate private/public valuesCreate each side’s private secret and corresponding public key.
- Exchange public keysSimulate insecure-channel sharing of public values only.
- Derive shared secretCompute matching session secret independently on both sides.
Diffie-Hellman in plain numbers
Alice and Bob agree publicly on a prime p = 23 and a base g = 5. Alice picks a secret 6 and sends 5^6 mod 23 = 8; Bob picks a secret 15 and sends 5^15 mod 23 = 19. Alice computes 19^6 mod 23 = 2 and Bob computes 8^15 mod 23 = 2 - they now share the secret 2, which never travelled over the network.
Real systems use numbers hundreds of digits long, which makes recovering the secrets from the public values infeasible. The same idea secures HTTPS, SSH and messaging apps today.
Key features
- Visualizes core Diffie-Hellman concept clearly for learning.
- Shows why private keys are never transmitted directly.
- Useful for understanding TLS and secure-session foundations.
- Bridges cryptography theory with step-by-step practical flow.
Common uses
- Teaching cryptography fundamentals in classes/workshops.
- Explaining secure key agreement to engineering teams.
- Demonstrating public-key exchange concept in documentation.
- Debugging conceptual misunderstandings in protocol design reviews.
Tips for better results
- Treat this as educational simulation, not production key generation.
- Focus on trust/authentication gap DH alone does not solve.
- Compare with ECDH for modern protocol context.
- Use larger parameter intuition when discussing real-world security.
Mistakes to avoid
- Assuming DH by itself prevents man-in-the-middle attacks.
- Using toy parameter sizes in real production systems.
- Confusing shared-secret derivation with full encryption protocol.
- Reusing static secrets without forward-secrecy design.
Frequently asked questions
This is an educational simulation meant to illustrate how the Diffie-Hellman math works conceptually - it's not intended to generate or exchange a real production-grade secret key for an actual secure communication channel.
It's a core building block in many real-world security protocols (like TLS/HTTPS) that lets two parties establish a shared secret key over a public network without ever sending the key itself, protecting against eavesdroppers.
The tool is designed to visualize the process step by step, making the core idea (public math operations that produce a shared secret only the two parties can compute) approachable even without deep prior cryptography knowledge.
They see the public values but would need to solve the discrete logarithm problem to recover a private number, which is infeasible with large enough primes. With the small numbers in a demo it is easy, which is why real systems use 2048-bit groups or elliptic curves.
Not on its own. An attacker in the middle can run a separate exchange with each side. TLS prevents this by authenticating the exchange with certificates and signatures.
Both sides start with a shared public colour, each adds a secret colour and swaps the mixtures, then adds their secret again. Both end with the same final colour, while an observer cannot un-mix the paints to find the secrets.