How encryption keeps messages secret
A Socratic walk-through of how encryption keeps messages secret — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #How does encryption keep messages secret?
To send someone a secret, it seems you must first share a secret way to unlock it — but if you could share that safely, why not just send the message safely in the first place? How can two strangers agree on a secret over a line everyone can hear?
Reasoning it through
REASONING #Notice the asymmetry we want: anyone should be able to lock a message for you, but only you should be able to unlock it. Locking and unlocking would then be different acts, needing different keys. Could a lock exist that anyone can snap shut, yet only one person can open?
Put like that it sounds like wishing, so ask what such a lock would be made of. It needs an operation cheap to perform, ruinously expensive to undo, and cheap to undo again if you hold one extra piece of information — a one-way street with a private back gate. Does anything in mathematics behave like that? Multiplication does. Multiply two large primes and a computer does it instantly; hand somebody the product alone and ask which primes made it, and no known method avoids an enormous search. A 250-digit number set as a public challenge held out until 2020, and the team that finally split it spent on the order of 2,700 processor-years doing so — while the numbers protecting your bank connection are considerably larger. The product can be published; the primes are the back gate.
So we have our lock. Does that finish the job? Try to use it in earnest and two problems surface at once.
The first is cost. Public-key operations are slow next to ordinary shared-key ciphers, and can only handle a block about the size of the key itself; encrypting a video call this way would be absurd. But notice what actually has to travel secretly: not the conversation, only a secret. So use the expensive lock once, to agree on a short random key, then run everything else through a fast shared-key cipher with it. That is what your browser really does — the public-key part of an HTTPS connection is a brief negotiation at the start, not the thing carrying your traffic.
The second problem is worse, because no arithmetic touches it. Suppose an eavesdropper does not merely listen but intercepts — catches the public key you were sent, substitutes their own, and passes your reply along re-encrypted with the real one. Every lock worked perfectly, both ends are satisfied, and the whole conversation is read. What could detect that? Nothing inside the mathematics: the message was locked correctly, just to the wrong person. The only escape is to import trust from outside the exchange — someone you already trust vouching that this key belongs to that name. That vouching, signed and checkable, is a certificate, and it is why your browser ships with a list of authorities it will believe.
The analogy
THE ANALOGY #Picture a mailbox on the street. It has a slot anyone can drop a letter through — that slot is public, and using it "locks" the letter inside. But the little door that lets you take letters out has a key only you hold. Strangers can send you secrets all day using the public slot; none of them, nor any passer-by, can read what is inside. And in practice the thing posted through the slot is rarely the message — it is the key to a padlock the two of you then use for everything that follows, the slot being a narrow and laborious way to move anything large.
A mailbox on the street tells you whose it is. Online, nothing stops a stranger putting up a slot with your name on it — so the picture quietly omits the hardest part of the whole business: proving that a public key really belongs to the person you think it does.
Clarifying the model
THE MODEL #So there are two keys, not one: a public key you hand out freely (the slot) and a private key you never share (the door key). A message locked with your public key can be opened only by your private key. Nothing secret ever had to travel the open line — the private key stayed home the whole time.
Three things commonly get misread. The first is that this is what encrypts your data; it usually is not. Public-key cryptography is almost always used to establish a shared secret, and the bulk of the traffic is then protected by a symmetric cipher with that key. Modern connections often go further and never send the key at all — both sides derive the same value from public exchanges neither could compute alone, so even a private key stolen years later will not unlock a recorded conversation.
The second is that "unbreakable" means "not breakable in the time available". None of this rests on proof; it rests on no efficient factoring method having been found, which is not the same as none existing — a reasonable bet on an open mathematical problem, and still a bet.
The third is treating secrecy as the goal. A confidential channel to an impostor is worth nothing, which is why real systems spend so much of their complexity on identity, and why most practical failures are failures of that machinery rather than of the ciphers.
A word, finally, on quantum computers, since the topic invites more confidence than the situation supports. Shor's algorithm would factor large numbers efficiently on a quantum machine, ending RSA and the elliptic-curve schemes together — but no machine near that scale exists, and nobody credible will tell you when one will. Shared-key ciphers are far less exposed, and mostly answered by longer keys. The practical response is already underway: standard replacements built on different mathematics were published in 2024 and are being rolled into browsers now, partly because anything recorded today could be decrypted whenever such a machine arrives.
A picture of it
THE PICTURE #How to readTime runs downward, and the eavesdropper is drawn as a full participant rather than a threat off to one side — assume they see everything on the wire, because they do. Read the two notes over E: they hold the key and the message and are still stuck. The reason is the first arrow, where the key that travels is the locking one. Everything that crosses the line is public by design; the only thing that can undo the lock is the one item that never moves. One caution: E is drawn as a listener. Redraw E sitting on the first arrow, handing over a substituted key, and every later step still succeeds — which is the man-in-the-middle problem, and the reason certificates exist.
What became clearer
WHAT CLEARED #Encryption need not require a pre-shared secret. By splitting locking from unlocking into a public and a private key, strangers can send you messages no eavesdropper can read, over a line everyone can hear. The split rests on operations easy one way and impractical to reverse — impractical, not impossible — and it is used in practice to agree on a fast shared key rather than to carry the conversation itself. What it cannot do alone is tell you whose slot you posted into, and that is where nearly all the real difficulty lives.
Where to go next
ONWARD #- How the same key pair also lets you sign a message to prove it came from you.
- Why the private key's secrecy is the whole game — and what happens if it leaks.
- What goes wrong when a certificate authority is compromised.
Key terms
TERMS #| Term | What it means |
|---|---|
| Public key | a freely shared key used to encrypt messages to you (the mail slot). |
| Private key | a secret key only you hold, used to decrypt (the door key). |
| Trapdoor function | an operation easy to compute and infeasible to reverse, unless you hold one extra secret. |
| Symmetric cipher | an ordinary shared-key cipher, fast enough to carry the traffic once a key has been agreed. |
| Man-in-the-middle | an interceptor who substitutes their own public key, so both ends encrypt correctly to the wrong recipient. |
| Certificate | a signed statement from a trusted party binding a public key to an identity. |
Every term the collection defines is gathered in the glossary.