Table of Contents
- Symmetric vs asymmetric: the split everything else builds on
- The algorithms people actually mean when they say “encryption”
- Encryption at rest, in transit, and in use
- How to actually choose
- What’s coming: post-quantum and homomorphic encryption
- FAQ
Every guide to encryption methods promises to explain “how encryption works” and then spends 2,000 words on locks and keys as a metaphor. Locks are fine. But if you’re here, you probably want the actual algorithms — which one does what, why RSA and AES aren’t interchangeable, and which one you should reach for in a given situation. That’s what this is.
Symmetric vs asymmetric: the split everything else builds on
Every encryption method on this page falls into one of two categories, and the difference isn’t academic — it determines what the algorithm is good for.
Symmetric encryption uses one key to both lock and unlock the data. Fast, efficient, and the workhorse for encrypting actual content — files, databases, disk volumes, the payload of a TLS session once it’s established. The catch: both sides need the same key, which means you need a way to get that key from one party to the other without anyone intercepting it. That’s the “key distribution problem,” and it’s the reason symmetric encryption almost never travels alone.
Asymmetric encryption (also called public-key cryptography) uses a mathematically linked pair of keys — one public, one private. Encrypt with the public key, and only the private key can decrypt it. This solves the distribution problem: you can publish your public key anywhere, and anyone can use it to send you something only you can read. The tradeoff is speed. Asymmetric algorithms are computationally expensive — often 100 to 1,000 times slower than symmetric ones for the same amount of data — so nobody uses them to encrypt a 4GB backup file.
In practice, almost every real system uses both. TLS (the protocol behind HTTPS) uses asymmetric encryption to negotiate a session, then switches to a symmetric cipher to actually move data. That hybrid pattern shows up everywhere once you know to look for it.
The algorithms people actually mean when they say “encryption”
Six names come up constantly. Here’s what each one is, in plain terms:
AES (Advanced Encryption Standard) — Symmetric block cipher, adopted by NIST in 2001 as FIPS 197 after a public competition to replace DES. Operates on 128-bit blocks with key sizes of 128, 192, or 256 bits. AES-256 is the default choice for nearly everything today: disk encryption, database columns, VPN tunnels, the file on your phone. Hardware acceleration (AES-NI, built into most modern CPUs) makes it essentially free performance-wise.
3DES (Triple DES) — The original DES algorithm run three times in sequence to extend its effective key strength. It was a stopgap while AES was being developed, and it shows: 64-bit blocks are small enough to be vulnerable to birthday-attack-style collisions on large data transfers (the “Sweet32” attack). NIST formally disallowed 3DES for new applications after 2023. If you find it in production, that’s a migration item, not a design choice.
Blowfish — Bruce Schneier’s 1993 block cipher, free of patents and popular in older password-management and VPN tools. Like 3DES, it uses a 64-bit block size, which caps how much data you can safely encrypt under one key before the same vulnerability class becomes a concern. Schneier’s own successor, Twofish, and later AES itself made Blowfish mostly a legacy-systems algorithm now.
RSA (Rivest–Shamir–Adleman) — The original practical asymmetric algorithm, published in 1977, built on the difficulty of factoring the product of two large prime numbers. RSA-2048 is the common baseline today; RSA-3072 and RSA-4096 show up where longer-term security matters. RSA handles key exchange and digital signatures — not bulk data, because it’s too slow and because RSA ciphertext is larger than the plaintext it came from.
ECC (Elliptic Curve Cryptography) — Asymmetric encryption built on the algebra of elliptic curves instead of prime factorization. The advantage is efficiency: a 256-bit ECC key provides security roughly equivalent to a 3072-bit RSA key, which means smaller keys, faster computation, and less bandwidth — a real win on mobile devices and IoT hardware. Most modern TLS handshakes now default to ECC (specifically ECDHE) over RSA for exactly this reason.
ChaCha20 — A symmetric stream cipher designed by Daniel J. Bernstein, usually paired with the Poly1305 authenticator as ChaCha20-Poly1305. It doesn’t need dedicated hardware acceleration to run fast, which makes it the better choice on devices without AES-NI — older phones, low-power IoT chips, some ARM processors. TLS 1.3 supports it as a first-class alternative to AES-GCM for that reason.
How they stack up
| Algorithm | Type | Typical key size | Relative speed | Best-fit use case |
|---|---|---|---|---|
| AES-256 | Symmetric | 256-bit | Very fast (hardware-accelerated) | Bulk data, disk encryption, database fields |
| ChaCha20-Poly1305 | Symmetric | 256-bit | Very fast (software-optimized) | Mobile/IoT without AES hardware support |
| 3DES | Symmetric | 112-bit effective | Slow | Legacy only — deprecated by NIST |
| Blowfish | Symmetric | up to 448-bit | Moderate | Legacy systems, small-data use |
| RSA-2048/4096 | Asymmetric | 2048–4096-bit | Slow | Key exchange, digital signatures |
| ECC (P-256/P-384) | Asymmetric | 256–384-bit | Fast for its category | Key exchange on mobile, modern TLS |
Encryption at rest, in transit, and in use
The algorithm is only half the picture. The other half is which of three data states you’re protecting, because each one calls for a different implementation even when the underlying cipher is the same.
Data at rest is anything sitting still — a database, a hard drive, a backup in cloud storage. AES-256 handles nearly all of it: full-disk encryption tools (BitLocker, FileVault), database-level encryption, and encrypted object storage all lean on it. NIST’s SP 800-111 guidance covers this category specifically.
Data in transit is anything moving across a network — a browser loading a page, an API call, a VPN tunnel. TLS is the dominant protocol here, and it’s a textbook hybrid: ECC or RSA negotiates the session, then AES-GCM or ChaCha20-Poly1305 encrypts the actual traffic. NIST’s SP 800-52 governs TLS configuration for federal systems, and its recommendations are a reasonable baseline for anyone.
Data in use is the newest and least solved category — protecting data while it’s actively being computed on, in memory, mid-operation. Traditional encryption doesn’t cover this gap: a database has to decrypt a field before it can query it, which is a moment of exposure. Two approaches are closing that gap. Confidential computing uses hardware-isolated “enclaves” (like Intel SGX or AMD SEV) so even the machine’s own operating system can’t see the data being processed. Homomorphic encryption takes a more radical approach — running computations directly on encrypted data, more on that below.
How to actually choose
Most “how to choose an encryption algorithm” content dodges the actual answer because the honest answer is “it depends on what you’re protecting and how it moves.” Here’s a scenario-based version instead of a vague checklist:
- Encrypting a database column or a file on disk → AES-256. It’s the default for a reason: fast, hardware-accelerated, no meaningful downside.
- Sending a symmetric key to someone over an insecure channel → RSA or ECC to wrap the key, then AES to encrypt the payload. This is the hybrid pattern TLS uses, and it’s the right instinct for custom systems too.
- Building for mobile or embedded hardware without AES acceleration → ChaCha20-Poly1305. It holds up in software where AES needs a hardware assist to stay fast.
- Signing a document or a software release → RSA or ECDSA today; budget time to evaluate ML-DSA (the new NIST post-quantum signature standard) if the signature needs to stay valid for decades.
- You inherited a system running 3DES or Blowfish → Migrate. Neither is a design choice at this point; both are technical debt.
- Protecting data mid-computation, not just at rest or in transit → Look at confidential computing (hardware enclaves) for near-term needs, and homomorphic encryption for specialized, privacy-critical workloads where performance cost is acceptable.
Notice what’s missing from that list: “it depends on your budget” or vendor-specific pitches. The algorithm choice mostly comes down to what state the data is in and what hardware it’s running on.
What’s coming: post-quantum and homomorphic encryption
RSA and ECC both rely on math problems — factoring large numbers, solving elliptic curve discrete logarithms — that are hard for classical computers but theoretically fast for a sufficiently powerful quantum computer running Shor’s algorithm. No quantum computer today can break real-world RSA or ECC keys. The concern is “harvest now, decrypt later”: encrypted data intercepted today could be stored and decrypted once quantum computing catches up, which matters enormously for anything that needs to stay confidential for years or decades.
NIST has already moved. In August 2024 it finalized the first three post-quantum encryption standards: ML-KEM (derived from CRYSTALS-Kyber) for key exchange, ML-DSA (from CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (from SPHINCS+) as a hash-based signature backup. In March 2025, NIST went further and selected HQC as a fifth algorithm, specifically because it’s built on error-correcting codes rather than lattice math — a deliberate hedge in case a future weakness is found in the lattice-based approach that ML-KEM uses. The full standardization effort is tracked on NIST’s Post-Quantum Cryptography project page. Organizations handling long-lived sensitive data — health records, government communications, intellectual property — are already piloting hybrid classical-plus-post-quantum key exchange in production TLS deployments.
Homomorphic encryption is a separate frontier, aimed at the “data in use” gap. Fully homomorphic encryption (FHE) lets a system perform calculations directly on ciphertext and get an encrypted result that, once decrypted, matches what you’d have gotten from running the same operation on the plaintext. Nobody handling the computation ever sees the actual data. The catch is cost: FHE operations are still orders of magnitude slower than plaintext computation, which keeps it confined to specialized use cases — privacy-preserving medical research and financial analytics being the two areas where the tradeoff currently makes sense.
FAQ
Is AES or RSA more secure? They’re not really comparable on the same scale, because they solve different problems. AES-256 is currently considered secure against any known practical attack, classical or otherwise. RSA’s security depends on key size and is vulnerable in theory to future quantum computers — but for key exchange and signatures, RSA-2048/4096 remains solid against classical attacks today.
Why do systems use both symmetric and asymmetric encryption? Because each covers the other’s weakness. Asymmetric encryption solves secure key exchange but is too slow for bulk data. Symmetric encryption is fast but needs a way to share the key safely. Combining them — asymmetric to exchange a session key, symmetric to encrypt everything after — is how TLS, most VPNs, and most secure messaging apps actually work.
What replaced DES and why? AES replaced DES (and its patch, 3DES) after NIST ran an open competition in the late 1990s. DES’s 56-bit key became crackable by brute force as computing power grew; AES’s minimum 128-bit key, with 192- and 256-bit options, closed that gap by a wide margin.
Do I need to worry about post-quantum encryption right now? If you’re protecting data that needs to stay confidential for 10+ years — health records, trade secrets, classified material — yes, start evaluating hybrid post-quantum key exchange now, since intercepted ciphertext today could be decrypted later. For most everyday systems, migration timelines are measured in years, not months, and NIST’s finalized standards give vendors a stable target to build toward.
Is ECC better than RSA? For most new systems, yes — smaller keys at equivalent security levels mean faster handshakes and less bandwidth, which is why ECC has become the default in modern TLS. RSA isn’t obsolete, though; it’s still widely supported and sometimes required for compatibility with older systems.
Encryption methods aren’t a single choice — they’re a stack of decisions: symmetric or asymmetric, which algorithm, which data state, and increasingly, whether to hedge against a quantum future that hasn’t arrived yet but might outlast the data you’re protecting today. Get the framework right — match the algorithm to the job instead of reaching for whichever one sounds strongest — and the specific acronym stops being the hard part.
