Two keys, not one
Asymmetric cryptography uses two related keys: a public key that you can share with anyone, and a private key that you must keep secret. They are mathematically linked, but the link only goes one direction: you can derive the public key from the private one, not the reverse.
That asymmetry powers two superpowers:
- Anyone can encrypt to you. They use your public key. Only you, with the private key, can decrypt.
- Only you can sign. You use your private key to produce a signature. Anyone can verify it with your public key.
The mailbox analogy
Think of a public key as a mailbox slot on a busy street, anyone can drop a letter in. The private key is the key to the back of the box, and only you have it.
Why this changed everything
Symmetric crypto is fast but needs both parties to share a key in advance. Asymmetric crypto is slow, but two strangers can use it to agree on a shared key over an open network. The web does exactly that: asymmetric crypto sets up a session, and then symmetric crypto carries the bytes.
This is also why "asymmetric is more secure than symmetric" is the wrong framing. They solve different problems. Modern systems use both.
The cast of algorithms
- RSA. Based on the difficulty of factoring very large numbers. Common for a long time; keys must be large (2048 or 3072 bits) to be secure today.
- Elliptic-curve algorithms (ECDSA, EdDSA, X25519). Much smaller keys for the same strength. The default for new systems.
- Diffie-Hellman. Not encryption, a way for two parties to agree on a shared secret over a public channel. Comes in classical and elliptic-curve forms.
- Post-quantum algorithms. Newer designs (like Kyber) that should resist a future quantum computer. Just beginning to be deployed.
Digital signatures
A digital signature is a value computed from a message and a private key. Anyone with the matching public key can verify three things at once: the signature was made with the right private key, the message has not been altered, and the signer cannot credibly deny producing it (the "non-repudiation" property).
Software downloads, package managers, code commits, container images, and the entire web's certificate chain all rely on digital signatures.
The PKI problem
Asymmetric keys solve secrecy. They don't solve identity. If you fetch a public key over the internet, how do you know it belongs to the person it claims to belong to?
The answer the web settled on is a Public Key Infrastructure: a small set of trusted
Certificate Authorities (CAs) that sign certificates. A certificate is just a public key
plus a name (like example.com) plus the CA's signature vouching that the
pair is correct.
Your browser is shipped with a list of root CAs it trusts. When you visit a site, the site presents a certificate; your browser follows the chain of signatures up to a trusted root and decides whether to believe it.
PKI is a trust shortcut
The trust is only as good as the CAs and the auditors that watch them. Real CAs have misissued certificates by mistake or under coercion. That is why modern browsers also use Certificate Transparency logs to make every issued certificate publicly visible.
Where it all shows up
- HTTPS: the TLS handshake uses asymmetric crypto to authenticate the server and agree on a session key.
- SSH: the public key you put in
authorized_keysis exactly this. - Signed software: every
apt,brew, ornpmpackage's signature. - Email: S/MIME and PGP (less common in practice, but still exist).
- Cryptocurrencies: a wallet is essentially a key pair; an "address" is derived from the public key.