How do symmetric and asymmetric encryption differ, and why does real-world crypto use both?
Symmetric uses one shared secret key and is fast; asymmetric uses a public/private key pair and solves key distribution, but is slow, so protocols combine them.
| Symmetric | Asymmetric (public key) | |
|---|---|---|
| Keys | One secret key, shared by both sides | A key pair: public key (anyone may have it), private key (only the owner) |
| Speed | Fast, suits bulk data | Orders of magnitude slower |
| Key size for comparable strength | Short (AES-128/256) | Long (RSA-3072/4096) or elliptic curves (256 bit) |
| Key distribution | Hard: the secret must reach the partner safely first | Easy: the public key can be published openly |
| Number of keys for n parties | n·(n−1)/2 pairwise secrets | n key pairs |
| Extra abilities | Confidentiality, MACs | Digital signatures, key exchange |
| Examples | AES, ChaCha20, 3DES | RSA, ECDSA, Diffie-Hellman |
The two are complementary. Symmetric crypto has the speed but needs a safe way to share the key; asymmetric crypto provides that way but is too slow for megabytes of data. So TLS, S/MIME and VPNs are hybrid: public-key operations authenticate the partner and agree on a fresh symmetric session key, and AES (or similar) then encrypts the actual traffic.
That leaves one open question, which is what a PKI answers: when someone hands you a public key, how do you know it really belongs to them? A certificate binds the key to a name, signed by a CA you trust.
Go deeper:
Computerphile: Public Key Cryptography — a six-minute intuition for key pairs, with no maths.
Wikipedia: Hybrid cryptosystem — how protocols wrap a symmetric session key with public-key crypto.
Wikipedia: Public-key cryptography — key pairs, signatures and key exchange side by side.