Two devices each send a short public number and both end up with the same secret, which eavesdroppers can't compute.
The idea: Each device picks a random secret number and multiplies a standard curve point by it to get a public key. They swap public keys, and each multiplies the other's by its own secret. Both land on the same point, which is hashed into encryption keys, while anyone watching only saw the two public keys. Fresh secrets are used for every connection, so stealing a server's long-term key later doesn't unlock past traffic (forward secrecy).
Why it matters: Sets up the encryption for almost every HTTPS, SSH, Signal and WireGuard connection.
Agreeing on a secret in public
Alice and Bob start from a public color, each mixes in a secret one, and they swap the mixtures in the open. Each then adds their own secret color to what they received, and both end up with the same paint. An eavesdropper has seen both mixtures but can't unmix them. In the real protocol, mixing is multiplying a curve point by a secret number.
The details
Diffie-Hellman over an elliptic curve: each side sends a 32-byte public key and both derive the same shared secret.
X25519, built on Curve25519[1, 2], is the default key exchange in TLS 1.3, SSH, Signal and WireGuard[3]. It is now usually paired with ML-KEM in a hybrid[4] so that recorded traffic stays safe from future quantum computers.
A. Langley, M. Hamburg and S. Turner. Elliptic Curves for Security. RFC 7748, 2016. rfc-editor.org/rfc/rfc7748
Daniel J. Bernstein. Curve25519: New Diffie-Hellman Speed Records. Public Key Cryptography - PKC 2006. doi:10.1007/11745853_14
E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, 2018. rfc-editor.org/rfc/rfc8446
Kris Kwiatkowski, Panos Kampanakis, Bas Westerbaan and Douglas Stebila. Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 (Internet-Draft draft-ietf-tls-ecdhe-mlkem). IETF TLS working group, 2024. datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem