What is public-key cryptography?

Until 1976, published cryptography 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.

The picture version

Five pictures for a reader who has never met the idea, following one ordinary moment: your laptop, your bank, and a hotel Wi-Fi network run by strangers.

Why it exists

You type your bank’s address into a browser on hotel Wi-Fi. A padlock appears, and within a few hundred milliseconds you’re typing a password into a page you trust. You and your bank have never met, never agreed on a password for the connection itself, and every byte between you just crossed a network run by strangers — including whoever else is on that hotel Wi-Fi. Somehow the two of you now share a secret that none of them have.

That’s the running example for this post: your laptop, your bank, and a network you don’t trust in between.

For most of cryptography’s history this was flatly impossible. “Encrypt a message” meant: pick a key, get it to the other party through some out-of-band channel — a courier, a codebook, a meeting in person — and use that same key on both ends. This is symmetric crypto, and it has a chicken-and-egg 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. Your bank cannot courier a codebook to every customer.

Diffie and Hellman named this directly in their 1976 paper New Directions in Cryptography, and gave the first published construction that escapes it — two parties agreeing on a shared secret over a channel everyone can hear. They also framed the authentication side, arguing that a public-key cryptosystem could be turned into a one-way authentication system, though without the concrete signature scheme people would end up using. Rivest, Shamir, and Adleman worked that out in 1977 and published it in 1978 as RSA. Together those results built asymmetric crypto in the open literature.

Why it matters now

The padlock is only the visible instance. Almost every secure thing your computer does rides on the same primitive: every TLS handshake, every SSH session, every signed software package (apt, container images, model checkpoints), every passkey login, every Git commit signed by a maintainer, every certificate authority stamp on a domain. Remove asymmetric crypto and there is no general way for two parties who haven’t met to start a private, authenticated conversation — which is the assumption nearly all of the above is built on. It’s the layer underneath the layer most engineers think about, which is exactly why it’s worth understanding once rather than trusting blindly forever.

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

Picture to keep: a mailbox bolted to a public street. Anyone walking past can drop a letter through the slot; only the person with the key on their keyring can open the front and take the letters out. The slot is the public key, the keyring is the private key — and handing out slots costs you nothing.

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.
• Key agreement — you and a stranger each combine your own private key with the other’s public key and land on the same secret, without that secret ever crossing the wire. This is the one that answers the hotel-Wi-Fi question, and it’s what your browser actually did.

That asymmetry is the whole trick. The companion post signatures vs encryption explains why encrypting and signing aren’t one primitive run in opposite directions; here we take the shape as given.

How it works

Follow the problem forward and the design builds itself. Your laptop wants to send your bank a secret over hostile Wi-Fi.

Naive attempt: agree on a key first. Symmetric encryption is fast and well-understood, so just pick a key and send it to the bank.

Why it breaks: you’d have to send the key over the same hostile network, where anyone listening now has it. Encrypting the key requires a key. You’re back where you started.

Fix 1: make the two directions different. What you need is an operation that everyone can perform but only one person can undo. That’s a trapdoor function: easy forward, infeasibly hard to invert — unless you hold a particular secret, in which case inverting is easy too. Publish the forward direction as your public key; keep the trapdoor as your private key. Two families supply one:

• RSA uses modular exponentiation. Multiplying two large primes is easy; factoring the result is believed hard at the sizes used (2048 bits and up). The private key is, in essence, knowing the factorization.
• ECC uses elliptic-curve algebra, where the hard problem is the discrete log: given P and Q = k·P, recovering k is believed hard. ECC gets comparable security at far smaller key sizes — a 256-bit ECC key is roughly in the class of a 3072-bit RSA key — which is why most new protocol designs reach for it.

Note the load-bearing word in both: believed. Nobody has proved factoring or discrete log is hard. We have decades of very motivated people failing to make them easy, which is a different and weaker kind of assurance.

Fix 2: don’t actually encrypt your data with it. Here’s the detail almost everyone gets wrong on first encounter — public-key crypto is almost never used to encrypt the real payload.

Why the naive version breaks: it’s slow, by orders of magnitude, and the math has sharp edges on large or structured inputs. Encrypting a 4 MB page directly with RSA is both impractical and a good way to introduce a vulnerability.

