Symmetric vs asymmetric encryption

You already know that encryption scrambles a plaintext message into unreadable ciphertext using a secret key, and that the method can be public — the key is the secret. But that leaves one enormous, awkward question hanging in the air:

If a shared key unlocks the message, how do the two of you agree on that key in the first place — over a network you don't trust?

You are about to buy something from a shop's website you have never visited before. To encrypt your card number you need a shared secret key. But you can't just send the key across the internet first — the very eavesdroppers you're hiding from would grab it, and then your "encryption" protects nothing. This is the famous key distribution problem, and the way it is solved is one of the most elegant ideas in all of computer science. There turn out to be two families of encryption, and understanding the difference between them is the whole story.

Family 1: symmetric encryption — one shared secret key

In symmetric encryption, the same key does both jobs: it locks (encrypts) the message and unlocks (decrypts) it. It's called "symmetric" because the two ends are mirror images — whoever can seal the box can also open it. The Caesar cipher you met before is symmetric: shift forward by k to encrypt, shift back by the same k to decrypt. Modern real-world symmetric ciphers such as AES are astronomically stronger, but the shape is identical.

\text{plaintext} \;\xrightarrow{\;\text{encrypt with } K\;}\; \text{ciphertext} \;\xrightarrow{\;\text{decrypt with } K\;}\; \text{plaintext}

Below, Alice sends a message to Bob. Follow the single key K — notice that the very same key appears at both ends, and so it has to somehow get from one to the other before any of this can work.

Symmetric encryption is fast — it can encrypt gigabytes per second, which is why it does the heavy lifting for bulk data. Its one fatal weakness is exactly the puzzle we opened with: both parties must already share the secret key, and there's no obviously safe way to hand it over across an open network.

The padlock that anyone can click shut

Here is the trick that breaks the deadlock. Imagine you buy a pile of identical open padlocks and hand them out to everyone — you leave a bowl of them by the door, print them in the newspaper, give them to strangers. You keep just one thing to yourself: the single key that opens them.

Now anyone who wants to send you something secret puts it in a box, grabs one of your padlocks, and clicks it shut. Clicking a padlock closed needs no key — anyone can do it. But opening it does need the key, and only you have that. So a total stranger can lock a message to you that nobody but you can open — and crucially, they never needed to share a secret with you first. That is the whole idea of asymmetric encryption, and it dissolves the key-distribution problem completely.

The open padlock you give away freely is your public key.
The key that opens it, which never leaves your pocket, is your private key.

Family 2: asymmetric encryption — a matched key pair

Asymmetric (or public-key) encryption gives every person a mathematically linked pair of keys generated together:

A public key — published openly, handed to anyone. It is used to encrypt a message to you (and to verify your digital signatures).
A private key — kept utterly secret, never shared. It is used to decrypt messages sent to you (and to sign, proving they came from you).
What one key of the pair locks, only the other can unlock. Knowing the public key does not let anyone work out the private key — that's the mathematical magic.

So if Alice wants to send a secret to Bob, she encrypts it with Bob's public key (which she can look up freely). From that moment the ciphertext can only be opened by Bob's private key — which Bob alone holds. Even Alice, having just encrypted it, cannot decrypt it back. Watch the two keys stay firmly on their own ends:

Compare the two diagrams. In the symmetric flow, one key had to somehow cross the gap between Alice and Bob. In the asymmetric flow, nothing secret ever crosses — only Bob's public key travels, and it's fine for the whole world to see it. The key-distribution problem simply evaporates.

\text{plaintext} \;\xrightarrow{\;\text{encrypt with Bob's } \textbf{public}\text{ key}\;}\; \text{ciphertext} \;\xrightarrow{\;\text{decrypt with Bob's } \textbf{private}\text{ key}\;}\; \text{plaintext}

Side by side

The single most important contrast for the exam: symmetric = one shared key; asymmetric = a public/private key pair. Everything else follows from that.

	Symmetric	Asymmetric (public-key)
