Public Key Cryptography Explained Simply: Keys, Ciphers, and Signatures

Cryptography sounds intimidating, but the core insight behind public key crypto is elegant and explainable without math. Once you understand the intuition, TLS, SSH, PGP, and JWT signatures all make sense as natural consequences.

The Problem: Sharing a Secret Over a Public Channel

Symmetric encryption — where both parties use the same key — works great when you can share the key in advance. But imagine you want to communicate securely with a web server you've never contacted before. You need to agree on an encryption key, but every message you send can be read by anyone on the network. How do you establish a shared secret in public?

This is the key exchange problem, and it stumped cryptographers for decades. The breakthrough came in 1976 when Whitfield Diffie and Martin Hellman published their paper introducing public key cryptography. (British intelligence had reached the same conclusion independently a few years earlier, but it wasn't disclosed until later.)

The Trapdoor Function Insight

Some mathematical operations are easy to do but hard to reverse. That's the key insight.

Multiplying two large prime numbers together is fast — even for primes with hundreds of digits, modern computers do it in microseconds. But if I give you only the result and tell you it's the product of two primes, finding those primes (factoring) takes an astronomical amount of time. There's no known algorithm that does this efficiently.

This is called a trapdoor function: easy in one direction, computationally infeasible in the other unless you know a secret shortcut (the "trapdoor").

Public key cryptography is built on trapdoor functions. The details of which function gets used depend on the algorithm, but the structure is always the same: you pick a hard mathematical problem, use properties of that problem to create a key pair, and the security relies on the intractability of the underlying problem.

RSA: The Classic Algorithm

RSA (Rivest–Shamir–Adleman, published in 1977) is built on prime factorization. Here's the intuition without the actual math:

1. Pick two large prime numbers, p and q.
2. Multiply them: n = p × q. This is easy.
3. Use p, q, and some number theory to derive a public key and a private key.
4. Publish the public key (n and a related number e). Keep the private key secret.

Anyone can encrypt a message using your public key. Decrypting requires knowing p and q — which means factoring n. For an RSA-2048 key, n is a 617-digit number. Factoring it is currently beyond any known computer. That's the security guarantee.

Modern RSA key sizes are 2048 or 4096 bits. 1024-bit RSA is considered broken and should not be used. The NIST guidelines on key management specify minimum key lengths for different security levels.

Public Key Encryption: Encrypt for a Recipient

The usage model for public key encryption:

• You publish your public key — anyone can have it, it's not a secret.
• Someone wants to send you a private message — they encrypt it using your public key.
• Only you can decrypt it — because only you have the private key.

Think of the public key as a padlock you hand out freely. Anyone can snap it shut on a message. Only you have the key to open it.

In practice, public key encryption is slow — much slower than symmetric encryption. So real systems use a hybrid approach: generate a random symmetric key, encrypt the data with that (fast), then encrypt just the symmetric key with RSA (slow but it's a small payload). This is exactly what TLS does.

Digital Signatures: Sign with Private, Verify with Public

Signatures work in reverse: you sign with your private key, and anyone with your public key can verify it.

Here's the flow:

1. You compute a hash of the data you want to sign.
2. You apply a signing operation using your private key — that's the signature. (In RSA, this is mathematically analogous to encrypting the hash; in ECDSA it involves the private key and a random nonce.)
3. The recipient verifies the signature using your public key, confirming it matches the hash of the received data.
4. If verification passes, they know the data hasn't been altered and the signature came from the private key holder.

This proves two things: the data hasn't been tampered with (integrity), and it came from whoever controls that private key (authenticity). No one else could have produced that signature without the private key.

Sign:    hash(data) → sign with private key  → signature
Verify:  signature + public key → confirm hash matches data

Digital signatures are how code signing works, how SSH host verification works, and how JWT RS256 tokens are verified.

Elliptic Curve Cryptography: Why Everything Moved to EC

RSA has a scaling problem. As computers get faster, you need larger keys to maintain security. A 2048-bit RSA key gives roughly 112 bits of security; a 3072-bit key gives 128 bits; a 4096-bit key gives roughly 140 bits. The key sizes grow much faster than the security increase.

Elliptic Curve Cryptography (ECC) uses a different trapdoor: the elliptic curve discrete logarithm problem. The details are more complex, but the payoff is dramatic — a 256-bit EC key gives roughly the same security as a 3072-bit RSA key.

Smaller keys mean:

• Faster handshakes (important for TLS)
• Less CPU usage
• Less bandwidth for certificates

This is why modern TLS certificates almost always use EC keys (specifically ECDSA), why SSH keys are now usually Ed25519 (another EC algorithm), and why modern JWTs prefer ES256 over RS256. The RFC for Ed25519 is surprisingly readable if you want the details.

Real-World Applications

TLS/HTTPS: Your browser and a web server perform a key exchange using EC Diffie-Hellman to establish a shared symmetric key. Certificates use ECDSA signatures to prove identity. See How TLS and HTTPS Work for the full handshake.

SSH: When you generate an SSH key pair, you get a private key (stays on your machine) and a public key (added to the server's authorized_keys). The server proves you're legitimate by verifying a challenge signature with your public key.

PGP/GPG: Email encryption and software signing. Public keys are shared via keyservers; private keys stay with the owner.

JWT RS256/ES256: JWTs signed with RS256 or ES256 are signed with an asymmetric private key. Any service with the public key can verify the token without being able to forge new ones — useful for microservices.

Hashing Is Not the Same Thing

Public key crypto involves hashing as a component (especially in signatures), but hashing and encryption are fundamentally different. Hashing is one-way and deterministic — you can't reverse a hash. Encryption is two-way — you can decrypt if you have the key. The Hash Generator tool is useful for exploring SHA-256, SHA-512, and MD5 hashes. For encoding data in transit, Base64 Encoder handles the encoding layer that often wraps cryptographic output.

Also worth reading: Encoding vs. Encryption vs. Hashing — these three terms get conflated constantly, and the distinction matters when you're reasoning about security.

Public key cryptography is one of those topics where the intuition makes it feel manageable even if the math is dense. The key pair model, the trapdoor insight, and the encrypt/sign duality cover 90% of what you need for practical work.