The fix — hybrid encryption: generate a fresh random symmetric key, encrypt the bulk payload with that (AES-GCM or similar), and use public-key crypto only to encrypt — or, more commonly these days, to agree on — that one small key. The slow asymmetric math runs once over a few hundred bytes; the fast symmetric cipher does the heavy lifting. This is precisely what your browser and your bank did during the handshake.

Fix 3: figure out whose key it is. Now your laptop can encrypt to a public key nobody can reverse. But the hotel Wi-Fi handed you that public key.

Why it breaks: whoever runs that network could have substituted their own key, read everything, and re-encrypted it onward to the bank. The math worked perfectly and you had a private conversation with the wrong party. “Here is a public key” is worthless until you know whose it is.

The fix: certificates and certificate authorities — a public key bundled with an identity and signed by someone your browser already trusts. That’s a different post (HTTPS certificates), but it’s the reason the padlock means anything at all.

Show the seams

• The mailbox analogy breaks at signatures. A street mailbox is a fine picture for encryption — anyone can put something in, one person takes things out. Except it says nothing about the other half of the pair, where the private key is used to produce something the whole world checks. There’s no mailbox that does that. Don’t stretch the picture; hold two pictures.
• 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 model of who holds which key and what each key can do.
• Diffie and Hellman may not have been first. Declassified GCHQ documents credit James Ellis with the concept (“non-secret encryption”) in 1970, Clifford Cocks with an RSA-equivalent scheme in 1973, and Malcolm Williamson with a key-exchange equivalent around 1974. Classified, unusable, and unpublished until 1997 — a reminder that “invented” and “published” aren’t the same event.
• Quantum computing breaks the schemes in use today. Shor’s algorithm, on a sufficiently large quantum computer, factors integers and computes discrete logs in polynomial time — killing both RSA and ECC. Post-quantum cryptography is an active migration: the major browsers now turn on hybrid post-quantum key agreement by default, and the share of live traffic using it is a moving number best read off an operator that publishes it — such as Cloudflare Radar — rather than frozen into a sentence here. See why post-quantum crypto matters.
• 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 nearly all real-world failures live.

You started with public-key crypto = a key pair + math where the halves do different jobs. What did the walk from your laptop to your bank add? — + a symmetric key doing the actual encrypting — agreed on rather than sent — and a certificate answering "whose public key is this?". The asymmetric math is the smallest part of the system by volume, and it’s load-bearing anyway: it’s the only piece that lets two strangers start from nothing.

Famous related terms

• Key exchange (Diffie-Hellman, ECDH) — key exchange = derive a shared secret over a public channel — DH and its elliptic-curve variant ECDH are how two parties end up with the same symmetric key without ever sending it.
• Hybrid encryption — hybrid = asymmetric step for one small key + symmetric encryption of the bulk — what age and most file-encryption tools do by wrapping a key; TLS 1.3 reaches the same place by agreeing on one via Diffie-Hellman rather than wrapping it.
• Signatures vs encryption — signature ≈ private key proves authorship; encryption ≈ public key hides contents — same key shape, opposite questions; see signatures vs encryption.
• TLS — TLS ≈ certificate-checked key exchange + hybrid encryption — the protocol behind the padlock; see TLS.
• HTTPS certificate — cert ≈ public key + identity + CA's signature — Fix 3, made concrete; see HTTPS certificates.
• Passkey — passkey ≈ per-site key pair the site never gets the private half of — signatures replacing passwords; the private half may live in dedicated hardware or in an end-to-end-encrypted keychain that syncs across your devices, and most passkeys today are the synced kind. See passkeys.
• Post-quantum / lattice-based — post-quantum ≈ public-key schemes whose hardness assumption survives a large quantum computer — lattice, code-based, and hash-based families are the leading candidates.

Going deeper

• Diffie & Hellman, New Directions in Cryptography (1976) — for the question “what exactly was impossible before, and what did the first escape look like?”; short, readable, and startlingly recent.
• Dan Boneh & Victor Shoup, A Graduate Course in Applied Cryptography (free PDF) — for the question “how do these primitives actually fit together into protocols?”, if you want the real treatment rather than the intuition.
• Rivest, Shamir & Adleman, A Method for Obtaining Digital Signatures and Public-Key Cryptosystems (1978) — the rabbit hole: for the question “what does a trapdoor actually look like written down?”, it’s about four pages of arithmetic.