I have used public-private keys for years before I could actually explain them. I generated SSH keys to push to GitHub, pasted a public key into a server, watched TLS certificates renew, verified JWTs in a backend, and signed the odd git commit. Each one felt like its own little ritual with its own rules.
Then it clicked: it is all the same three ideas. Once I could name them, every "auth thing" I run into stopped being magic and became an instance of one of three primitives. This post is that mental model, and it is the index for three deeper posts, one per primitive.
Why this is worth getting straight
If you do not have this model, three things keep happening to you.
First, you cargo-cult. You copy the SSH command, paste the public key in the right box, and it works, but you cannot reason about it. When something breaks ("permission denied (publickey)", "JWT signature invalid", "certificate not trusted") you are guessing instead of debugging.
Second, you mix up encryption and signing. This is the single most common confusion I see, and it is not pedantic. People say "the token is encrypted" about a JWT whose entire payload is sitting there in plain base64 for anyone to read. If you think a signature hides data, you will eventually put a secret somewhere it does not belong.
Third, you miss the third primitive entirely. Almost everyone knows "encrypt" and "sign". Very few engineers can name the third thing keypairs do, even though it runs at the start of every single HTTPS connection they make. Once you see it, TLS stops being a black box.
The payoff: there are only three primitives. Everything else (TLS, certificates, mTLS, SSH, passkeys, JWT, code signing, crypto wallets) is those three composed together. Learn three things, understand a hundred.
The one invariant that never changes
Before the three jobs, internalise the rule that holds across all of them:
The private key is the secret. You guard it with your life and it never leaves the machine that owns it. The public key is shareable. You can publish it, email it, put it in DNS, hand it to every server in your fleet, and it being "stolen" changes nothing.
That asymmetry (one secret half, one public half, mathematically bound together) is the whole trick. Everything below is just a question of which half does what, and in which direction.
One more thing the invariant kills: a single private key does not hand out many public keys. A keypair is exactly one private key bound to exactly one public key. What a private key produces without limit is signatures, not more public keys. If you want another public key, you generate another keypair.
The three jobs
The three things a keypair can do, and the direction each one runs
1. Encryption: keep data secret
The public key encrypts; the private key decrypts. Anyone can scramble a message to you using your public key, but only your private key can unscramble it. Direction: public to private.
This is the one most people picture when they hear "public key crypto". It answers: how do I send you something only you can read?
2. Signing: prove authenticity
The private key signs; the public key verifies. Only the holder of the private key can produce a valid signature, and anyone with the public key can check it. Direction: private to public, the exact reverse of encryption.
It answers a different question: who sent this, and was it tampered with? A JWT, a signed git commit, an SSH login, a TLS certificate, an App Store binary: all signatures.
3. Key exchange: agree on a shared secret over an open wire
Two parties combine their key material to independently compute the same secret number, without ever sending that secret across the network. Nobody watching the wire can derive it. They then use that shared number as a fast symmetric key.
It answers: how do two strangers on a public network end up with a shared secret? This is the Diffie-Hellman idea, and it is the part of every HTTPS handshake you never see.
The flip that trips everyone up
Encryption and signing use the same keypair in opposite directions. This table is worth memorising, because it is the source of nearly every "wait, which key does what" moment:
| Operation | Done with | Checked / undone with | Answers |
|---|---|---|---|
| Encryption | public key | private key | keep it secret |
| Signing | private key | public key | prove who sent it |
If the public key could sign, signing would be worthless: everyone has the public key, so anyone could forge. The whole model is one secret signer, many public verifiers for signing, and many public senders, one secret reader for encryption.
Where you actually meet these
Almost every "security thing" in a normal SWE setup is one of the three primitives wearing a costume. Once you can map the tool to the primitive, it stops being mysterious:
| You use | Primitive underneath |
|---|---|
| TLS / HTTPS | key exchange (session key) + signing (cert proves the server) + symmetric (bulk data) |
| Certificates / PKI / a CA | signing (the CA signs your cert, forming a chain of trust) |
| mTLS (service-to-service) | signing (each side proves identity with a cert) |
| SSH key login | signing (your client signs a challenge, server verifies) |
| Git commit / tag signing | signing |
| Passkeys / WebAuthn / FIDO2 | signing (your device signs a challenge, no password) |
| JWT / OIDC / SAML | signing |
| Code signing (Apple notarization, APK, npm provenance, cosign) | signing |
| DKIM (email anti-spoofing) | signing (verified via a public key in DNS) |
| Crypto wallets / blockchain | signing (your address is derived from your public key) |
| End-to-end messaging (Signal, iMessage, PGP) | key exchange + signing + encryption together |
| KMS / envelope encryption / encrypted files | encryption (but hybrid, see below) |
Notice how much of that list is signing. Authenticity ("is this really from who it claims") turns out to be the workhorse, far more than confidentiality.
Almost nothing encrypts data with asymmetric keys directly
One practical truth ties the whole picture together: asymmetric crypto is slow, so you rarely use it to encrypt real data. The standard move is hybrid (envelope) encryption:
- Generate a random symmetric key (fast, e.g. AES).
- Encrypt the actual payload with that symmetric key.
- Encrypt just the small symmetric key with the recipient's public key.
TLS, PGP, AWS KMS, disk encryption: all do a version of this. So "encryption" in the wild almost always means asymmetric to protect the key, symmetric to protect the data. Keep that in your pocket; it explains why TLS can be both secure and fast.
Read next
This post is the map. Each primitive gets its own deep-dive:
- Public-Key Encryption: how asymmetric keys keep secrets covers the encrypt-to-public, decrypt-with-private flow, why it is slow, and the envelope trick every real system uses.
- Digital Signatures: from JWT to JWKS to key rotation goes deep on sign-with-private, verify-with-public, then follows it all the way into JWTs, the JWKS keyring, the
kidheader, and how keys rotate with zero downtime. - Key Exchange: the crypto primitive you use but never see explains how two strangers agree on a shared secret over an open wire, and why it sits at the front of every HTTPS handshake.
And one level up from the crypto, a companion piece: OAuth2 vs OIDC vs SAML vs LDAP vs SCIM maps the auth protocols that produce and exchange the signed tokens these primitives secure.
Three primitives. Private stays secret, public is shareable, and the operation just flips direction depending on whether you want secrecy or proof. That is the whole foundation.