Symmetric vs Asymmetric Encryption

Symmetric encryption uses one shared key (fast, hard to distribute). Asymmetric uses a public/private pair (solves key distribution, but slow). Real systems use both—like HTTPS and JWTs.

Banner

Prefer to watch? ▶ Symmetric vs Asymmetric Encryption in 90 seconds ✈ Telegram

You have two ways to scramble data so only the right person can read it. The whole difference is how the key works—and getting it wrong is how a "secure" channel leaks on the very first step.

  • Mental model: Symmetric is a shared passport both of you guard; asymmetric is a mailbox only you can open but anyone can drop letters into.

Symmetric Encryption: One Shared Secret

Symmetric encryption uses a single key that both encrypts and decrypts the data. You and I agree on a secret passphrase, and we both use it to lock and unlock messages.

Common algorithms:

  • AES (Advanced Encryption Standard) — the gold standard for bulk data
  • ChaCha20 — modern, fast, resistant to timing attacks

It's blazing fast. Symmetric encryption can encrypt gigabytes per second on modern hardware. That's why it protects all your disk storage, all the traffic flowing through your VPN, all the video streaming from Netflix to your screen.

The catch is brutal: key distribution. How do you and I safely exchange that one secret key in the first place?

If I send it to you over an untrusted network—email, the internet, a text message—anyone listening can intercept it in transit and copy it. Now they hold the same key you and I hold. They can read every message we've ever sent with it. They can forge new messages and pretend they're from me.

And the problem scales badly. If 10 people all need to talk to each other privately, each pair needs its own unique key. That's not 10 keys—it's roughly 45 keys (N × (N − 1) ÷ 2). With 100 people, you're managing nearly 5,000 keys. Every key is a secret that must be guarded, rotated, and never disclosed.


Asymmetric Encryption: A Public/Private Pair

Asymmetric encryption solves the key-distribution problem by creating two mathematically linked keys:

  • The public key encrypts messages. You hand it to anyone, put it on your website, email it freely.
  • The private key decrypts messages. It never leaves you. It stays locked in your system.

Anyone can use your public key to send you a message nobody else can read—not even them, once it's encrypted. Only you, holding the private key, can decrypt it.

Common algorithms:

  • RSA — the oldest and most widely deployed
  • Elliptic Curve Cryptography (ECC) — newer, smaller keys for the same security

There is no shared secret to smuggle across the network. Key distribution is solved. You just publish your public key. The hard part—the private key—never travels.

The catch is speed. Public-key math (modular exponentiation, elliptic-curve point multiplication) is orders of magnitude slower than symmetric operations. Roughly 100× slower for the same security level. You can't encrypt a gigabyte of video with RSA in real time.


The Real World: Use Both

Production systems don't choose one or the other. They use asymmetric encryption to safely hand off a symmetric key, then use symmetric encryption for the actual traffic.

This hybrid approach shows up everywhere:

HTTPS/TLS Handshake

When you visit https://example.com:

  1. Your browser asks the server for its public key (inside a certificate).
  2. Your browser generates a random session key (symmetric).
  3. Your browser encrypts that session key with the server's public key (asymmetric) and sends it.
  4. The server decrypts it with its private key (asymmetric).
  5. Now both of you have the same session key. You use it to encrypt all traffic for the rest of the connection (symmetric).
  6. When the connection closes, you throw away that session key. Next connection, a new random key.

Asymmetric solves the bootstrap problem. Symmetric does the heavy lifting.

JWT Signing

A JWT (JSON Web Token) works similarly:

header.payload.signature

The signature is computed by hashing the header and payload, then encrypting that hash with the issuer's private key (asymmetric). Anyone with the public key can verify the signature was really made by the issuer—but they can't forge a new signature without the private key.

The token itself is not encrypted. It's only signed. The public key verification proves authenticity and prevents tampering.


Comparison Table

AspectSymmetric (AES, ChaCha20)Asymmetric (RSA, ECC)
KeysOne shared secretPublic/private pair
Key distributionHard — must smuggle safelyEasy — publish the public key
SpeedVery fast, bulk dataSlow, ~100× slower
Use caseEncrypt gigabytes of traffic or diskEncrypt a key, hash, or signature
Who can decrypt?Anyone with the keyOnly holder of private key
N-person scaling~N² keys neededN public keys, N private keys

Code: A Conceptual Sketch

Here's pseudocode showing the hybrid approach:

# Client initiates connection
public_key = fetch_server_certificate()  # Asymmetric
session_key = generate_random_key()      # Symmetric, 256-bit
encrypted_session_key = asymmetric_encrypt(session_key, public_key)
send(encrypted_session_key)

# Server receives it
encrypted_session_key = receive()
session_key = asymmetric_decrypt(encrypted_session_key, private_key)

# Both now have the same session key. Encrypt all traffic with it.
encrypted_message = symmetric_encrypt("Hello", session_key)
send(encrypted_message)

received = receive()
message = symmetric_decrypt(received, session_key)  # "Hello"

Asymmetric solves the problem. Symmetric does the work.


For LLM Inference: Latency and Caching

If you're building a system where an LLM generates tokens and a user decrypts them in real time, symmetric encryption dominates the latency budget.

  • Asymmetric (key exchange during connection setup): one-time cost, amortized over the session. Happens in the TLS handshake before the first token streams out.
  • Symmetric (per-token encryption/decryption): happens per-token. If you're doing it naively, it blocks Time To First Token (TTFT) and per-token latency. Use hardware acceleration (AES-NI) or stream-cipher modes (ChaCha20 with no block-boundary overhead) to keep latency negligible.

The real win: send the session key once (asymmetric, slow), then stream encrypted tokens at line rate (symmetric, negligible overhead).


Verdict

Reach for symmetric encryption when you need to protect bulk data fast (disk, network traffic, storage). Use asymmetric encryption to safely hand off keys or sign messages without revealing secrets. Real systems use both—asymmetric bootstraps the connection, symmetric carries the traffic.

Watch the 90-second reel on the short-form channels above for the visual walkthrough.

Symmetric vs Asymmetric Encryption | Vahid Aghajani