Symmetric vs asymmetric encryption: the difference that confuses everyone

Every other week someone shows up in the engineering channel saying they're going to "encrypt the password in the database with a secret key." And almost always, what they actually want isn't encryption at all. The classic confusion is treating everything as just "a key": TLS, user passwords, session tokens, all tossed in the same bucket. But there are two models of cryptography that work in opposite ways, plus a third concept that uses no key whatsoever, and that's exactly where most people slip.

This article separates the three: symmetric encryption, asymmetric encryption, and hashing. When to use each, why the real world uses the first two together, and why the third isn't encryption at all.

The difference in one sentence

Symmetric encryption uses a single key to encrypt and decrypt. The same key that locks, unlocks. Asymmetric encryption uses a key pair: a public key and a private key, mathematically linked, where what one does only the other can undo.

It sounds like a detail, but it changes everything about who can read what, and above all, how you hand the key to the other side.

Symmetric: fast, and the problem is the key

In symmetric encryption you have one key (a sequence of bytes, typically 256 bits with AES) and use it on both ends. The sender encrypts with the key, the receiver decrypts with the same key. The standard algorithm today is AES, preferably in AES-GCM mode, which not only ciphers but also authenticates (it detects if the ciphertext was tampered with).

The big advantage is speed. AES is absurdly fast, usually hardware-accelerated (AES-NI instructions on the CPU). To encrypt a 5 GB file, a backup, a disk volume, a video stream, symmetric is the only sensible option.

# encrypt a file with AES-256 (symmetric)
openssl enc -aes-256-gcm -in data.txt -out data.enc -pbkdf2
# decryption uses exactly the same password/key
openssl enc -d -aes-256-gcm -in data.enc -out data.txt -pbkdf2

The problem isn't encrypting. The problem is key distribution: how do you hand that key to whoever needs to decrypt, without a third party intercepting it on the way? If you email the key alongside the file, congratulations, you protected nothing. That's symmetric's Achilles heel, and it's exactly the problem asymmetric solves.

Asymmetric: slow, but it solves key distribution

In asymmetric encryption you generate a pair: a public key and a private key. The public key you can scatter to the whole world, paste on GitHub, send by email. The private key you guard like gold and never share. The math guarantees two useful properties:

• What's encrypted with the public key can only be decrypted with the matching private key. Anyone can send you something encrypted; only you read it.
• What's signed with the private key can be verified by anyone holding the public key. That's the basis of the digital signature: proof the message came from you and wasn't altered.

The classic algorithms are RSA and, increasingly, elliptic curve cryptography (ECC), which delivers the same security with much smaller keys and is faster.

The price is slowness. Asymmetric operations are orders of magnitude more expensive than AES. Nobody encrypts a 5 GB file with RSA; it would be absurd. So what's it for? For solving exactly symmetric's key distribution problem.

Encryption is not the same as signature

Worth hammering this because it confuses people: encrypting for secrecy and signing for authenticity are different uses of the same key pair. For secrecy, you encrypt with the recipient's public key (only they read it). For authenticity, you sign with your own private key (everyone verifies it was you). These are opposite goals and don't substitute for each other.

The real world uses both: hybrid cryptography

Here's the point that demolishes the idea that TLS is "just a key." TLS, which protects all HTTPS, is a hybrid system. It uses both models, each for what it does best:

1. Handshake (asymmetric): the client and server use asymmetric cryptography to do the key exchange and securely agree on a symmetric session key. Nobody in the middle can capture that key.
2. Session (symmetric): from then on, all the actual traffic, the page bytes, the requests, the video, is encrypted with AES using that session key. Fast.

In other words: asymmetric solves the hard problem (delivering the key securely) and symmetric does the heavy lifting (encrypting volume). Each covers the other's weakness. Practically every serious cryptographic protocol, from TLS to SSH to PGP, follows this hybrid pattern.

The third concept: hashing is not encryption

Now the point that confuses people most, and the root of that "encrypt the password" request. Hashing is not encryption. Encryption is reversible by definition: there's a key that undoes it. Hashing is one-way and uses no key at all. You feed data into a hash function and get back a fixed-size value; there's no operation that recovers the original data from the hash.

That's exactly why hashing is the right way to store passwords. You never want to be able to "decrypt" a user's password, because if you can, an attacker who steals your key can too. You store the hash, and at login you hash whatever the user typed and compare. For passwords, use functions designed for it, like bcrypt or Argon2, which are deliberately slow to resist brute-force attacks, never a raw fast hash like SHA-256 on its own.

If you want to see the difference between a one-way transformation and ciphering in practice, you can play with a hash generator: change one character of the input and watch the entire output change, with no key involved and no way back.

When to use which

The practical rule:

• Encrypt bulk data (files, backups, large payloads): symmetric, AES-GCM.
• Exchange a key securely over an open channel or prove identity: asymmetric, ECC or RSA, or a ready-made hybrid protocol like TLS.
• Store a password or verify integrity: hashing. Password = bcrypt/Argon2. Integrity/checksum = SHA-256.

And the opinion you're probably expecting: don't roll your own crypto. Crypto is one of those areas where code that "passes the tests" can be completely broken against a real attacker. Use vetted libraries (libsodium, your language's crypto stdlib, the system's TLS), default to modern AES-GCM and ECC, and leave mode of operation, nonce, and padding to people who already solved it properly. If you're hand-generating your own nonce, stop and look at what you're doing.

For the backdrop on why all of this matters, confidentiality, integrity, authenticity, it's worth reading the information security fundamentals, which frame where each of these techniques fits.

Takeaway

Symmetric is one key, fast, great for bulk, and the hard part is distributing the key. Asymmetric is a public/private pair, slow, and it solves key distribution and digital signatures. The real world uses both together (TLS does the asymmetric handshake and a symmetric session). And hashing is not encryption: it's one-way, keyless, and it's the right way to store passwords. Internalize that separation and you'll stop making the single most common security mistake. And, again: don't write your own crypto.

Frequently asked questions

Is symmetric or asymmetric encryption better?

Neither is "better"; they solve different problems. Symmetric is fast and ideal for encrypting large amounts of data, but you have to distribute the key securely. Asymmetric is slow but lets you exchange keys over an open channel and sign data. That's why real systems combine them.

Why does TLS use both types of encryption?

Because each covers the other's weakness. Asymmetric cryptography handles the handshake and key exchange securely, then a fast symmetric key encrypts the actual session traffic. Using asymmetric for everything would be far too slow; using symmetric alone would leave you with no safe way to share the key.

Is hashing a type of encryption?

No. Encryption is reversible with a key; hashing is a one-way function with no key, so there's no way to recover the original input from the hash. That's precisely why hashing (with bcrypt or Argon2) is the correct way to store passwords, not encryption.

Which algorithms should I use today?

For symmetric, AES-GCM (or ChaCha20-Poly1305). For asymmetric, modern elliptic curve cryptography (ECC) or RSA with adequate key sizes. For password storage, bcrypt or Argon2. And use a vetted library rather than implementing any of these yourself.