Choosing an encryption algorithm feels like it should be simple — pick the strongest one and use it everywhere. But encryption algorithms are not interchangeable. AES, RSA, and ChaCha20 solve fundamentally different problems, run at wildly different speeds, perform differently depending on your hardware, and face different futures when quantum computers arrive. Picking the wrong algorithm does not just slow your system down — it can leave security gaps that no amount of key length fixes.
This guide compares AES, RSA, and ChaCha20 with actual benchmarks, real-world deployment data, and practical recommendations for every major use case in 2026. No hand-waving about "it depends." You will leave knowing exactly which algorithm to use for your specific situation and why.
Fundamentals: Symmetric vs. Asymmetric Encryption
Before comparing specific algorithms, you need to understand the fundamental distinction that makes "AES vs RSA" a misleading comparison. AES and ChaCha20 are symmetric algorithms — they use the same key for encryption and decryption. RSA is an asymmetric algorithm — it uses a public key for encryption and a separate private key for decryption. These are not competing approaches. They solve different problems and work together in virtually every real-world encryption system.
Symmetric encryption: AES and ChaCha20
Symmetric algorithms encrypt bulk data — files, disk partitions, database columns, network traffic, video streams. They are fast because the mathematical operations involved (substitution, permutation, XOR for AES; addition, rotation, XOR for ChaCha20) are simple and parallelizable. The challenge is key distribution: both parties need the same key before they can communicate securely, and transmitting that key requires its own protection.
Asymmetric encryption: RSA
Asymmetric algorithms solve the key distribution problem. RSA allows two parties who have never communicated before to establish a shared secret over an insecure channel. One party publishes a public key (which anyone can use to encrypt data), and only the holder of the corresponding private key can decrypt it. RSA also enables digital signatures — proving that a message came from a specific sender and was not tampered with. The tradeoff is speed: RSA operations are 1,000 to 10,000 times slower than AES operations, which makes RSA impractical for encrypting large amounts of data directly.
How they work together: the hybrid model
Every major encryption protocol — TLS, SSH, PGP, S/MIME, Signal Protocol, WireGuard — uses the hybrid model: an asymmetric algorithm (RSA, ECDH, X25519) negotiates and exchanges a symmetric key, then a symmetric algorithm (AES or ChaCha20) uses that key to encrypt the actual data. When you visit a website over HTTPS, your browser and the server use asymmetric cryptography to agree on a shared AES or ChaCha20 key, then all the actual page content flows encrypted under that symmetric key. Understanding this hybrid model is essential — it explains why you do not choose between AES and RSA, but rather choose which symmetric cipher and which asymmetric mechanism to pair together.
AES: The Global Standard for Symmetric Encryption
The Advanced Encryption Standard was selected by NIST in 2001 through an open international competition that evaluated 15 candidate algorithms. The winning algorithm, Rijndael (designed by Belgian cryptographers Joan Daemen and Vincent Rijmen), became AES and has since become the most widely deployed encryption algorithm in history. AES is mandated or recommended by virtually every government, financial regulator, and standards body worldwide.
How AES works (simplified)
AES operates on fixed 128-bit blocks of data through multiple rounds of substitution-permutation operations. Each round applies four transformations: SubBytes (replaces each byte using a substitution table), ShiftRows (cyclically shifts rows of the state matrix), MixColumns (mixes data within each column using matrix multiplication), and AddRoundKey (XORs the state with a round key derived from the main key). AES-128 performs 10 rounds, AES-192 performs 12 rounds, and AES-256 performs 14 rounds. More rounds mean better security but slightly slower performance.
AES modes of operation
The algorithm alone is not enough — the mode of operation determines how AES processes data larger than one block and has enormous security implications:
AES-GCM (Galois/Counter Mode) is the recommended mode for most applications in 2026. It provides authenticated encryption — both confidentiality (no one can read the data) and integrity (no one can modify the data without detection). GCM runs in parallel on multi-core processors and is the primary cipher suite in TLS 1.3. The one caveat: GCM is catastrophically vulnerable to nonce reuse. If you ever encrypt two different messages with the same key and nonce, an attacker can recover the authentication key and forge messages. Your implementation must guarantee unique nonces.
AES-XTS is designed specifically for disk encryption. BitLocker, FileVault, and LUKS all use AES-XTS for full-disk encryption. XTS handles the unique challenges of disk encryption — encrypting fixed-size sectors where data must be decryptable at any offset without reading the entire disk.
AES-CBC (Cipher Block Chaining) was the standard mode for decades but has known vulnerabilities — most notably padding oracle attacks (as exploited in the POODLE attack against TLS). CBC is still used in some legacy systems but should be avoided in new implementations.
AES-CTR (Counter Mode) turns AES into a stream cipher, enabling parallel encryption and random access to encrypted data. However, CTR provides no authentication — combine it with HMAC if you need integrity, or better yet, just use GCM.
AES performance benchmarks
AES performance varies dramatically depending on whether hardware acceleration (AES-NI) is available. AES-NI is a set of CPU instructions designed specifically for AES operations, available on Intel processors since 2010 (Westmere) and AMD since 2011 (Bulldozer). With AES-NI, AES-256-GCM achieves 2-4 GB/s on a single core, making it the fastest option for servers and modern desktops. Without AES-NI, AES-256-GCM drops to roughly 200-500 MB/s in optimized software — still fast enough for most applications but significantly slower than ChaCha20 on the same hardware.
On modern server hardware (Intel Xeon, AMD EPYC), AES-NI is universal. On mobile devices, Apple A-series and M-series chips include AES acceleration, and modern Qualcomm Snapdragon (800-series) and Samsung Exynos chips include ARMv8 cryptography extensions that accelerate AES. Budget and mid-range mobile processors from 2022 and earlier may lack these extensions, which is where ChaCha20 becomes advantageous.
AES security status in 2026
AES remains unbroken after 25 years of public cryptanalysis by the global research community. The best known attack against AES-256 is a related-key attack by Biryukov, Khovratovich, and Nikolic that reduces the effective keyspace from 2^256 to 2^99.5 — but this attack requires related keys (a scenario that does not apply to normal encryption usage) and is still computationally infeasible. Against quantum computers, Grover algorithm theoretically halves the effective key length, reducing AES-256 to an effective 128-bit security level — which is still considered secure. AES-256 is the safe long-term choice.
RSA: The Foundation of Public-Key Cryptography
RSA (Rivest-Shamir-Adleman), published in 1977, was the first practical public-key cryptosystem and remains the most widely deployed asymmetric algorithm. RSA derives its security from the mathematical difficulty of factoring the product of two large prime numbers. Given two 1024-bit primes, multiplying them is trivial — but factoring their 2048-bit product back into the original primes is computationally intractable with current technology.
RSA key sizes and security levels
RSA-2048 is the current minimum recommended key size, providing approximately 112 bits of security. NIST considers it safe through approximately 2030. Most TLS certificates, code signing certificates, and PGP keys use RSA-2048 today. RSA-3072 provides approximately 128 bits of security and is recommended for data that needs protection beyond 2030. RSA-4096 provides approximately 140+ bits of security and is used for high-value keys like root CA certificates. The key size increase is not linear with security: doubling the RSA key size from 2048 to 4096 only adds about 28 bits of effective security, while making operations roughly 6-8 times slower.
RSA performance reality
RSA is not designed for bulk data encryption and its performance numbers reflect that. RSA-2048 encryption (using the public key) runs at roughly 20,000-40,000 operations per second, while decryption (using the private key) runs at roughly 1,000-2,000 operations per second. For RSA-4096, those numbers drop by approximately 6-8x. Compare this to AES-256-GCM at 2-4 GB/s — RSA is operating in a completely different performance tier because it is solving a completely different problem. The practical implication: RSA encrypts a 245-byte block (the maximum for RSA-2048 with OAEP padding). If you tried to encrypt a 1 GB file using RSA alone, it would take hours instead of the fraction of a second that AES requires.
RSA vs. elliptic curve alternatives
For new applications in 2026, ECDH (Elliptic Curve Diffie-Hellman) and ECDSA (Elliptic Curve Digital Signature Algorithm) are increasingly preferred over RSA for key exchange and signatures. An ECDH key using the P-256 curve provides equivalent security to RSA-3072 but with 256-bit keys instead of 3072-bit keys, resulting in faster operations, smaller certificates, and lower bandwidth usage. X25519 (a specific elliptic curve designed by Daniel Bernstein) is even faster and simpler to implement securely than NIST P-curves. TLS 1.3 uses X25519 for key exchange by default in most configurations.
RSA and quantum computing
RSA has a critical vulnerability that AES and ChaCha20 do not share: Shor algorithm. Shor algorithm, running on a sufficiently large quantum computer, can factor large numbers in polynomial time — breaking RSA completely regardless of key size. A quantum computer with approximately 4,099 logical qubits could break RSA-2048 in hours. Current quantum computers have achieved around 1,000 physical qubits (logical qubits, which require error correction from many physical qubits, are far fewer). Most experts estimate cryptographically relevant quantum computers are 10-20 years away, but the threat is real enough that data encrypted today with RSA could be stored by adversaries and decrypted later — the "harvest now, decrypt later" attack. NIST finalized post-quantum replacement standards in 2024: ML-KEM (for key encapsulation, replacing RSA/ECDH key exchange) and ML-DSA (for signatures, replacing RSA/ECDSA signatures).
ChaCha20: The Modern Stream Cipher Alternative
ChaCha20 was designed by Daniel Bernstein in 2008 as a refinement of his earlier Salsa20 cipher. It gained significant traction when Google adopted it for TLS connections to Android devices in 2014, and it was standardized in RFC 8439 as ChaCha20-Poly1305 — pairing ChaCha20 encryption with the Poly1305 message authentication code for authenticated encryption.
How ChaCha20 differs from AES
AES is a block cipher that processes fixed 128-bit blocks using substitution-permutation networks. ChaCha20 is a stream cipher that generates a keystream using add-rotate-XOR (ARX) operations, then XORs the keystream with plaintext. The ARX construction is significant because these operations have constant-time execution on all processors — they are inherently resistant to timing-based side-channel attacks. AES, by contrast, uses lookup tables (S-boxes) that can leak timing information through cache access patterns. While AES-NI eliminates this concern on hardware with dedicated AES instructions, software AES implementations remain vulnerable to cache-timing attacks.
ChaCha20-Poly1305 performance
ChaCha20-Poly1305 performance depends heavily on the hardware context. On devices with AES-NI (modern x86 servers and desktops), AES-256-GCM is roughly 20-40 percent faster than ChaCha20-Poly1305 because dedicated hardware beats optimized software. On devices without AES-NI (older ARM processors, IoT devices, budget smartphones), ChaCha20-Poly1305 is 3-4x faster than software AES-GCM because ARX operations map directly to basic CPU instructions that every processor has, while AES S-box lookups are expensive without dedicated hardware.
This performance characteristic is exactly why Google adopted ChaCha20 for mobile: when a Pixel phone connects over TLS, ChaCha20 means faster page loads and less battery drain compared to AES on older hardware. On the Google server side (which has AES-NI), the computational cost of either algorithm is negligible.
Where ChaCha20 dominates
WireGuard VPN uses ChaCha20-Poly1305 exclusively (with no cipher negotiation) — a deliberate design choice for simplicity and performance across diverse device types. Android full-disk encryption defaults to Adiantum (based on ChaCha20) for devices without AES hardware support. Cloudflare, Google, and other CDNs negotiate ChaCha20 for mobile TLS connections. SSH supports chacha20-poly1305@openssh.com as a cipher option. Noise Protocol Framework (used by WhatsApp and Lightning Network) defaults to ChaCha20-Poly1305.
ChaCha20 security status
ChaCha20 provides 256-bit security and has no known practical attacks. The best published attack reduces ChaCha20 security from its full 20 rounds to a theoretical attack against a reduced 7-round variant — the full 20-round version retains a massive security margin. Like AES, ChaCha20 is a symmetric cipher and faces only Grover algorithm from quantum computing, meaning it retains at least 128-bit equivalent security against quantum adversaries. Both AES-256 and ChaCha20 are considered quantum-safe at the symmetric level.
Head-to-Head Comparison: AES vs. ChaCha20
Since RSA serves a different purpose (key exchange and signatures, not bulk encryption), the meaningful head-to-head comparison is between the two symmetric contenders: AES-256-GCM and ChaCha20-Poly1305.
When to choose AES-256-GCM
Choose AES-256-GCM when your deployment target has guaranteed AES-NI support — servers, modern desktops, Apple devices (all M-series and A-series chips), flagship Android phones, and cloud infrastructure. AES-GCM is the default recommendation for data at rest (because storage servers always have AES-NI), database encryption (TDE in SQL Server, Oracle, PostgreSQL uses AES), and government or regulated environments where AES/NIST approval is explicitly required (FIPS 140-2/3 compliance, FedRAMP, CMMC).
When to choose ChaCha20-Poly1305
Choose ChaCha20-Poly1305 when your application runs on diverse hardware where AES-NI cannot be guaranteed — mobile apps targeting budget Android devices, IoT deployments with constrained processors, embedded systems, or VPN clients that must perform well on every device type (which is why WireGuard chose ChaCha20 exclusively). ChaCha20 is also the better choice when side-channel resistance is a priority and you cannot control the execution environment — for example, in multi-tenant cloud containers where cache-timing attacks are a concern.
Practical Algorithm Selection by Use Case
Here are specific recommendations for the most common encryption scenarios in 2026:
Web server TLS (HTTPS): Configure TLS 1.3 with both TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. Modern TLS libraries (OpenSSL 1.1.1+, BoringSSL, LibreSSL) automatically prefer AES-GCM for clients with AES-NI and ChaCha20 for clients without — this is the approach Google and Cloudflare use. For key exchange, prefer X25519 (ECDH on Curve25519) over RSA key transport.
File encryption at rest: AES-256-GCM through a proven library (libsodium, OpenSSL, or your platform's built-in crypto API). For disk-level encryption, use AES-256-XTS through BitLocker, FileVault, or LUKS. On Android devices without AES hardware, the Adiantum scheme (ChaCha20-based) provides efficient full-disk encryption.
Database column encryption: AES-256-GCM with unique IVs per record. Never use ECB mode (which leaks patterns in the data). For transparent data encryption (TDE) at the database engine level, all major databases (PostgreSQL, MySQL, SQL Server, Oracle) use AES-XTS or AES-CBC — this is handled by the database engine, not your application code.
Mobile app encryption: If you target only iOS (or modern Android flagships with ARMv8 crypto extensions), AES-256-GCM is fast enough. If you target a broad range of Android devices including budget models, use ChaCha20-Poly1305 — the performance difference on older ARM CPUs is dramatic. Libraries like libsodium default to ChaCha20 and provide a simple API.
IoT and embedded: ChaCha20-Poly1305 is almost always the right choice. IoT processors (ESP32, STM32, older ARM Cortex-M) rarely have AES hardware acceleration, and the simpler ARX operations of ChaCha20 are easier to implement correctly in constrained environments. The smaller code footprint also matters when flash storage is limited.
VPN: WireGuard uses ChaCha20-Poly1305 exclusively and outperforms OpenVPN (which typically uses AES-256-GCM) in throughput tests on identical hardware — partly because WireGuard's protocol is simpler, partly because ChaCha20 avoids cipher negotiation overhead. For enterprise VPNs requiring FIPS compliance, use AES-256-GCM through an approved module.
Email encryption (PGP/S-MIME): RSA-4096 or ECC (Curve25519) for key exchange, AES-256 for message encryption. GPG 2.x defaults to this combination. For new key generation, prefer ECC over RSA — smaller keys, faster operations, equivalent security.
Digital signatures: Ed25519 (EdDSA on Curve25519) for new applications — faster than RSA, smaller signatures, simpler implementation. RSA-PSS (with SHA-256 or SHA-512) for environments that require NIST-approved algorithms. Use RSA-4096 for signing keys that need to remain valid beyond 2030.
Common Implementation Mistakes That Break Encryption
The algorithm you choose matters far less than how you implement it. Here are the mistakes that actually cause real-world encryption failures:
Using ECB mode. ECB (Electronic Codebook) encrypts each block independently with the same key, meaning identical plaintext blocks produce identical ciphertext blocks. This leaks patterns in your data — the famous "ECB penguin" image demonstrates this: encrypting a bitmap image with AES-ECB preserves the visible shape of the penguin. Never use ECB mode for anything except possibly encrypting a single block of random data. This mistake still appears in production code regularly.
Reusing nonces/IVs. Both AES-GCM and ChaCha20-Poly1305 have catastrophic failure modes if you encrypt two different messages with the same key and nonce. For AES-GCM, nonce reuse leaks the authentication key, allowing an attacker to forge messages and decrypt previous communications. Use a counter-based nonce (preferred for sequential operations) or a random 96-bit nonce (safe for up to approximately 2^32 messages per key before the birthday bound creates collision risk). If you need to encrypt more than 4 billion messages under the same key, switch to AES-256-GCM-SIV, which provides nonce-misuse resistance.
Encrypting without authenticating. Encryption without authentication (like AES-CTR or AES-CBC alone) allows attackers to modify the ciphertext and potentially learn about the plaintext. Always use authenticated encryption: AES-GCM, ChaCha20-Poly1305, or AES-CCM. If you must use an unauthenticated mode for legacy reasons, add HMAC with Encrypt-then-MAC ordering.
Weak key derivation. If your encryption key comes from a user password, you must use a purpose-built key derivation function — Argon2id (preferred), scrypt, or PBKDF2 with at least 600,000 iterations (OWASP recommendation for 2026). Using a simple SHA-256 hash of a password as an encryption key is vulnerable to dictionary and brute-force attacks. Raw SHA-256 computes billions of hashes per second on a GPU; Argon2id with recommended parameters takes hundreds of milliseconds per attempt, making brute-force infeasible.
Rolling your own crypto. Do not implement AES, RSA, or ChaCha20 from scratch. Use established libraries: libsodium (recommended — high-level API that makes misuse difficult), OpenSSL, BoringSSL, Windows CNG, Apple CryptoKit, or Java's javax.crypto. These libraries have been audited, optimized, and battle-tested. Your hand-rolled implementation will not match their security, performance, or side-channel resistance.
Quantum-Readiness: Planning Your Migration
Quantum computing threatens asymmetric algorithms (RSA, ECDH, ECDSA) far more than symmetric ones. Here is your practical timeline:
No action needed now for AES and ChaCha20. Both AES-256 and ChaCha20 retain 128-bit effective security against quantum computers (Grover algorithm), which is safe. If you are using AES-128, consider upgrading to AES-256 as a low-effort quantum hedge — the performance difference is minimal with AES-NI.
Begin RSA/ECC migration planning now. NIST published three post-quantum cryptography standards in 2024: ML-KEM (FIPS 203, based on CRYSTALS-Kyber) for key encapsulation, ML-DSA (FIPS 204, based on CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (FIPS 205, based on SPHINCS+) as a backup signature scheme. For organizations handling classified data or long-lived secrets (data that must remain confidential for 20+ years), begin hybrid deployments that combine classical algorithms (RSA/ECDH) with post-quantum algorithms (ML-KEM) to protect against both classical and quantum adversaries.
Inventory your cryptographic dependencies. Create a cryptographic bill of materials (CBOM) listing every algorithm, key size, library, and protocol your systems use. This inventory is the foundation for migration planning. Tools like Symantec Cryptographic Assessment and IBM's Quantum Safe Explorer can automate this inventory for large environments.
The "harvest now, decrypt later" threat is real: adversaries (particularly nation-state actors) may be collecting encrypted data today with the intent to decrypt it once quantum computers are available. If your data has long-term sensitivity (healthcare records, government secrets, financial data, intellectual property), the time to add post-quantum protection is now — not when quantum computers arrive.
Decision Framework: Choosing Your Algorithms
Use this decision tree for algorithm selection in 2026:
What are you encrypting? If bulk data (files, disk, database, network traffic) — you need a symmetric cipher (AES or ChaCha20). If you are exchanging keys or signing data — you need an asymmetric algorithm (RSA, ECDH, Ed25519).
For symmetric encryption — does your hardware have AES-NI? If yes (servers, modern desktops, Apple devices, flagship Android), use AES-256-GCM. If no or uncertain (IoT, budget mobile, embedded, diverse client base), use ChaCha20-Poly1305. If you support both types of hardware (like a web server serving all clients), configure both and let TLS negotiate.
For asymmetric operations — is FIPS/NIST compliance required? If yes, use RSA-3072+ for key exchange, ECDSA P-256 for signatures, and plan for ML-KEM/ML-DSA migration. If no compliance requirement, use X25519 for key exchange and Ed25519 for signatures — they are faster, simpler to implement correctly, and have excellent security margins.
Does the data need quantum-resistant protection? If the data must remain confidential for 20+ years, begin hybrid deployments combining classical + post-quantum algorithms now. For shorter-term data protection, classical algorithms with the quantum migration planned for 2028-2030 is sufficient.
The bottom line: there is no single "best" encryption algorithm. AES-256-GCM is the right default for most server-side and storage workloads. ChaCha20-Poly1305 is the right default for mobile, IoT, and diverse-hardware deployments. RSA is being gradually replaced by elliptic curve alternatives for key exchange and signatures. And all three classical algorithm families will eventually transition to post-quantum replacements — AES and ChaCha20 need only key size adjustments, while RSA and ECC face complete algorithm replacement. Know your hardware, know your compliance requirements, and pick the algorithm that matches your actual deployment.
