What is public-key cryptography?

Until 1976, encrypting a message required both sides to already share a secret. Public-key crypto broke that chicken-and-egg problem and quietly became the substrate of the modern internet.

Security intro Apr 30, 2026

Why it exists

For most of cryptography’s history, “encrypt a message” meant: pick a key, share it with the other party through some out-of-band channel (a courier, a codebook, a face-to-face meeting), and use that same key on both ends. This is symmetric crypto, and it has a built-in problem the moment your partner is someone you’ve never met: you can’t share a secret over a channel that requires already sharing a secret. Diffie and Hellman named this directly in their 1976 paper New Directions in Cryptography, and proposed the first construction that escapes it. The following year, Rivest, Shamir, and Adleman published RSA (paper in 1978), which added the second half of the picture: digital signatures. Together those two results invented asymmetric crypto.

Why it matters now

Almost every secure thing your computer does today rides on it: every TLS handshake your browser performs, every SSH session, every signed software package (apt, container images, model checkpoints), every passkey login, every Git commit signed by a maintainer, every CA stamp on a domain. If asymmetric crypto vanished overnight the public internet would stop working. It is the layer underneath the layer most engineers think about.

The short answer

public-key crypto = a key pair (public, private) + math designed so the public key can encrypt-to or verify, but only the private key can decrypt or sign

You generate two keys at once, mathematically linked. One you publish; one you guard. The two halves play different roles:

Encryption to a recipient — anyone with your public key can encrypt a message that only you, the private-key holder, can read.
Signature — only you can produce a signature that anyone with your public key can verify.

That asymmetry is the whole trick. The companion post signatures vs encryption explains why those operations are not the same primitive run in opposite directions; here we’ll take the conceptual shape as given.

How it works

You don’t need the number theory to use this, but you need the right metaphor. The one that survives contact with reality is the trapdoor function: easy to compute forward, infeasibly hard to invert — unless you know a particular secret (the private key), in which case inverting is easy too.

Two families dominate:

RSA uses modular exponentiation. The trapdoor: multiplying two large primes is easy, factoring the resulting semiprime is believed to be hard at the sizes used (2048+ bits). The private key is, essentially, knowledge of the factorization.
ECC uses elliptic-curve algebra. The trapdoor is the elliptic-curve discrete log problem: given P and Q = k·P, recovering k is believed to be hard. ECC gets equivalent security at much smaller key sizes (a 256-bit ECC key is roughly comparable to a 3072-bit RSA key), which is why most new protocol designs reach for it.

The detail almost everyone gets wrong on first encounter: public-key crypto is almost never used to encrypt the actual data. It’s slow, and the math has sharp edges on large or structured inputs. Real systems use hybrid encryption: generate a fresh symmetric key, encrypt the bulk payload with that (AES-GCM or similar), and use public-key crypto only to encrypt — or, more commonly, agree on — that symmetric key. TLS works exactly this way.

Show the seams

The math is hard; the interface is the part to internalize. You will almost never implement RSA or ECC yourself, and shouldn’t. What you need is a clear mental model of who holds which key and what each key can do.
Quantum computing breaks the current schemes. Shor’s algorithm, on a sufficiently large quantum computer, factors integers and computes discrete logs in polynomial time — which kills both RSA and ECC. Post-quantum cryptography (lattice-based schemes like ML-KEM, hash-based signatures) is an active migration; major TLS stacks have begun rolling out hybrid post-quantum key exchange, but I don’t have a confident current adoption figure.
Key management is the real problem. The math is the easy part. Losing a key, leaking it, rotating it, deciding whose public key to trust — that’s where almost all real-world failures live. Certificates and CAs exist because “here is a public key” is useless until you know whose.

Key exchange (Diffie-Hellman, ECDH) — key exchange = derive a shared secret over a public channel — Diffie-Hellman (DH) and its elliptic-curve variant ECDH are how two parties end up with the same symmetric key without ever sending it.
Signatures vs encryption — signatures ≈ private key proves authorship; encryption ≈ public key hides contents — same key shape, different questions; covered in signatures vs encryption.
TLS — TLS ≈ certificate-checked key exchange + hybrid encryption — see TLS.
HTTPS certificate — cert ≈ public key + identity + CA's signature — see HTTPS certificates.
Passkey — passkey ≈ per-site key pair stored in a secure enclave — see passkeys.
Hybrid encryption — hybrid = public-key wrap of a fresh symmetric key + symmetric encryption of the bulk — what TLS, age, and most file-encryption tools actually do.
Post-quantum / lattice-based — post-quantum ≈ public-key schemes whose hardness assumption survives a large quantum computer — lattice problems, code-based schemes, and hash-based signatures are the leading families. Honest gap: I don’t have reliable current production-adoption numbers.

Going deeper

Diffie & Hellman, New Directions in Cryptography (1976) — the paper that started the field. Worth reading once just to feel how recent this all is.
Rivest, Shamir & Adleman, A Method for Obtaining Digital Signatures and Public-Key Cryptosystems (1978) — the RSA paper.
Dan Boneh, A Graduate Course in Applied Cryptography (free PDF) — the modern reference for how this stuff actually fits together.
Cryptography Engineering (Ferguson, Schneier, Kohno) — practitioner angle on why “don’t roll your own” is a load-bearing rule, especially at the boundary between encryption and signatures.