Symmetric vs Asymmetric Encryption, Explained Through Food Delivery

Last time, we watched your browser and a delivery app's server land on the exact same secret key without ever saying that key out loud — the "key exchange" step of the TLS handshake. It felt a little like magic. But we skipped past a question that's actually the whole point: once both sides have a shared secret, what do they do with it, and why did they go through all that trouble instead of just picking a key and sending it over?

The answer is that encryption comes in two fundamentally different shapes, and TLS quietly uses both — one for the handshake, and a completely different one for your actual order. Understanding the difference between them is understanding a huge chunk of applied cryptography, and none of it requires the math.

Symmetric encryption: one key, both sides need it

Symmetric encryption uses a single key to both lock (encrypt) and unlock (decrypt) the data. If you and the restaurant both have a copy of that same key, either of you can seal a message and either of you can open one.

Memory hook: a lockbox with exactly one kind of key. You cut two copies at the hardware store — one for you, one for the restaurant. Whoever holds a copy can open the box.

This is fast, simple, and — for the actual bulk of your data — exactly what you want. Algorithms like AES can encrypt huge amounts of traffic with very little computational overhead, which matters a lot when a server is doing this for millions of connections at once.

But it has one obvious, glaring problem.

The key distribution problem

If the key has to be identical on both sides, how does the second copy get there? You can't just email it, post it in the request itself, or send it in plain text over the same connection you're trying to protect — anyone watching that channel would simply copy the key in transit and read everything afterward. Somehow, the one thing that must never be seen in the open is the one thing both sides need to already have.

Memory hook: you can cut a spare key at the hardware store, but the courier who delivers it to the restaurant could just as easily be an impostor — and now the entire lockbox is worthless, because anyone with a copy of that key can open it.

This single problem is why symmetric encryption alone was never going to be enough for the open internet, where you're establishing a secure channel with a server you've never met, over a network you don't control.

Asymmetric encryption: two keys, mathematically linked

Asymmetric encryption solves this by using two different keys instead of one: a public key, which can be shared with absolutely anyone, and a private key, which never leaves its owner. The two are mathematically related in a specific way — anything locked with the public key can only be unlocked with the matching private key.

Memory hook: the restaurant hands out an open padlock to anyone who asks — you, a courier, a stranger. Anybody can snap that padlock shut around a box. But only the restaurant holds the one physical key that opens it, and that key never leaves the back office.

Notice what just disappeared: the key distribution problem. The restaurant never had to secretly deliver anything to you. It just handed you an open padlock in plain sight — because the padlock being public doesn't help anyone open it. Algorithms like RSA and elliptic-curve cryptography (ECC) — the "EC" in the ECDHE key exchange from the TLS post — work this way.

So why not just use asymmetric encryption for everything?

If asymmetric encryption solves the hard problem, it seems like the obvious winner. The catch is cost: the math behind public/private key pairs is dramatically more computationally expensive than symmetric encryption's simple shared-key operations. Using it to encrypt an entire video stream or a large file transfer would work, technically — but it would be slow enough to notice, and expensive enough that a server handling many connections at once would struggle to keep up.

Memory hook: the padlock-and-private-key system is trustworthy, but it's also the restaurant's owner personally verifying and signing off on every single box, one at a time. Great for the one moment that matters most. Painfully slow if you tried to run the entire kitchen that way all day.

The hybrid approach: how TLS actually uses both

This is exactly why the TLS handshake exists as its own separate phase, and it's the piece that connects directly back to last post. TLS doesn't pick one system — it uses asymmetric encryption for a few milliseconds to solve the one hard problem (safely agreeing on a secret, and proving the server's identity via its certificate), and then switches entirely to symmetric encryption for the actual application data, because by that point both sides finally share a secret they never had to transmit.

Memory hook: the restaurant's public padlock is used exactly once, to safely pass along a one-time shared key. From that moment forward, you and the restaurant just use that shared key like an ordinary lockbox for the rest of the meal — fast, simple, no more padlocks needed.

That's the real reason the handshake from last time looks the way it does: ClientHello and ServerHello negotiate capabilities, the certificate proves identity, and the key exchange step uses asymmetric math to land on a shared secret — all so that the "Finished" and "Application data" steps can switch to fast, cheap symmetric encryption for everything that actually matters to you.

Quick reference

• Keys involved — Symmetric: one shared key. Asymmetric: a public/private key pair.
• Speed — Symmetric: fast, low overhead. Asymmetric: much slower, computationally expensive.
• The hard problem — Symmetric: getting the same key to both sides safely. Asymmetric: none, the public key can be shared openly.
• Typical use in TLS — Symmetric: encrypting the actual application data. Asymmetric: the handshake (authentication and key exchange).
• Common algorithms — Symmetric: AES. Asymmetric: RSA, ECC (as in ECDHE).

The pattern worth keeping: whenever you see "fast bulk encryption," that's symmetric. Whenever you see "proving identity" or "safely agreeing on a secret with a stranger," that's asymmetric. Nearly every secure system you use daily — HTTPS, encrypted messaging, VPNs — is quietly running this exact same handoff between the two, even though from the outside it just looks like one padlock icon.

This is the fourth post in this series, following The OSI Model, But It's Food Delivery, Every OSI Layer Attack, Explained Through Food Delivery, and HTTP vs HTTPS: The TLS Handshake, Explained Through Food Delivery. Next: hashing vs. encryption — the difference people mix up constantly, and why a password database should never contain either of the two keys we just talked about.