Symmetric vs asymmetric encryption
Published
Symmetric encryption is a house key. The same key locks and unlocks, and you have to get a copy to everyone who needs to come in. Asymmetric encryption is a box of open padlocks with your name on them. You hand them out to anyone. Anybody can snap one shut on a parcel, but only you have the key that opens them.
The padlocks solve a problem the house key cannot: you never had to meet the sender to get them a key. But padlocks are slow and bulky. So every secure connection you make today does the obvious thing: it uses a padlock once to agree on a house key, then uses the house key for everything else.
Your laptop in a Bengaluru cafe connects to your bank for the first time. You have never exchanged a secret with the bank. Everyone on the cafe WiFi can see every packet. How can the two of you end up sharing a key that the people watching do not have?
Symmetric: one key, very fast#
One secret key, shared by both sides. AES is the standard everywhere, and ChaCha20 is the alternative on phones without AES hardware. Modern CPUs have AES instructions built in (AES-NI on Intel and AMD, the crypto extensions on ARM), so a single core encrypts several gigabytes a second. Your disk, your phone's storage and every HTTPS byte after the handshake use it.
Use an authenticated mode: AES-GCM or ChaCha20-Poly1305. They encrypt and also detect tampering. Never use ECB mode, which encrypts identical blocks identically; the famous demonstration is the Linux penguin image that is still recognisable after ECB encryption.
The weakness is entirely about the key. Both sides need it, it must reach them secretly, and with 1,000 people who each need a private channel to each other, you need about half a million keys.
Asymmetric: a key pair#
Each party has a public key, which can be published, and a private key, which never leaves them. The two are mathematically linked. RSA and elliptic curve cryptography (ECC) are the families you will meet. It gives you two different tools:
- Encryption or key agreement: anyone can use your public key so that only your private key can recover the secret.
- Digital signatures, the reverse direction: you sign with your private key, and anyone can verify with your public key. Nobody else could have produced that signature.
Signatures are everywhere once you look. A JWT signed with RS256 or ES256 is verified by every service with the identity provider's public key. Software updates, Git commit signing, SSH host keys, UPI's device binding and Aadhaar's eSign all rest on them.
The weakness is speed and size. An RSA-2048 private key operation costs around a millisecond of CPU; an elliptic curve one is much cheaper but still nowhere near bulk encryption speeds. Nobody encrypts a video with RSA.
The numbers are rough, single core and order of magnitude only, but the conclusion holds on any hardware. Asymmetric crypto is for small secrets: a key, a signature, a handshake.
How TLS uses both#
Back to the cafe. The trick that makes it work is key agreement, specifically elliptic curve Diffie-Hellman (ECDHE). Each side makes a fresh key pair just for this connection, sends only the public half, and combines its own private half with the other side's public half. Both arrive at the same shared secret. Someone watching saw both public halves and still cannot compute it.
That alone does not prove you are talking to the real bank: an attacker in the middle could do key agreement with you and separately with the bank. So the server also signs the handshake with the private key behind its certificate, and a certificate authority your device already trusts vouches for that key.
Because the ECDHE keys are thrown away after each connection, recording today's traffic and stealing the server's private key next year does not let anyone decrypt it. That property is forward secrecy, and TLS 1.3 makes it mandatory by removing the older RSA key exchange.
One more 2020s detail worth knowing: large quantum computers would break RSA and today's elliptic curves. Chrome, Firefox and Cloudflare already use a hybrid key agreement that combines X25519 with ML-KEM, a post quantum algorithm standardised by NIST in 2024, so traffic recorded now stays safe later. AES-256 is considered fine against quantum attacks.
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Symmetric (AES-GCM, ChaCha20-Poly1305) | Gigabytes per second per core, small keys (256 bits), tamper detection built in. | Both sides need the same secret, and getting it to them is the hard problem. | All bulk data: disks, databases, the body of every TLS connection. |
| Asymmetric (RSA, ECDSA, Ed25519, ECDHE) | No shared secret needed in advance. Enables signatures and key agreement with strangers. | Orders of magnitude slower, larger keys, only works on small data. | Handshakes, signatures (JWTs, code, certificates), wrapping symmetric keys. |
The same "padlock once, then house key" pattern shows up outside TLS. Envelope encryption in AWS KMS or Google Cloud KMS encrypts each file with its own random AES data key, then encrypts that small data key with a master key held in the KMS. PGP email does the same.
- AEAES-256-GCMThe symmetric default everywhere
- X2X25519 / Ed25519Modern elliptic curves for key agreement and signatures
- RSRSA-2048 / 3072Older, still common in certificates
- Let's EncryptFree certificate authority, issues most web certificates
- AWSKMS: envelope encryption with managed master keys
- CloudflareHybrid post quantum TLS by default
In the interview#
Checkpoint#
1. How do your browser and a bank agree on a key over a network others can read?
2. What is forward secrecy?
3. You sign data with your private key. Who can verify the signature?
- Symmetric: one shared key, fast (AES-GCM). Problem: getting the key there.
- Asymmetric: public and private pair, slow. Gives key agreement and signatures.
- TLS: ECDHE agrees a key, the certificate signature proves identity, AES encrypts traffic.
- Forward secrecy comes from throwaway key pairs. Mandatory in TLS 1.3.
- Envelope encryption: data key per object, wrapped by a master key in a KMS.
Symmetric encryption uses one shared key for both directions; AES-GCM with hardware support encrypts gigabytes per second, but both sides need the key in advance. Asymmetric encryption uses a public and private key pair; it lets strangers agree on a secret and lets anyone verify a signature made with a private key, but it is orders of magnitude slower and only handles small data. Real systems combine them. In a TLS 1.3 handshake, both sides send ephemeral elliptic curve Diffie-Hellman public keys and derive a shared secret, the server signs the handshake with the key in its certificate so the client knows it is the real server, and then all traffic is encrypted symmetrically with keys derived from that secret. Ephemeral keys give forward secrecy. The same pattern appears as envelope encryption in KMS, where each object gets its own AES key wrapped by a master key.