How Public-Key Cryptography Actually Works

Every time you SSH into a server or load an HTTPS site, two mathematically linked keys do the heavy lifting. One is public, one is private, and the relationship between them is what makes secure communication over an untrusted network possible in the first place.

The basic idea

With symmetric encryption, one key both locks and unlocks the data. That works fine if both parties already share a secret, but distributing that secret safely is the hard part. Public-key (asymmetric) cryptography solves this by generating a mathematically related pair: a public key you hand out to anyone, and a private key you never share.

Data encrypted with the public key can only be decrypted with the matching private key. Data signed with the private key can be verified by anyone holding the public key. Those two properties cover almost everything we use this for: confidentiality and authentication.

RSA, the classic example

RSA relies on the fact that multiplying two large primes is fast, but factoring the product back into those primes is computationally brutal at scale. A 2048-bit RSA key is built from two primes roughly 1024 bits each. The public key is (n, e) — n being the product of the primes, e a fixed exponent like 65537. The private key is derived using the totient of n and involves knowing the original primes.

Encryption is modular exponentiation: c = m^e mod n. Decryption reverses it with the private exponent d: m = c^d mod n. Nobody's actually encrypting large payloads directly with RSA in practice, though — it's slow and has size limits tied to the key length. Instead, RSA typically wraps a symmetric session key (AES-256, for instance), and the symmetric cipher handles the bulk data. That's the hybrid approach TLS uses.

Elliptic curve cryptography and why it's taking over

ECC gets you equivalent security to RSA with much smaller keys. A 256-bit ECC key (like curve secp256r1 or Curve25519) is roughly comparable in strength to a 3072-bit RSA key. Smaller keys mean faster handshakes and less bandwidth, which is why modern TLS configs, SSH implementations, and Signal's protocol all lean on ECC.

The math is different — it's based on the discrete logarithm problem over points on an elliptic curve rather than integer factorization — but the public/private key relationship and the guarantees are conceptually the same.

Digital signatures: the other half of the equation

Encryption keeps data confidential. Signatures prove authenticity and integrity. To sign a message, you hash it (SHA-256, typically) and encrypt that hash with your private key. Anyone with your public key can hash the message themselves, decrypt your signature, and check the two hashes match.

This is exactly what happens when you run git commit -S with a GPG key, or when a Certificate Authority signs a TLS certificate. The CA's private key signs your cert; browsers ship with the CA's public key pre-trusted, so they can verify your cert's authenticity without ever talking to the CA directly.

Where this shows up day to day

SSH key auth is a direct application: ssh-keygen -t ed25519 generates a key pair, you drop the public half into ~/.ssh/authorized_keys on the server, and authentication happens through a challenge-response using the private key, no password ever transmitted.

TLS handshakes use asymmetric crypto briefly, just to establish a shared symmetric key (via ECDHE key exchange in modern setups), then drop into fast symmetric encryption for the actual session. PGP/GPG email encryption follows the hybrid pattern too — encrypt the message with a random AES key, then encrypt that AES key with the recipient's RSA or ECC public key.

What actually breaks in practice

The math behind RSA and ECC hasn't been broken through classical computing. What goes wrong is almost always implementation: weak random number generation when creating keys (the Debian OpenSSL bug from 2008 is the textbook case), reused nonces in ECDSA signatures leaking private keys, or padding oracle attacks against poorly implemented RSA (Bleichenbacher's attack against PKCS#1 v1.5 padding). Quantum computing is the long-term theoretical threat — Shor's algorithm would break both RSA and ECC if a sufficiently large quantum computer existed — which is why NIST has already standardized post-quantum algorithms like ML-KEM (formerly Kyber) for future migration.

If you want to go further with this, Korra Studio's cryptography track covers key exchange protocols and hash function internals in more depth, and the networking segments walk through how all of this fits into an actual TLS handshake byte by byte.