Symmetric vs asymmetric encryption, explained properly

Symmetric encryption uses one key: the same secret locks and unlocks the data. Asymmetric encryption uses a key pair: anyone can encrypt with the public key, only the private key holder can decrypt. Symmetric is thousands of times faster; asymmetric solves the problem symmetric cannot, which is agreeing on a key with someone you have never met. Every serious system, TLS included, uses both together: asymmetric to exchange a key, symmetric to move the data.

That is the whole picture in four sentences. The details are worth knowing because they explain most of the cryptography you interact with daily. If you want to feel the symmetric side concretely, the Encrypt Text tool runs AES-GCM in your browser with a key derived from your passphrase.

How symmetric encryption works

One secret key drives both directions. The modern standard is AES, usually with a 256 bit key, in an authenticated mode like GCM that detects tampering as well as hiding content. Given the key, encryption and decryption are extremely fast: hardware instructions in every modern CPU push AES to gigabytes per second, which is why your disk encryption and every large file transfer are symmetric.

The catch is in the name people give the problem: key distribution. If you and I want to exchange encrypted files, we both need the same key, and we cannot send it over the channel we are trying to protect. Whisper it over the phone? Meet in person? Every option is awkward, and it gets worse with scale: a system of n parties needs a separate key per pair.

How asymmetric encryption works

Asymmetric cryptography, also called public key cryptography, splits the key in two mathematically linked halves:

• The public key can be handed to anyone, printed on a website, embedded in a certificate. It encrypts.
• The private key never leaves its owner. It decrypts.

Now key distribution dissolves: to receive secret messages, publish your public key and keep the private one safe. Anyone can encrypt to you; only you can read the result.

The same key pair, used in the opposite direction, gives digital signatures: the private key signs, the public key verifies, proving who produced a message and that it was not altered. This is what certificate authorities do to TLS certificates and what JWTs use in their RS256 and ES256 variants.

The classic algorithm is RSA; the modern preference is elliptic curve cryptography (ECDSA, Ed25519, X25519), which reaches the same security with far smaller keys, a 256 bit curve key roughly matching a 3072 bit RSA key. The key formats these arrive in are their own small maze, untangled in our RSA key formats post.

Why not use asymmetric for everything?

Because it is slow and awkward with bulk data. Asymmetric operations cost thousands of times more CPU than AES, and RSA cannot even encrypt a message longer than its key. Encrypting a video call or a database backup with RSA is not a thing anyone does.

So every real protocol is a hybrid:

1. Use asymmetric crypto once, at the start, to agree on a random symmetric key.
2. Use that symmetric key with AES (or ChaCha20) for all the actual data.

TLS is exactly this: the handshake uses asymmetric cryptography (today, an elliptic curve Diffie-Hellman exchange, with the server's certificate signing the exchange to prevent impersonation), then everything after the handshake is symmetric. The full sequence is traced in the TLS handshake explained. PGP encrypted email, Signal messages, and encrypted file sharing all follow the same shape: a symmetric session key, delivered asymmetrically.

Side by side

The two mistakes worth avoiding

Confusing encoding with encryption. Base64 looks scrambled but anyone can reverse it; there is no key. This mistake ships to production constantly, and Base64 is not encryption exists because of it.

Rolling your own combination. The individual primitives are solid, but composing them, key derivation, nonces, padding, authentication order, is where homemade cryptography fails. Use vetted constructions: AES-GCM with a key from a proper KDF, or a library like libsodium that packages the whole decision. If a passphrase is involved, the stretching step matters as much as the cipher, which our password entropy post quantifies.

To see the symmetric half in action, the Encrypt Text tool derives an AES-GCM key from your passphrase with PBKDF2 and encrypts entirely in your browser; nothing you type is transmitted. Pair it with AES-CBC vs AES-GCM to understand why the mode matters as much as the algorithm.