Public-Key Cryptography

Every cipher covered since Chapter 2 — including AES and every mode in Chapters 5-6 — is symmetric: the same secret has to reach both parties before anything can happen. Chapter 1 named this "the hard problem symmetric crypto never solved," and previewed asymmetric cryptography as the eventual answer. This chapter is that answer, in full.

The Problem Symmetric Crypto Never Solved

How do two parties who have never met establish a shared secret, over a channel an eavesdropper might be listening to the entire time? Historically, the only real answer was physical: couriers, sealed codebooks, or — as Chapter 3 covered directly — Enigma's own daily key settings, physically distributed on paper to every operator in advance. That approach doesn't scale to two strangers connecting over the open internet for the first time, which is exactly the situation every HTTPS connection (https1) faces constantly.

Trapdoor Functions — The Core Idea

Asymmetric cryptography is built on trapdoor functions: a function that's easy to compute in one direction, but computationally infeasible to reverse — unless you possess a specific secret piece of information (the "trapdoor") that makes reversal easy. The public key effectively is the function itself, fully public; the private key is the trapdoor.

RSA — Trapdoors from Prime Factorization

RSA's trapdoor is built from a genuinely simple asymmetry in difficulty: multiplying two large prime numbers together is fast and easy, but factoring that product back into its two original primes is computationally infeasible once the primes are large enough (2048+ bits in practice).

• Public key — the product of the two primes (the "modulus"), plus a public exponent.
• Private key — derived using the two original prime factors, which only the key's owner knows.

Encryption and decryption both use modular exponentiation against the modulus. Knowing the two original prime factors lets you efficiently compute the specific exponent needed to reverse the operation; without them, an attacker is left facing the same hard problem — factor an enormous number — that made RSA usable in the first place.

RSA in Practice — Key Sizes & Speed

2048-bit RSA keys are the accepted minimum today, with 3072 or 4096 bits used for higher security margins. RSA is computationally expensive compared to Chapter 5's symmetric ciphers — exactly why Chapter 1 flagged asymmetric crypto as "much slower, used sparingly." In practice, RSA is typically used only to encrypt or exchange a much shorter symmetric key, after which the actual bulk data is handled by fast AES or ChaCha20 (Chapters 5-6) — precisely what https1's TLS handshake does.

Diffie-Hellman Key Exchange — A Different Approach

Diffie-Hellman (DH), published in 1976, doesn't encrypt or decrypt anything at all. It lets two parties who have never met derive an identical shared secret over a public channel, even if an eavesdropper sees every single message exchanged between them.

The real mathematics uses modular exponentiation over a large prime, and the hard problem underneath is the discrete logarithm problem: given the public values exchanged, finding either party's private exponent is computationally infeasible for large enough numbers.

RSA vs. Diffie-Hellman — Different Jobs

RSA can both encrypt data directly and produce digital signatures (Chapter 10). Diffie-Hellman solves key exchange specifically — it never encrypts a message itself, only derives a shared secret both parties can then use with a symmetric cipher.

DH's major practical advantage is forward secrecy, when used with fresh, temporary ("ephemeral") values for every session — commonly written DHE. Even if a party's long-term private key is compromised at some later date, past session keys derived via ephemeral DH cannot be recovered from that long-term key alone, since the ephemeral values used to derive them were never transmitted anywhere and are discarded immediately after use.

Elliptic Curve Cryptography (ECC) — Smaller Keys, Same Security

ECC is built on a different hard problem entirely — the elliptic curve discrete logarithm problem — believed to be considerably harder, per key bit, than either RSA's factoring problem or plain Diffie-Hellman's discrete logarithm problem. The practical payoff is dramatic: a 256-bit ECC key offers roughly the same real-world security as a 3072-bit RSA key.

Why the gap is so large: no algorithm anywhere near as effective as the best known factoring or discrete-log algorithms has ever been found against elliptic curve math, so ECC needs far fewer bits to reach an equivalent difficulty level — smaller keys, faster computation, and less bandwidth and storage, all for the same practical security. ECDH is the elliptic-curve version of Diffie-Hellman; ECDSA, the elliptic-curve signing equivalent, is covered fully in Chapter 10.

Putting It Together — What TLS Actually Does

Now fully informed, https1's handshake can be stated precisely: modern TLS 1.3 uses ECDHE (ephemeral elliptic-curve Diffie-Hellman) for key exchange, giving every session forward secrecy by default, then immediately switches to a fast symmetric AEAD cipher — AES-GCM or ChaCha20-Poly1305 (Chapters 5, 6, and 8) — for all the actual bulk data. RSA's role in modern TLS has shifted almost entirely to signing the server's certificate (Chapter 10) rather than performing the key exchange itself.

Hands-On Exercises