Keys	One shared secret key	A pair: public + private
Encrypt with	The shared key	Recipient's public key
Decrypt with	The same shared key	Recipient's private key
Speed	Very fast (bulk data)	Much slower (small data)
Key distribution	Hard — the key must be shared secretly first	Easy — the public key can be shared openly
Examples	AES, Caesar cipher	RSA, elliptic-curve (ECC)

The best of both: how HTTPS really works

If asymmetric encryption is so clever, why not use it for everything? Because it's slow — the maths behind a key pair is expensive, and encrypting a whole video stream that way would crawl. Symmetric encryption is blisteringly fast but can't safely share its key. So real systems — including the HTTPS padlock in your browser — combine them and take the best of each:

Your browser invents a fresh random symmetric session key (fast for the bulk of the conversation).
It encrypts that session key with the website's public key and sends it over. Only the website's private key can unwrap it, so the session key crosses the open internet completely safely.
Now both sides share the secret session key, and the rest of the page — every click, password and card number — flows quickly under fast symmetric encryption.

Asymmetric encryption solves the hard part (agreeing a secret over an open line); symmetric encryption does the heavy lifting (fast bulk data). That handshake happens invisibly every single time that padlock appears.

Public-key cryptography was published in 1976 by Whitfield Diffie and Martin Hellman, and the famous RSA algorithm followed in 1977 (Rivest, Shamir and Adleman). But there's a twist: mathematicians at Britain's GCHQ — James Ellis, Clifford Cocks and Malcolm Williamson — had worked out essentially the same ideas a few years earlier, in the early 1970s. Their work was classified secret and only declassified in 1997, so for two decades the world credited the public inventors. Sometimes the same great idea is discovered more than once.

This is the single most common exam mistake — get the direction fixed firmly in your head:

To send someone a secret, you encrypt with the recipient's PUBLIC key. It's public precisely so that anyone can encrypt to them.
They decrypt with their own PRIVATE key — the one thing only they possess.
You never, ever share a private key. It never travels, never gets emailed, never leaves its owner. The moment a private key leaks, every message ever sent to that person can be read.
You do not encrypt with your own public key to message a friend — then only you could read it! Always reach for the recipient's public key.

(Signing is the mirror image: you sign with your private key so that anyone can verify with your public key — but that's a topic for another page.)

See the directions in code

This tiny model uses a made-up pair of keys just to show the flow (real RSA maths is far more involved). The point to read off is which key is used where: Alice encrypts with Bob's public key; Bob decrypts with his private key. Press Run:

// A toy stand-in for a real key pair (NOT secure — it just illustrates the flow). interface KeyPair { readonly publicKey: number; // given out freely readonly privateKey: number; // kept secret; publicKey * privateKey = 26 } const bob: KeyPair = { publicKey: 5, privateKey: 21 }; // 5 * 21 = 105 = 1 (mod 26) // "Encrypt" each letter by shifting with the PUBLIC key. function encrypt(text: string, publicKey: number): string { let out: string = ""; for (const ch of text.toUpperCase()) { const c: number = ch.charCodeAt(0); if (c >= 65 && c <= 90) { out += String.fromCharCode(((c - 65 + publicKey) % 26) + 65); } else { out += ch; } } return out; } // "Decrypt" by shifting with the matching PRIVATE key (undoes the public shift). function decrypt(text: string, privateKey: number): string { return encrypt(text, privateKey); // 5 + 21 = 26 ≡ 0, so it lands back on the original } const message: string = "TOP SECRET"; // Alice encrypts to Bob using BOB'S PUBLIC key: const cipher: string = encrypt(message, bob.publicKey); // Only Bob can decrypt, using HIS PRIVATE key: const recovered: string = decrypt(cipher, bob.privateKey); console.log("Plaintext :", message); console.log("Ciphertext :", cipher); console.log("Bob decrypts:", recovered);

Alice used a key she looked up in public, yet the result can only be opened by Bob. No shared secret ever had to travel — that's the power of a key pair.