Symmetric vs Asymmetric Encryption: Which to Use

The common misconception is that RSA is "a stronger AES". The two were designed for different jobs:

	Symmetric	Asymmetric
Key	Same key both ways	Public encrypts, private decrypts
Speed	Fast (GB/s)	Slow (~1000× slower)
Data size	Unlimited	Tiny (RSA-2048 ≈ 190 bytes)
Solves	Confidentiality	How to share the key safely
Examples	AES, ChaCha20	RSA, ECC

One line: symmetric moves the data, asymmetric hands over the key.

Symmetric: the mode matters more than the algorithm

AES itself is sound. Breaches come from modes and parameters.

Mode	IV needed	Tamper-proof	Verdict
ECB	No	No	Never. Identical plaintext blocks produce identical ciphertext
CBC	Yes, random	No — add HMAC	Legacy compatibility only
CTR	Yes, random	No — add MAC	Same
GCM	Yes, unique	Yes	Default choice

Three rules:

1. ECB is not a style preference. It encrypts each 16-byte block independently, so structure survives encryption — encrypt an image with ECB and you can still see its outline.
2. A GCM nonce must never repeat under the same key. Reuse leaks the XOR of the plaintexts and allows forgery of the auth tag. "Pick a fixed nonce to keep it simple" is a real breach.
3. CBC alone is not enough. Without a MAC, an attacker can flip ciphertext bits to make controlled changes to the decrypted plaintext (padding oracle attacks).

To see the difference concretely, AES Encryption supports GCM, CBC and CTR with adjustable key and IV — encrypting the same text under two modes shows why the GCM output is longer (it carries a 16-byte auth tag).

Asymmetric: only two jobs

1. Encrypting a small key

That is what a TLS handshake does: agree on a temporary symmetric key, then encrypt all traffic with it. You get asymmetric's "no shared secret needed" plus symmetric's speed.

2. Signing

Signing is not encryption. It computes over a hash of the data with the private key; anyone with the public key can verify both origin and integrity.

	Encrypt	Sign
Keys	Public encrypts, private decrypts	Private signs, public verifies
Goal	Secrecy	Authenticity + integrity
Who can do it	Anyone (public key is public)	Only the private key holder

If you only need "prove this was not modified", sign; there is no reason to encrypt.

Three misuses that still ship

Encrypting a large file with RSA. RSA-2048 handles ~190 bytes per operation. To encrypt a file you encrypt an AES key with RSA and the file with AES — hybrid encryption. Chunking a file into 190-byte RSA blocks is technically possible and unusably slow.

Encrypting passwords. Passwords must be hashed, irreversibly. Encryption is reversible by whoever holds the key, and a password store must be unrecoverable even by its owner. Use bcrypt/scrypt/Argon2 — see Password Hashing.

Generating IVs from timestamps or counters. Date.now() looks random and is predictable. Counters reset and repeat after a restart. Use a CSPRNG (crypto.getRandomValues).

Key sizes and actual strength

Symmetric	Asymmetric	Roughly equivalent
AES-128	RSA-3072 / ECC-256	128 bits
AES-256	RSA-15360 / ECC-512	256 bits

"AES-256 is twice as strong as AES-128" is not meaningful — both are beyond brute force. AES-256's practical value is margin against future quantum attacks. For asymmetric keys, 2048 bits is the floor; new systems should use 3072+ or ECC.

The decision flow

Need to protect the content?
├─ Yes → how much data?
│   ├─ A lot → AES-GCM for the data + RSA/ECC for the AES key (hybrid)
│   └─ A little → AES-GCM directly; asymmetric adds nothing
└─ No, just prove it was not changed → sign (RSA / ECDSA)

Passwords are not in this flow at all: they need a deliberately slow hash, not encryption.

The closing warning

Do not implement an encryption scheme yourself. The algorithms are public and fine; what breaks is the composition — where the IV comes from, how keys are stored, what error messages reveal. Use a well-reviewed library and spend your effort on key management, which is the actually hard part.