Public-key cryptography, explained without the maths degree

Imagine you made a special padlock. You hand out thousands of copies of that padlock — open and unlocked — to everyone in the world. You keep the one key that closes and opens it.

If your friend wants to send you a secret message, they put it in a box and snap your padlock shut. Now nobody can open it — not even your friend — except you, because only you have the key.

That padlock is your public key. The key in your pocket is your private key. The maths that makes such a magical padlock possible is called public-key cryptography.

Before public-key cryptography existed, every pair of people who wanted to communicate privately needed to share the same secret key in advance — and share it safely, without anyone eavesdropping. With millions of users on the internet, that is an impossible logistics problem.

Public-key (asymmetric) cryptography solves this by giving everyone a key pair: a public key you share freely, and a private key you never reveal.

The pair has two distinct uses:

• Confidentiality — Anyone who wants to send you a secret message encrypts it with your public key. Only your private key can decrypt it.
• Authenticity / integrity — You sign data with your private key. Anyone who has your public key can verify the signature and know the data came from you and has not been altered.

Common algorithms you will meet: RSA (the classic choice, based on the difficulty of factoring large numbers) and ECC (elliptic-curve cryptography, which achieves the same strength with much smaller keys).

Let us look at each operation in turn, then see how real protocols stitch them together.

Symmetric vs asymmetric — a quick comparison

Digital signatures sign a hash, not the raw message

Signing a large document directly with RSA or ECC arithmetic would be impractically slow. Instead, the signer first runs the message through a cryptographic hash function (e.g. SHA-256) to produce a short, fixed-length digest, then signs the digest. The verifier hashes the received message independently and checks the signature against that hash.

Hybrid encryption — why real systems combine both

Because asymmetric operations are slow, real protocols never use them to encrypt bulk data. Instead they use hybrid encryption:

1. Generate a random session key (a symmetric key, e.g. 256 bits of AES key material).
2. Encrypt the session key with the recipient's public key (small, fast enough).
3. Encrypt all payload data with the session key using AES-GCM or ChaCha20-Poly1305.
4. The recipient decrypts the session key with their private key, then decrypts the payload.

Diffie-Hellman key exchange

Sometimes you do not want to encrypt a session key with a static public key — you want both sides to agree on a shared secret without either one choosing it unilaterally. That is Diffie-Hellman (DH). Both parties contribute randomness; an eavesdropper who sees all the messages cannot reconstruct the secret.

The network sees both public values but cannot compute the shared secret without knowing either private exponent — that is the discrete logarithm problem.

RSA vs ECC

Certificates and PKI — binding a public key to an identity

A bare public key tells you nothing about who owns it. A certificate is a digitally signed document that binds a public key to a name (domain, person, or organisation). The signature comes from a Certificate Authority (CA) whose own public key you already trust.

This chain of trust is the Public Key Infrastructure (PKI). Your browser ships with about 150 trusted root CAs; every TLS certificate on the web chains up to one of them. For a deep walkthrough of how TLS uses all this during connection setup, see the TLS handshake article.

Forward secrecy via ephemeral Diffie-Hellman (ECDHE)

In classic RSA key exchange, the server's long-lived private key is used to decrypt each session key. If that private key is later compromised, an adversary who recorded past traffic can decrypt it all retroactively.

Ephemeral Diffie-Hellman eliminates this. Both sides generate a fresh DH key pair for each session; the shared secret is derived through DH and neither side's long-term key can decrypt it later. TLS 1.3 mandates ECDHE — static RSA key exchange is gone.

Real-world uses across infrastructure

• TLS — ECDHE for key agreement, ECDSA or RSA certificate for server authentication, AES-GCM for data.
• SSH — Ed25519 or RSA key pair authenticates the user; the server is authenticated by its host key (checked against ~/.ssh/known_hosts).
• Signed packages/software — RPM, DEB, and container image manifests carry signatures; your package manager verifies them before install.
• Git commit signing — git commit -S attaches a GPG or SSH signature to the commit object; git log --show-signature verifies it.
• JWT signing — RS256 (RSA) or ES256 (ECDSA) JWTs let a verifier check token authenticity using only the issuer's public key.
• Kerberos PKINIT — smart-card and certificate-based Kerberos initial authentication uses the client's certificate private key in place of a password; see the Kerberos article.

Protecting and managing private keys

The private key is the crown jewel. If it is compromised, an attacker can impersonate you, decrypt historical traffic (if forward secrecy is not in use), and forge signatures. Treat it accordingly:

• Passphrase-protect private keys at rest. SSH keys encrypted with ssh-keygen -a 100 use 100 rounds of bcrypt for the passphrase KDF. OpenSSL private keys use AES-256-CBC by default.
• Use an ssh-agent or GPG agent so the passphrase is entered once per session and the raw key material stays in memory, not on disk repeatedly.
• Hardware security modules (HSMs) and security keys (YubiKey, etc.) store the private key in tamper-resistant hardware; signing operations happen inside the device — the key never leaves.
• Rotate keys proactively, not just after suspected compromise. TLS certificates have explicit expiry; SSH host keys and code-signing keys should have a documented rotation policy.
• Revocation — for TLS: CRL or OCSP stapling. For PGP: upload a revocation certificate to keyservers before you lose access. For SSH: AuthorizedKeysFile or an AuthorizedKeysCommand that centralises trust.

The quantum threat

Shor's algorithm, running on a sufficiently powerful quantum computer, can solve integer factorisation (breaks RSA) and the discrete logarithm problem (breaks DH, DSA, and ECC) in polynomial time. A cryptographically relevant quantum computer does not yet exist, but nation-state adversaries are almost certainly conducting harvest-now, decrypt-later attacks — recording encrypted traffic today to decrypt once a quantum computer is available.

Post-quantum cryptography (PQC)

NIST finalised its first PQC standards in 2024:

• ML-KEM (formerly CRYSTALS-Kyber, FIPS 203) — lattice-based key encapsulation mechanism; replaces DH/ECDH for key agreement.
• ML-DSA (formerly CRYSTALS-Dilithium, FIPS 204) — lattice-based digital signature; replaces RSA/ECDSA.
• SLH-DSA (formerly SPHINCS+, FIPS 205) — hash-based signature scheme; conservative fallback with no lattice assumptions.

TLS 1.3 implementations are beginning to support X25519MLKEM768 hybrid key exchange, which combines classical ECDH with ML-KEM so that a classical or quantum attacker would need to break both. Chrome and Firefox already negotiate this with supporting servers.

Practical migration checklist:

1. Inventory all systems using RSA or ECC for key exchange or signatures — TLS endpoints, SSH servers, code-signing pipelines, JWTs.
2. Prioritise enabling forward secrecy (ECDHE) everywhere today — it limits the value of harvest-now attacks regardless of future quantum capability.
3. Track OS/library PQC support: OpenSSL 3.x, Go, and the major cloud providers already offer hybrid or pure PQC options.
4. Plan for larger key and signature sizes (ML-DSA signatures are ~2.4 kB vs ~64 bytes for Ed25519) — review MTU, certificate chain size limits, and any fixed-size buffers.
5. Benchmark ML-KEM and ML-DSA on your hardware; performance is generally acceptable but may surprise you on constrained devices.

Troubleshooting common public-key problems

A useful sanity-check tool when debugging hash or signature problems is the hash generator, which lets you compute SHA-256 and other digests interactively.