By Freddy ·
The Encrypt / Decrypt tool on this site has a key field. You type a key, paste some text, and get ciphertext back. What the tool cannot do is get that same key to the person who needs to decrypt it. That gap has a name, the symmetric key exchange problem, and it is the reason public-key cryptography was invented in the first place. AES is fine. Delivering the key is the part that breaks.
With a symmetric cipher, anyone who holds the key can read everything and forge everything. So the key cannot travel over the channel you are trying to protect, because anyone watching that channel gets the key along with the ciphertext. You need a second, already-secure channel to move the key, and if you had one of those, you would send the message through it and skip the encryption.
Historically the answer was physical: couriers with locked cases, codebooks handed over in person. That works for two embassies. It does not work for a browser talking to a server it has never met, and it gets worse fast as the number of parties grows, because every pair needs its own key.
| People who need to talk privately | Separate shared keys required |
|---|---|
| 10 | 45 |
| 100 | 4,950 |
| 1,000 | 499,500 |
The count is n(n-1)/2. Every one of those keys has to be created, delivered secretly, stored safely, and rotated. Nobody runs a website that way, which is why the problem needed a different kind of solution rather than better logistics.
Public-key cryptography splits the key in two. One half, the public key, can be handed to anyone, including attackers, and it only does one job: lock things. The other half, the private key, never leaves its owner and does the opposite job: unlock them. Whatever the public key locks, only the private key opens. Now the sender needs nothing secret in advance. They fetch the recipient's public key from anywhere, lock a message, and send it.
RSA, published in 1977, was the first widely used way to build this. The security rests on a lopsided piece of arithmetic: multiplying two large primes is quick, but recovering them from the product is infeasible at the right sizes. Here is a toy version with numbers small enough to check by hand. Pick primes 17 and 19, so the public modulus is n = 323. Choose the public exponent e = 5, and work out the private exponent d = 173 (it satisfies 5 × 173 ≡ 1 mod 288, where 288 = 16 × 18). To lock the message 42, compute 425 mod 323, which gives 264. To unlock, compute 264173 mod 323, which gives back 42. Anyone can do the first step with (323, 5). Only someone who knows 173 can do the second, and finding 173 means factoring 323 into 17 and 19. That is trivial for 323 and hopeless for a 2048-bit modulus.
Do not take this toy into production. Real RSA pads the message first (OAEP is the standard choice), uses keys of 2048 bits or more, and comes from a vetted library. Textbook RSA without padding is insecure in several well-documented ways.
Two limits matter in practice. First, RSA is slow and size-capped. A 2048-bit key with OAEP and SHA-256 can encrypt at most 190 bytes in one go, so you cannot use it for files or database rows. The standard move is to encrypt a random AES key with RSA, send that small blob, and let AES handle the bulk data. The AES vs RSA comparison covers that hybrid pattern in more detail.
Second, and more serious: a public key proves nothing about who owns it. If an attacker sits between you and the recipient and swaps in their own public key, you will lock your message for them. The exchange itself is sound; the identity behind the key is unverified. That gap is why the web has certificate authorities, which sign statements of the form “this public key belongs to this domain.” RSA solved the secrecy half of the problem and left the trust half to infrastructure.
Here is the part many explainers skip. TLS 1.3 removed RSA key transport altogether. A modern HTTPS handshake agrees on its session key with ephemeral Diffie-Hellman over elliptic curves (ECDHE), and RSA only shows up, if at all, to sign the server's certificate. The reason is forward secrecy. If a server's long-term RSA private key leaks years later, anyone who recorded old traffic could decrypt every session that used RSA to deliver its AES key. With ephemeral Diffie-Hellman the session keys are generated fresh and thrown away, so a later leak exposes nothing from the past.
So RSA exists because of the key exchange problem, and the key exchange problem has since been solved more safely by something else. Learning why RSA was invented is still worth the time, since it frames every decision about how a key gets from one place to another.
Decide how the key will be delivered before you choose a cipher. If both ends are services you control, a secrets manager or a KMS removes the problem, and the storage tradeoffs are laid out in where to safely store an AES key. If two parties who have never met must derive a shared key, use ECDH from the Web Crypto API or a maintained library, and let TLS protect the channel. Reach for RSA-OAEP key wrapping only when the recipient already publishes an RSA public key you cannot change. Whatever you pick, never invent your own exchange protocol out of primitives, and remember from the client-side encryption trust model that the code delivering the public key is itself part of what you are trusting.