The idea: one key, or a key pair

Encryption turns a readable message (the plaintext) into gibberish (the ciphertext) that only someone with the right key can turn back. There are two kinds. In symmetric encryption one shared key both locks and unlocks, so sender and receiver must hold the same secret. In asymmetric (public-key) encryption the receiver has a key pair: a public key that anyone may use to lock, and a private key that only the owner has and that alone can unlock.

Two rows. Symmetric: Alice encrypts MEET AT NINE with the shared key LEMON into XIQH NE RUBR, and Bob decrypts with the same key LEMON. Asymmetric: Alice encrypts HI BOB with Bob's public key (3233, 17) into numbers, and Bob decrypts with his private key d = 2753, which never leaves him
Symmetric: the same key on both sides. Asymmetric: anyone can lock with the public key; only the private key unlocks.

The canvas shows Alice (sender), the network and Bob (receiver). Eve sits on the network and copies every packet into her notebook. Pick a method and a message and press Send, or run a demo. The table at the bottom keeps one row per message: did Eve read it, did Bob, and how much work it took. Colours: green for a shared or session key, blue for a public key, orange for a private key, red for Eve's key, grey for ciphertext.

Symmetric encryption

The page's symmetric cipher is a toy: the shared key is LEMON, and each letter is shifted forward by the matching key letter (A = 0, B = 1, …, Z = 25). M + L = X, E + E = I, so MEET AT NINE becomes XIQH NE RUBR. Bob shifts back with the same key. This is a Vigenère cipher and it is easy to break; real systems use AES or ChaCha20. The idea is the same: one secret key, and very little work per byte. Modern CPUs encrypt gigabytes per second with AES. (Demo: symmetric, key agreed in person)

The key-distribution problem

Symmetric encryption only works if Alice and Bob already share the key and nobody else has it. If Alice sends the key over the network, it can't be encrypted, because there is no key yet to encrypt it with. Eve copies it and from then on reads everything. (Demo: symmetric, key sent over the network)

Meeting in person, sending a courier or installing the key in advance solves this for a few people. It doesn't scale. Every pair needs its own key, so n people need n(n − 1)/2 keys: 6 for 4 people, 4,950 for 100. And your browser can't meet every website first.

Left: four people A, B, C, D connected by six lines, each line a different shared key. Right: the same four people, each with one key pair (one public key, one private key), four pairs in total. Below: n people need n(n-1)/2 shared keys, 4950 for 100 people, but only n key pairs
With shared keys every pair needs its own secret. With key pairs everyone publishes one public key.

Asymmetric encryption

Bob makes a key pair. The page uses textbook RSA on small numbers, the same as How a Digital Signature Works: p = 61, q = 53, so n = 3233. Bob's public key is (n = 3233, e = 17), and his private key is d = 2753. Alice turns each letter into its code (H = 72) and computes c = m17 mod 3233, so 72 becomes 3000. Bob computes c2753 mod 3233 and gets 72 back.

Bob can send his public key in the open. Eve copies it, but it only locks. Applying it again to 3000 gives a different number, not H. To unlock, Eve needs d, and getting d from (3233, 17) means factoring n into p × q. That's easy for 3233. It is out of reach for the 2048-bit numbers real keys use. (Demo: asymmetric, Eve has the public key too)

Other public-key systems work on the same lock/unlock split: elliptic-curve cryptography (ECC) gives the same security with much shorter keys.

Why not use asymmetric for everything?

Because it is slow. Each letter costs a big exponentiation. On the page that's 5 multiplications to encrypt (e = 17) and 15 to decrypt (d = 2753), against 1 shift each way for the symmetric cipher. The long message costs 56 operations with the shared key and 560 with RSA. (Demo: same long message three ways) With real key sizes the gap is far larger:

Symmetric (AES-256-GCM)Asymmetric (RSA-2048)
Keysone shared secret keya public key and a private key
Key size256 bits2048 bits (ECC: 256 bits)
Speedgigabytes per second per coreabout a thousand private-key operations per second per core
Message sizeany lengthless than the key size (about 190 bytes with OAEP)
Key exchangeneeds a safe channel firstthe public key can be sent in the open
Used forbulk data: files, disks, every TLS recordexchanging keys, signatures

Hybrid encryption

Real systems combine the two. Alice picks a fresh random session key (TIGER on the page) and encrypts only that with Bob's public key. Bob decrypts it with his private key. Now both share a secret that never crossed the network in the clear, and everything after it uses the fast symmetric cipher. RSA runs once, on 5 letters. The long message costs 100 + 56 = 156 operations instead of 560. (Demo: hybrid, RSA carries the session key)

A sequence from top to bottom between Alice and Bob: 1. Bob sends his public key (3233, 17). 2. Alice picks the session key TIGER and sends it encrypted with the public key, slow but only once. 3. Both now hold TIGER. 4. Every message goes encrypted with TIGER, fast
Hybrid: the slow public-key step runs once to share a session key, and the fast cipher carries the data.

PGP and the old RSA key exchange in TLS 1.2 work exactly like this. TLS 1.3 and SSH agree on the session key with an (EC)Diffie-Hellman exchange instead of sending it encrypted, which also gives forward secrecy: stealing the server's key later doesn't unlock old recordings. See How an HTTPS Connection Is Established.

Whose public key is it?

Public-key encryption keeps a message from everyone except the owner of the public key. It doesn't say who that owner is. If Eve can change packets, she replaces Bob's public key with her own (2773, 17). Alice encrypts to Eve without knowing it. Eve decrypts with her private key d = 157, reads the message, re-encrypts it with Bob's real key and forwards it. Bob reads it fine, and nobody notices this man-in-the-middle attack. (Demo: Eve swaps Bob's public key)

The fix is a certificate: Bob's public key signed by a certificate authority that Alice already trusts. Eve can't make a valid signature on her own key with Bob's name. See How a Digital Signature Works.

See the RSA math worked by hand on a toy key (n = 3233) in Modular Exponentiation and Toy RSA.

Agreeing on a session key without sending it at all is the job of Diffie-Hellman key exchange.

See also: Inside AES-128 and SHA-256 shows the rounds of the AES cipher used for the session key, on the FIPS-197 test vector.

Kerberos solves key distribution with symmetric keys only, through a trusted KDC that hands out session keys: see How Kerberos Works.

What the page leaves out

The ciphers are toys. The shift cipher falls to frequency analysis, and textbook RSA per letter sends the same number for the same letter (both Bs in HI BOB are 524). Real RSA encrypts one padded block with OAEP, which adds randomness. Real symmetric encryption also uses a mode and an authentication tag (AES-GCM) so tampering is detected, and spaces and lengths aren't left in the clear. The page also skips how key pairs are generated, Diffie-Hellman key agreement, key rotation, and post-quantum key exchange (ML-KEM), which replaces RSA and ECDH against future quantum computers.