Authenticated Key Exchange: Defeating MITM & Replay Attacks

Threat Model

MITM attacker active

Signed-nonce authentication

Nonce freshness window 1500 ms

Handshake Status

Idle — press Run handshake

Alice's session key

—

Bob's session key

—

Replay attempts blocked

Protocol Log

How it works

Alice and Bob agree on a shared secret using Diffie–Hellman over a public channel with small parameters p = 23, g = 5:

private a, b  (random, 2..18)
A = g^a mod p     (Alice → Bob)
B = g^b mod p     (Bob → Alice)
K_A = B^a mod p,  K_B = A^b mod p
K_A == K_B  ⇔  handshake secure

Without authentication, a man-in-the-middle (Mallory) can run this exact exchange twice — once with Alice, once with Bob — relaying nothing, and each endpoint unknowingly negotiates a session key with Mallory instead of with each other. Neither key readout matches, because Alice and Bob never actually shared one secret.

Signed-nonce authentication fixes this: every exchanged value A, B is bound to a per-message nonce and signed with a long-term key only the real Alice/Bob hold. Mallory can copy bytes across the wire but cannot forge a valid signature over her own substituted public value, so the receiver's signature check fails and the handshake is rejected — MITM is detected before any key is trusted.

Replay defense is a separate, independent check: every accepted nonce is cached, and a nonce's timestamp must fall inside the freshness window. "Replay captured packet" resends a real, previously-valid signed packet unchanged — it still gets rejected, either because the nonce is already in the replay cache or because its timestamp has aged out of the window. This is exactly how TLS record sequence numbers, Kerberos timestamps and WireGuard's rolling counters stop replayed packets from being re-accepted.

Alice Bob Mallory (attacker)

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.