Asymmetric crypto and key exchange

Why a second kind of crypto exists

Symmetric ciphers — AES, ChaCha20 — use one key for both encrypt and decrypt. They are fast (a modern CPU does gigabytes per second with AES-NI) and, at 256 bits, beyond brute force. Their fatal limitation is the key-distribution problem: both sides need the same secret before they can talk, and getting it there safely over an untrusted network is exactly the problem you were trying to solve.

Asymmetric (public-key) crypto breaks the symmetry. Each party has a key pair: a public key it hands out freely and a private key it never shares. The two are mathematically linked so that what one does, only the other undoes. That gives you two distinct powers:

• Encryption: anyone encrypts to your public key; only your private key decrypts. Confidentiality without a pre-shared secret.
• Signatures: you sign with your private key; anyone verifies with your public key. Authenticity and integrity — proof the message came from the holder of that private key and wasn’t altered.

The catch is cost. RSA-2048 decryption is on the order of a thousand times slower than AES per byte, and asymmetric algorithms also have a hard size limit on what they can directly encrypt (RSA can’t encrypt more than its key size minus padding). So nobody encrypts a 4 MB request body with RSA. The universal pattern is hybrid encryption: use the expensive asymmetric step once to agree on a fresh random symmetric key, then encrypt the actual bulk traffic with fast AES. Asymmetric crypto is the handshake; symmetric crypto is the conversation.

RSA vs elliptic curve: same job, different math

Two families dominate. RSA rests on the difficulty of factoring the product of two large primes. It’s old, battle-tested, and simple to reason about — but its keys are large and getting larger as factoring attacks improve. Elliptic-curve cryptography (ECC) rests on a different hard problem (the elliptic-curve discrete log) that resists attack far better per bit, so it delivers equivalent security with dramatically smaller keys and faster operations. This is why mobile, TLS, and modern protocols moved to curves like P-256 and X25519.

The security-per-bit gap is the whole story — here is the equivalence the standards bodies publish:

Read the bottom row carefully: to match AES-256, RSA needs a 15360-bit key — at which point key generation and operations are painfully slow — while ECC needs only 521 bits. RSA key size scales roughly with the cube root of the work to break it, so doubling the security level more than doubles the key. That non-linear penalty is why new systems default to curves and you mostly meet RSA only in legacy certificates and existing PKI.

Diffie-Hellman: agreeing on a secret in the open

RSA-style key transport (one side picks the symmetric key and encrypts it to the other’s public key) works, but it has a flaw we’ll get to. The more important primitive is Diffie-Hellman key exchange (DH), and its elliptic-curve form ECDH. DH is not encryption — it’s a way for two parties to jointly compute a shared secret that neither one chose alone, over a channel an attacker is reading in full.

The mechanism, stripped to its essence: both sides agree on public parameters. Each side picks a private random value, derives a public value from it, and sends only the public value across the wire. Then each side combines its own private value with the other’s public value — and by the algebra of the construction, both arrive at the identical shared secret. The eavesdropper saw both public values but neither private one, and recovering the secret from what crossed the wire is the hard problem (discrete log) that no efficient attack solves. The shared secret is then run through a key-derivation function to produce the symmetric session key.

There’s a critical caveat: raw DH gives you confidentiality against a passive eavesdropper, but it does not tell you who’s on the other end. An active attacker who sits in the middle can run a separate DH with each side and relay between them — a man-in-the-middle. DH must therefore be combined with authentication: in TLS the server signs its DH public value with the private key behind its certificate, so the client knows the value came from the real server and not an impostor. Key exchange establishes a secret; signatures and certificates establish who you’re sharing it with. You need both.

Forward secrecy: making the past un-decryptable

The fix for that archive problem is forward secrecy (also called perfect forward secrecy). The idea: generate a brand-new, throwaway DH key pair for every session — that’s the ephemeral in ECDHE — and discard the private values the moment the handshake completes. The long-term certificate key is used only to sign the ephemeral exchange, proving identity; it never encrypts the session key and never touches the shared secret.

The payoff is the property that an attacker who compromises the server’s long-term private key later cannot decrypt traffic captured earlier. Each session’s secret died with the ephemeral keys that produced it; there is nothing left on disk to recover it from. Without forward secrecy, one stolen private key retroactively unlocks years of recorded sessions — the “harvest now, decrypt later” attack, where an adversary records ciphertext today specifically to crack it once it obtains the key. With forward secrecy, each session is its own island. This is why TLS 1.3 makes ephemeral (EC)DH non-negotiable.

Where asymmetric crypto is — and isn’t — used

The senior mental model: asymmetric crypto is for bootstrapping trust and keys, not for bulk work. It shows up at exactly three moments — agreeing a session key (ECDHE), proving identity (the certificate’s signature over the handshake), and verifying authenticity at rest (signed software updates, signed JWTs, code signing). Everywhere else — the gigabytes of actual request and response bodies, the data encrypted in your database, the files on disk — is symmetric AES, because asymmetric is too slow and size-limited to do that work. When you see “encrypt this 50 MB upload,” the answer is never “RSA”; it’s “generate a random AES key, encrypt the data with AES, and protect that one small key with the asymmetric layer.”