A public starting point
Both sides start from one public value. For X25519, RFC 7748 fixes it as the curve point with u-coordinate 9. On the wheel it is the base colour, which everyone sees at the start of each round. Agreeing on it needs no secret.
MikroTik field tools · Security expertise · free · in-browser
Diffie-Hellman lets two parties agree a key over a network that anyone on the path can record. This page runs one exchange on a colour wheel. Each side turns a public base colour by a private amount and sends the result. Then each side turns the colour it received from the other by its own private amount. Both end on the same colour, and that colour is never sent. Once the exchange is done, you play the eavesdropper. Every public colour is on your dial, and you can blend them any way you like to get close to the shared one. The X25519 panel shows this round's numbers, including how far your best blend falls short, next to the same exchange written for Curve25519. The walkthrough and FAQ below cover forward secrecy and where a MikroTik router uses it.
Two sides agree a secret colour while you record everything they send. When they finish, drag the needle and get as close to that colour as you can.
agreed at both ends — never sent
Drag the needle — how close can you get to the colour they agreed?
You are stuck 38° short — and 38° is exactly one of the two secret turns. A blend always lands between its ingredients, so everything you can pour lives inside the wedge — and the secret sits one turn beyond it. Could you cheat instead? On a colour wheel, yes: subtract the base from a public and a turn falls right out. Curve25519 is the wheel where that subtract button does not exist — running the step backwards is the hard problem, and the curve does not even leak how close you are. The whole secret rests on that missing button. Close is not a key.
And the two turns? Deleted the moment the session ended. That is Perfect Forward Secrecy — a full recording of the wire stays sealed: no key stolen later reopens it.
Running this wheel backwards is one subtraction. Running Curve25519 backwards is the elliptic-curve discrete-log problem — no known shortcut faster than about 2^126 curve operations on today’s computers. The colours are reversible; the curve is not.
Colour is only the model here. The real one-way street is ECDLP on Curve25519 — a hard mathematical conjecture, not the physical impossibility of unmixing paint: these pigments could be separated again; the curve, as far as anyone knows, cannot be run backwards.
Forward secrecy seals the past, not the future: a stolen long-term key can still impersonate the server to new visitors until the certificate is revoked. It signs the handshake — it is never an input to the key schedule.
Drag the needle — how close can you get to the colour they agreed?
Vivid chip = a colour in play: the common base everyone can see, the two colours broadcast in the open, the shared colour agreed but never sent, and the eavesdropper’s blend. Each is labelled, and the readout prints the distance in degrees — nothing depends on colour alone.
Both sides start from one public value. For X25519, RFC 7748 fixes it as the curve point with u-coordinate 9. On the wheel it is the base colour, which everyone sees at the start of each round. Agreeing on it needs no secret.
Each side picks a private value and keeps it. For X25519 that is 32 random bytes; on the wheel it is how far that side turns the colour. The private value never leaves the side that picked it.
Each side applies its private value to the starting point and sends the result. On the wheel the result is the colour the needle stops on; on the curve it is a 32-byte point. This is where the model breaks down. On the wheel you can undo the step with one subtraction: take the base hue away from the public hue and the private turn is left. Undoing the step on the curve is the hard problem the secret depends on.
Each side then applies its private value to the public value it received from the other. Both get the same result. On the wheel, two turns add up to the same total in either order. RFC 7748 states the curve version as X25519(a, X25519(b, 9)) = X25519(b, X25519(a, 9)). The shared value is computed at each end and never sent.
A full recording holds three public values: the starting point and the two results. The demo only lets you blend them, since subtraction would give a private turn away. A blend always lands between the colours you mixed, so your best blend stops short of the shared colour by exactly the smaller of the two private turns. On the curve, the only known route to the shared point is to recover a private value from its public one, which is the elliptic-curve discrete-log problem on Curve25519. Its hardness is a conjecture with no proof, and there is no known shortcut on today's computers.
When the session ends, both sides delete their private values. After that, no key stolen later can reopen the recording; the only way in is to solve the hard problem itself. This is forward secrecy, and it covers past sessions only. Whoever steals a long-term key can still impersonate its owner in new handshakes until the key is revoked. That key cannot decrypt a session that has already closed, because the session's key came from private values that no longer exist.
Each session's keys are derived from temporary secrets that both sides delete when the session ends. If someone records the encrypted traffic and later gets the server's long-term key, the one that proves its identity, they still cannot decrypt those sessions. It depends on a fresh ephemeral Diffie-Hellman exchange for every session, and on those ephemeral secrets being deleted.
Each side picks a private number and applies it to a public starting point that both know, then sends the result. Each side then applies its own private number to the result the other side sent. Both calculations give the same value. The private numbers and the shared value never go over the network.
The recording holds only public values: the starting point G and the two results, a·G and b·G. Adding the two results gives (a+b)·G, which is a different point; the shared secret is ab·G. Getting there needs a or b, and recovering either from its public point is the elliptic-curve discrete-log problem. It is believed to be hard, and there is no known shortcut on today’s computers.
Not if those sessions used forward secrecy. Their keys came from ephemeral secrets that were deleted when each session ended. In a TLS handshake the long-term key only signs; it is never an input to the key schedule, so holding it later does not rebuild a finished session. Sessions after the leak are not protected: whoever holds the key can impersonate the server in new handshakes until the key is revoked.
X25519 is the Diffie-Hellman function that RFC 7748 defines for Curve25519. The steps are the ones this page shows: a public starting point, a private value on each side, two public results exchanged, and one shared value computed at both ends. The values are points on an elliptic curve instead of hue angles on a wheel.
No. It models the intuition only. A hue turn is easy to reverse: subtract the base from a public colour and the private turn comes out, which is why the demo only lets you blend. The one-way step in the real protocol is the elliptic-curve discrete-log problem on Curve25519. Nobody has proved it hard; its hardness is a conjecture. The wheel also shows your distance from the secret in degrees. The curve gives no distance signal for a wrong guess.
WireGuard runs a fresh ephemeral key exchange in every handshake, so forward secrecy is part of the protocol and there is nothing to switch on. IPsec depends on the proposal. If it sets a PFS group, every phase-2 rekey runs a new Diffie-Hellman exchange instead of deriving its keys from phase 1 alone. A TLS-based tunnel is forward-secret when its handshake runs a fresh key exchange. A session resumed from a pre-shared key alone, with no key exchange, is not forward-secret.
No. End-to-end encryption means only the two endpoints can read the traffic, and nothing in between can. Forward secrecy means a recording of old sessions stays unreadable even if a long-term key leaks later, because the session keys were deleted. A system can have either one without the other.
This demo also runs on the security expertise page. It has a page of its own here so you can send someone a link to the exchange alone. Read RouterOS security and hardening.
Bring me the VPN you haven’t auditedAlso on the bench: RouterBOARD reset simulator, Visual subnet calculator, Recursive failover simulator, Interactive packet-flow diagram