Public-Key Encryption: How Asymmetric Keys Keep Secrets

This is the second post in a short series on what public-private keys actually do. The overview lays out the three primitives; this one zooms into the first: encryption, the job of keeping data secret.

Why start here

Encryption is the mental model most people already have, and it is the one they over-trust. They assume "it uses keys" means "it is private", and they assume asymmetric encryption is how bulk data gets protected. Both assumptions are subtly wrong, and the gap between them and reality is exactly where security bugs live. Getting encryption straight also makes the next post (signing) click, because signing is this exact machinery run backwards.

The direction that defines it

Public-key encryption answers one question: how do I send you something only you can read?

Anyone encrypts with the public key; only the private key decrypts

Read that direction carefully, because it is the source of the model's power. Your public key is everywhere: on your website, in a directory, handed to anyone who asks. Any of those people can scramble a message to you. But the scrambling is one-way unless you hold the private key. So:

• Many senders, each using the freely-available public key.
• One reader, the single holder of the private key.

This is why "my public key got leaked" is a non-event. The public key's only power is to lock things for you. An attacker holding it can encrypt messages to you, which is not a threat; it is the intended use.

Why it is the reverse of signing

If you have read the signing post, this will look like a mirror, because it is:

Same keypair, opposite directions. Encryption protects secrecy (only the private holder can read). Signing protects origin (only the private holder can produce). People blur these constantly. The clean test: ask whether you are trying to hide something or prove something. Hiding is encryption (public to private). Proving is signing (private to public).

The catch: it is painfully slow

Here is the fact that reshapes everything in practice. Asymmetric operations (RSA, elliptic-curve) are orders of magnitude slower than symmetric ones (AES), and RSA can only encrypt a payload smaller than its key size anyway. You physically cannot RSA-encrypt a 4 GB file, and you would not want to even if you could.

So in the real world, almost nobody encrypts actual data with a public key directly. Instead they use a hybrid.

The envelope trick (hybrid encryption)

The shape (a fast symmetric key for the data, plus something stronger to protect that key) shows up everywhere, but it splits into two cases worth keeping straight. The pure asymmetric version, where the wrapping key is a real public key, is what PGP and S/MIME do: encrypt the message with a one-time symmetric key, then encrypt that key to the recipient's public key. Whenever you genuinely see "encrypted with a public key", this is what is happening:

Hybrid encryption: asymmetric protects a small symmetric key, symmetric protects the bulk data

1. Generate a fresh random symmetric key (the "data key", e.g. AES-256).
2. Encrypt the actual payload with that fast symmetric key.
3. Encrypt just the small symmetric key with the recipient's public key.
4. Send both: the encrypted data and the encrypted data key.

The recipient uses their private key to unwrap the small data key, then uses that to decrypt the bulk data. Asymmetric crypto guards the key; symmetric crypto guards the data. You get the distribution superpower of public keys (no shared secret needed up front) with the speed of symmetric ciphers.

The same shape also appears where the wrapping key is symmetric, not a keypair. AWS KMS calls it envelope encryption: your data key is wrapped by a key that never leaves the KMS hardware, but that KMS master key is itself symmetric (AES-256) by default. Full-disk encryption (LUKS, BitLocker, FileVault) is the same idea: the volume key is wrapped by a passphrase or TPM-derived symmetric key. These are the clearest illustrations of the envelope idea, just not the asymmetric flavour.

One example people reach for that is actually wrong today: TLS. Old TLS did wrap a symmetric key with the server's RSA public key ("RSA key transport"), which fit this pattern exactly. But TLS 1.3 removed that. Modern TLS agrees on the symmetric key with ephemeral Diffie-Hellman instead of wrapping one, which is key exchange, not encryption, and the subject of its own post.

plaintext ──AES(data_key)──▶ ciphertext           (fast, any size)
data_key  ──RSA(pub_key)──▶ encrypted_data_key    (slow, but tiny)

send: { ciphertext, encrypted_data_key }
read: RSA_decrypt(priv_key) -> data_key -> AES_decrypt -> plaintext

A signed token is not an encrypted one

One myth worth killing while we are here, because it bridges to the next post: a JWT is not encrypted. Its payload (your user id, email, expiry) is plain base64, readable by anyone who copies the token. The signature on it guarantees it was not forged or altered, not that it is hidden.

So never put a secret in a JWT payload thinking the signature protects it. Confidentiality and authenticity are different jobs, done by the keypair in different directions. If you genuinely need an encrypted token, that is a separate construct (JWE), and it is rare.

The takeaway

Public-key encryption is the public-to-private direction: anyone can lock data for you, only you can unlock it, and the public key being public is the entire point. But because it is slow, you almost never use it on real data directly. You wrap a fast symmetric key with it and let symmetric crypto do the heavy lifting.

Next in the series: Digital Signatures, the same keypair run the other way, and the most-used primitive of the three. Or jump back to the overview.