Web Security's encryption lesson named asymmetric encryption's shape — a public key that encrypts, a private key that decrypts — without explaining why that's even mathematically possible, or why every real system reaches for symmetric encryption the moment performance actually matters.
3 min read
Symmetric encryption (lesson 2) needs both parties to already share the same secret key — but if two parties have never met and have no secure channel yet, how does that first key ever get safely exchanged? Sending it in plaintext defeats the purpose entirely; this is exactly the chicken-and-egg problem asymmetric encryption exists to solve.
Asymmetric encryption uses a key pair — mathematically related, but not identical. The public key can be shared with literally anyone; the private key must stay secret. Data encrypted with the public key can only be decrypted with the matching private key:
This is the genuinely clever part: the public key doesn't need to be protected at all — publishing it openly is the entire point — yet possessing it gives an attacker no ability to decrypt anything encrypted with it.
RSA (the most widely known asymmetric algorithm) relies on a problem that's easy in one direction and extremely hard in the other: multiplying two large prime numbers together is fast; factoring the resulting product back into those two primes is not, for large enough primes. The public key is derived from that product; the private key depends on knowing the original prime factors. Anyone can do the "easy direction" math to encrypt; only someone who actually knows the prime factors (the private key holder) can do the "hard direction" math to decrypt efficiently. This asymmetry between the two directions is the entire mathematical foundation the scheme rests on — not a trick, a genuine, well-studied computational hardness assumption.
Asymmetric operations are computationally expensive compared to symmetric ones — orders of magnitude slower for the same amount of data. Using RSA to encrypt an entire large file directly would be genuinely impractical at real scale. This is exactly why lesson 2's mode-of-operation discussion and this lesson's public/private key idea combine in practice rather than competing:
Real systems (TLS included, covered in depth in lesson 7) use asymmetric encryption briefly, just to safely establish a shared symmetric key, then switch entirely to fast symmetric encryption for the actual data — getting asymmetric encryption's key-distribution benefit without paying its performance cost for every byte transferred.
A public/private key pair can be used two genuinely different ways: to encrypt (public key encrypts, private key decrypts — confidentiality, this lesson's focus) or to sign (private key signs, public key verifies — authenticity, lesson 4's focus). These are not the same operation run differently; they solve different problems, and confusing them is a common source of real misunderstanding about what asymmetric cryptography actually provides in a given system.
Modern systems increasingly use ECC (Elliptic Curve Cryptography) instead of RSA — a different mathematical hard problem (the discrete logarithm problem on an elliptic curve, rather than integer factorization), chosen because it achieves equivalent security with significantly smaller key sizes, meaning less data to transmit and faster computation. The core public/private key concept from this lesson applies identically; only the specific math problem underneath changes.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What mathematical asymmetry does RSA's security rely on?
2. Why do real systems use asymmetric encryption only briefly rather than for all data transfer?
3. How does using a key pair for signing differ from using it for encryption?
Cryptography Fundamentals