How Public-Key Cryptography Works

You use public-key cryptography thousands of times a day without noticing. It runs every time you load a site over HTTPS, log into a server over SSH, or install signed software. It solved a problem that had no good answer for most of recorded history, and the idea behind it is genuinely elegant once you strip away the math. You do not need to follow the equations to understand what it does and why it works.

The problem: sharing a secret you cannot share

Classic encryption is symmetric. Both sides use the same secret key, one to lock the message and the same one to unlock it. This works fine if the two parties can agree on that key privately. The trouble is agreeing on it.

Imagine you want to send an encrypted message to someone you have never met, over the open internet, where anyone might be listening. To encrypt it, you both need the shared key. To share the key, you need a secure channel. But a secure channel is exactly the thing you do not have yet, which is why you wanted encryption in the first place. This is the key distribution problem, and for centuries the only answer was to meet in person or trust a courier.

The breakthrough: two keys instead of one

Public-key cryptography, also called asymmetric cryptography^[1], replaces the single shared key with a pair of mathematically linked keys. One is public and one is private.

You generate the pair together. You publish the public key to the whole world and keep the private key secret, known only to you. The two are linked so that what one key locks, only the other can unlock. They are not interchangeable, and critically, you cannot work out the private key from the public one in any practical amount of time.

Two things the key pair lets you do

That one arrangement gives you two abilities that look different but come from the same idea.

The first is encryption. If someone wants to send you a private message, they encrypt it with your public key, which anyone can get. Once encrypted, only your private key can decrypt it. The sender never needs to share a secret with you beforehand, which solves the distribution problem directly.

The second is digital signatures, which work in the other direction. You encrypt, or more precisely sign, something with your private key. Anyone can verify it using your public key. Because only you hold the private key, a valid signature proves the message came from you and was not altered in transit. Encryption keeps a message secret. A signature proves who sent it and that it is intact^[2].

The intuition: easy one way, hard to reverse

The whole thing rests on functions that are easy to compute in one direction and extremely hard to reverse without a secret. These are called trapdoor functions^[3].

The classic example is multiplication versus factoring. Multiplying two very large prime numbers together is fast, even for numbers hundreds of digits long. Taking the result and working backward to find the two original primes is, as far as anyone knows, hopelessly slow without extra information, even for the fastest computers. The RSA algorithm builds on exactly this gap^[4]. A newer family based on elliptic curves uses a different hard-to-reverse operation^[5] and gets the same security with much smaller keys, which is why most modern systems have moved to it. You do not need the equations. The point is that the math makes going forward cheap and going backward impractical, and your private key is the shortcut that lets you go backward.

Why it works with symmetric crypto, not instead of it

Public-key operations are slow, far slower than symmetric ones^[6], so you would not want to encrypt a large file or a whole web session with them directly. In practice they are used to bootstrap, not to carry the load.

1. Use public-key crypto to agree on a fresh shared secret.
2. Switch to a fast symmetric cipher using that secret.
3. Encrypt the actual conversation with the fast cipher.

This is essentially what happens in the first moments of an HTTPS connection, the TLS handshake^[7]. The two sides use asymmetric cryptography to safely establish a shared symmetric key, then use that fast key for the rest of the session. You get the convenience of public keys and the speed of symmetric encryption together.

Where you meet it every day

HTTPS is the obvious place. The padlock in your browser means the site presented a certificate containing its public key, and your browser used public-key cryptography to verify the site and set up an encrypted channel. Certificates are vouched for by certificate authorities^[8], trusted third parties whose job is to confirm that a given public key really belongs to a given site, which addresses the question of how you trust a public key you just received.

SSH uses key pairs so you can log into a server^[9] by proving you hold the matching private key, no password required. Software and, increasingly, source code commits are signed so you can verify they came from who they claim and were not tampered with. Cryptocurrencies use signatures to prove ownership of funds without any central authority.

The idea that you can hand your lock to the entire world and still be the only one who can open it is counterintuitive the first time you hear it. It took until the 1970s for anyone to make it work in public, and it reshaped what computers could safely do with strangers. Every private thing you do online rests on it, usually without a moment's thought, which is the mark of infrastructure that works.