When someone says "this is encrypted", they usually picture a single thing: a padlock that turns text into noise. But under that padlock there are two very different families of encryption, with almost opposite strengths. One is fast but shares a secret; the other distributes keys with no risk but is slow. The elegant move isn't to pick one: it's to combine them, and that's exactly what your browser does every time you see the HTTPS padlock.
What encryption means
Before comparing families, it helps to pin down what encryption is. It's not hiding a message: it's transforming it reversibly, so that only whoever holds the right key can read it.
Encrypting is transforming readable text (plaintext) into unreadable text (ciphertext) using an algorithm and a key. Only whoever holds the right key can reverse the process —decrypt— and recover the original text.
Security doesn't depend on hiding the algorithm, which is usually public and studied by everyone, but on protecting the key. A good cipher stays secure even if the attacker knows every detail of how it works; the one thing they must not have is the key.
Symmetric encryption: one key
The oldest and most intuitive way to encrypt uses the same key for both directions: the one that locks the padlock is the same one that opens it.
- Both parties share a single secret key, known only to them.
- The sender encrypts the message with that key and transmits it.
- The receiver uses the same key to decrypt and read it.
The big advantage is speed: symmetric algorithms are fast and efficient, ideal for encrypting large volumes of data —whole disks, heavy files, all the traffic of a session—. The quintessential real example is AES, the standard that encrypts everything from your disk to the content of your HTTPS connections.
But it has an Achilles' heel: if both parties need the same key, someone has to get it to the other party securely. And if an attacker intercepts that key in transit, the whole encryption falls apart. It's the classic key distribution problem: how do you share a secret with someone without yet having a secure channel to do it?
Asymmetric encryption: a key pair
Asymmetric encryption solves that problem with a brilliant idea: instead of a shared key, each party has two different but mathematically linked keys.
Each user has a key pair: a public key, which they can share with everyone, and a private key, secret, which never leaves its owner.
What's encrypted with the public key is only decrypted with the private one, and vice versa. They're linked in such a way that knowing the public key doesn't let you deduce the private one.
This solves distribution: you can publish your public key anywhere —a directory, a website, an email— with no risk at all, because with it you can only encrypt messages addressed to you; to read them you need your private key, which you never shared. The real examples are RSA and schemes based on elliptic curves (ECC).
The price is high: asymmetric encryption is much slower than symmetric —by orders of magnitude— and no good for large volumes of data. Encrypting a whole large file with RSA would be absurdly expensive. That's why, in practice, it's almost never used to encrypt the data itself.
How they combine
Here's the trick that ties it all together. Since symmetric is fast but has a distribution problem, and asymmetric distributes well but is slow, the solution isn't to pick one: it's to use each where it shines.
- The asymmetric encryption is used only at the start, so the two parties can secretly agree on a session key without ever having shared it over an open channel.
- That session key is symmetric: a single key, now known to both parties thanks to the previous step.
- All the bulk of the data is encrypted with that symmetric key, which is fast and holds up under the volume of a real connection.
- This gets you the best of both worlds: the distribution security of asymmetric to agree on the key, and the speed of symmetric to move the data.
This is exactly what the TLS/HTTPS handshake does every time you open a site with a padlock: the browser and the server use asymmetric cryptography at the start to agree on a session key, and then encrypt the whole exchange with that symmetric key. Neither asymmetric alone nor symmetric alone would be enough; together, they are.
Symmetric vs asymmetric, side by side
| Feature | Symmetric | Asymmetric |
|---|---|---|
| Number of keys | One shared | A pair: public + private |
| Speed | High | Low |
| Good for | Large volumes of data | Agreeing on keys and signing |
| Problem it solves | — | Key distribution |
| Examples | AES | RSA, ECC |
Common mistakes
"Asymmetric encryption is more secure than symmetric." No: it's not a matter of more or less secure, but of different purposes. Well-used symmetric —for example AES-256— is extremely robust; asymmetric is slower and is used where symmetric can't reach (distributing keys, signing). That's why they're combined, not in competition.
Around that basic confusion, other frequent mistakes creep in:
- Reusing or "burning" the private key. The private key is the secret of your entire cryptographic identity: if it leaks, anyone can impersonate you or read what's addressed to you. It's never shared, it's transported carefully and rotated.
- Confusing encrypting with signing. Encrypting protects confidentiality (that no one reads it); signing proves authenticity (that it comes from who it claims and wasn't altered). Asymmetric serves both, but they're not the same.
- Believing a secret algorithm is more secure. The opposite: serious algorithms are public and scrutinized by the whole community. Security lives in the key, not in hiding how the cipher works.
The banking angle
In banking, encryption isn't up for debate: it's assumed. What separates a serious system from a fragile one is how the keys are managed, a problem as important as the encryption itself. The strongest algorithm in the world is useless if the key is poorly stored.
That's why, in financial environments, keys are generated, stored and rotated inside dedicated hardware modules (HSMs): devices designed so the key never leaves in the clear, with strict access controls and auditing of every use. The logic is simple and hard: a leaked key voids all the encryption, no matter how robust the algorithm. Protecting the key is protecting the data.
Encryption isn't picking the "strongest" algorithm and calling yourself safe. It's combining the right tools —asymmetric to agree, symmetric to move the volume— and, above all, protecting the keys. That, and not the name of the cipher, is where the real security lives.
