Ask a developer whether to encrypt a database with AES-256 or RSA and you’ll often get a confused pause. The two algorithms get compared constantly in interviews, security audits, and Stack Overflow threads, yet they solve different problems. AES-256 locks up the data itself. RSA locks up the key that unlocks the data, or signs a certificate so you know who you’re talking to. Mixing up their jobs is one of the most common mistakes junior engineers make when designing an encryption scheme, and it’s also why “AES vs RSA” remains one of the most searched cryptography comparisons heading into the back half of 2026.
This matters more this year than in previous ones. NIST’s SP 800-131A Rev. 3 draft sets a hard deadline of December 31, 2030 after which RSA-2048 gets deprecated for new digital signatures and key establishment, and the “harvest-now-decrypt-later” threat model has pushed 87% of security and IT leaders into active concern about data captured today being cracked once quantum hardware matures, according to a 2026 industry report cited by NIST-aligned researchers. AES-256 sits on the other side of that line: Grover’s algorithm only halves its effective strength against a quantum attacker, leaving roughly 128 bits of post-quantum security intact. RSA gets no such cushion. Shor’s algorithm breaks it outright once a large enough quantum computer exists.
This guide breaks down what AES-256 encryption and RSA actually do, where their performance diverges by orders of magnitude, how TLS 1.3 uses both at once, and which one you should reach for depending on the system you’re building. We’ll cover benchmarks pulled from three separate sources, a full specs table, pricing considerations for cloud key management, migration guidance, and a data-backed verdict.
AES-256 vs RSA: the short answer
AES-256 is a symmetric-key block cipher. The same 256-bit key encrypts and decrypts data, and it does so fast: hundreds of megabytes per second in pure software, multiple gigabytes per second with AES-NI hardware acceleration on modern CPUs. RSA is an asymmetric algorithm built on the difficulty of factoring large integers. It uses a public key to encrypt or verify and a separate private key to decrypt or sign, and it’s slow by comparison, measured in thousands of operations per second rather than gigabytes.
In practice you almost never choose one over the other. TLS 1.3, disk encryption, VPN tunnels, and password managers all use both: RSA (or increasingly elliptic-curve alternatives) to establish trust and exchange a session key, then AES-256 to encrypt the actual traffic or files. That’s called hybrid encryption, and it’s been the standard architecture for encrypted communication since the 1990s. Understanding when each algorithm does its job, and where the seams in that architecture are showing strain in 2026, is what this comparison sets out to explain.
What is AES-256 encryption?
AES, the Advanced Encryption Standard, became a federal standard in 2001 when NIST published FIPS 197. It replaced DES after a public competition that Belgian cryptographers Joan Daemen and Vincent Rijmen won with their Rijndael cipher. AES-256 is the variant that uses a 256-bit key and runs 14 transformation rounds on 128-bit blocks of data, each round substituting bytes, shifting rows, mixing columns, and adding a round key derived from the original secret. AES-128 uses the same structure with 10 rounds, and AES-192 sits in between at 12, but AES-256’s extra rounds are what buy it the largest security margin of the three.
The security of AES-256 doesn’t rest on a hard math problem the way RSA’s does. It rests on the sheer size of the key space. A 256-bit key has roughly 1.16 × 10^77 possible values. Cryptographer Bruce Schneier’s often-cited thermodynamic argument holds that even an idealized computer powered by the sun’s total annual energy output couldn’t brute-force a key that large. The energy needed to flip enough bits exceeds what’s physically available in the solar system. At an optimistic trial rate of one billion keys per second, exhausting the AES-256 keyspace would take on the order of 3.67 × 10^57 millennia. No credible cryptanalytic attack against full AES-256 exists as of August 2026.
AES ships in several modes, and the mode matters as much as the key size for real-world security. GCM (Galois/Counter Mode) has become the default for TLS and most modern applications because it provides both confidentiality and built-in authentication in a single pass, protecting against tampering as well as eavesdropping. CBC mode still shows up in disk encryption tools like BitLocker and VeraCrypt, usually paired with a separate HMAC for authentication since CBC alone doesn’t provide it. XTS mode, a CBC variant designed specifically for disk sectors, avoids the need for a per-block initialization vector to be stored separately. Whatever the mode, the underlying cipher and 256-bit key strength stay the same, which is why mode selection, not key size, is usually where implementation mistakes creep in.
What is RSA encryption?
RSA takes its name from Ron Rivest, Adi Shamir, and Leonard Adleman, who published the algorithm in 1977. It’s built on a deceptively simple asymmetry: multiplying two large prime numbers together is fast, but factoring the resulting product back into its two primes is, for numbers of sufficient size, computationally infeasible with classical computers. That asymmetry lets RSA generate a public key anyone can use to encrypt a message or verify a signature, paired with a private key only the owner holds that can decrypt or sign.
Key size matters enormously for RSA because its security doesn’t scale the way symmetric ciphers do. NIST SP 800-57 Part 1 maps out the comparable strength between RSA modulus size and symmetric key bits: RSA-2048 lands around 112-bit security, RSA-3072 reaches roughly 128-bit security (comparable to AES-128, not AES-256), and matching AES-256’s full 256-bit strength would require an RSA modulus of 15,360 bits, a size so unwieldy that nobody deploys it in production. That gap is the single most misunderstood fact in this comparison. RSA-3072 is not “as strong as AES-256.” It’s roughly equivalent to AES-128.
RSA-2048 remains the de facto minimum in TLS and PKI deployments today, per NIST’s own guidance summaries, but that clock is running out. SP 800-131A Rev. 3’s initial public draft states plainly that RSA keys between 2048 and 3071 bits are acceptable through December 31, 2030, after which they become deprecated for new signature generation and key establishment and permitted only for processing legacy data. Organizations issuing new long-lived certificates are already shifting toward RSA-3072 or moving to elliptic-curve alternatives like Ed25519, which we’ve covered in a separate performance comparison.
RSA also comes with implementation traps that AES-256 mostly avoids. Padding schemes matter enormously: the older PKCS#1 v1.5 padding is vulnerable to Bleichenbacher-style oracle attacks if implemented carelessly, which is why modern deployments use OAEP for encryption and PSS for signatures instead. Key generation is slower too, since finding two large primes that satisfy RSA’s constraints takes noticeably longer than generating a random 256-bit AES key, though this only matters at setup time rather than during ongoing use.
AES-256 vs RSA: full specs comparison
The table below lines up the two algorithms across the properties that actually drive engineering decisions: key structure, standard, quantum exposure, and where each one shows up in a typical TLS 1.3 handshake.
| Property | AES-256 | RSA (2048/3072/4096) |
|---|---|---|
| Algorithm type | Symmetric block cipher | Asymmetric (public-key) |
| Key structure | Single 256-bit shared secret | Public/private key pair |
| Underlying hard problem | Keyspace exhaustion (brute force) | Integer factorization |
| Governing standard | FIPS 197 (2001) | PKCS#1 / FIPS 186-5 (signatures) |
| Typical key sizes in use | 256-bit (fixed) | 2048-bit, 3072-bit, 4096-bit |
| NIST security strength | 256-bit | 112-bit (2048), ~128-bit (3072) |
| Software throughput | ~200-500 MB/s | Thousands of ops/sec (2048), hundreds (4096) |
| Hardware-accelerated throughput | 3.2-10+ GB/s with AES-NI | No equivalent bulk-data acceleration |
| Primary role in TLS 1.3 | Bulk data encryption | Certificate/signature authentication only |
| Quantum threat | Grover’s algorithm (quadratic speedup, ~128-bit residual) | Shor’s algorithm (breaks it outright) |
| NIST 2030 deprecation risk | None | RSA-2048 deprecated for new use after Dec 31, 2030 |
| FIPS 140-3 module status | Core validated primitive | Validated, but shrinking key-size headroom |
| Data size suitability | Any size, including gigabytes | Small payloads only (keys, hashes, signatures) |
Performance benchmarks: AES-256 vs RSA
The performance gap between these two algorithms isn’t a rounding error. It’s several orders of magnitude, and it’s the entire reason hybrid encryption exists. Below are figures pulled from three separate benchmark sources published in 2024 through 2026.
| Benchmark | AES-256 | RSA-2048 | RSA-4096 |
|---|---|---|---|
| OpenSSL-style x86-64 synthesis (no RSA hardware, 2026) | 200-500 MB/s software, 3.2-10+ GB/s with AES-NI | 300-4,200 signs/sec, 10,000-135,000 verifies/sec | 30-580 signs/sec, 1,800-35,000 verifies/sec |
| 2024 controlled academic comparison (AES-256-CBC) | Up to ~433,893 KB/s (~424 MB/s) | ~7,140 private ops/sec, ~229,613 public ops/sec | ~1,099 private ops/sec, ~68,179 public ops/sec |
| Ash Vardanian cipher-tuning benchmark, Intel Ice Lake (2025) | 577-2,617 MB/s (AES-256-GCM, with AES-NI) | Not benchmarked (different workload class) | Not benchmarked |
The Ash Vardanian benchmark is worth a closer look because it isolates the exact variable that decides most real deployments: whether AES-NI is present. On an Intel Ice Lake server with AES-NI engaged, AES-256-GCM pulled ahead of ChaCha20-Poly1305 for large records, hitting roughly 2.6 GB/s versus ChaCha20’s 1.2 GB/s on Intel Ice Lake. RSA doesn’t enter that comparison at all, since nobody uses it for streaming bulk data. The comparison that actually matters for RSA is operations per second on small payloads: certificate signing, JWT signing, code-signing events, the kind of infrequent, latency-tolerant tasks RSA was designed for.
Two things jump out. First, AES-256 handles data volume that RSA simply isn’t built for. On a modern server with AES-NI, encrypting a gigabyte of data takes a fraction of a second. Signing that same gigabyte with RSA-4096 directly would take minutes even at the higher end of the benchmark ranges, and that’s before accounting for the padding and chunking overhead RSA needs for anything larger than its modulus. Second, RSA’s private-key operations (signing and decryption) are far slower than its public-key operations (verification and encryption), which is why certificate verification on a client feels instant while a certificate authority’s signing infrastructure needs dedicated hardware security modules to keep up with request volume.
This is also why nobody encrypts a video file, a database backup, or a VPN tunnel’s payload with RSA directly. Every real-world system that uses RSA pairs it with a symmetric cipher, almost always AES-256 or ChaCha20-Poly1305, and reserves RSA for the small, infrequent job of protecting or authenticating the symmetric key itself. We covered the ChaCha20 side of that symmetric-cipher choice in our ChaCha20-Poly1305 vs AES-256-GCM benchmark comparison if you’re deciding between the two bulk ciphers rather than between symmetric and asymmetric approaches.
How TLS 1.3 actually uses both algorithms
A common point of confusion: doesn’t HTTPS use RSA to encrypt your traffic? Not anymore, and this is where a lot of outdated tutorials lead people astray. TLS 1.3, standardized in RFC 8446, removed RSA key transport entirely. Every TLS 1.3 handshake negotiates its session keys through ephemeral Diffie-Hellman (ECDHE), which provides forward secrecy that static RSA key exchange never could. If an attacker steals a server’s private RSA key years later under the old TLS 1.2 RSA key-exchange model, they could theoretically decrypt every past session they’d recorded. ECDHE breaks that chain because each session gets a fresh, throwaway key pair.
So where does RSA still fit into TLS 1.3? Authentication. The server’s certificate carries an RSA (or ECDSA) public key, and the server proves it holds the matching private key by signing part of the handshake transcript, typically using rsa_pss_rsae_sha256 or a similar signature scheme. Once that identity check passes and the ECDHE key exchange completes, every byte of your actual traffic, the HTML, the images, the API calls, gets encrypted with AES-256-GCM or ChaCha20-Poly1305. RSA touches the handshake for a few milliseconds. AES-256 does the heavy lifting for the rest of the connection.
This division of labor is also why post-quantum migration efforts have focused first on the key-exchange step rather than the bulk cipher. NIST’s ML-KEM standard, finalized in FIPS 203, is designed to replace the ECDHE (and by extension the RSA-signed trust anchor) portion of the handshake with a quantum-resistant alternative, while AES-256 stays exactly as it is. We go deeper into that transition in our ML-KEM vs X25519 in TLS 1.3 breakdown and our ML-KEM vs RSA comparison.
CDN operators have been tracking this shift for years through raw traffic telemetry, and the pattern is consistent with what NIST’s roadmap predicts: AES-GCM cipher suites, spanning both AES-128 and AES-256, account for the large majority of observed TLS traffic, with ChaCha20-Poly1305 picking up a meaningfully higher share specifically on mobile and Android-heavy connections where AES-NI-equivalent hardware support is less universal. Cloudflare documented this exact split in its analysis of ChaCha20 versus AES-GCM adoption across its own edge network, and the underlying logic hasn’t changed since: clients and servers negotiate whichever bulk cipher their hardware handles fastest, and RSA or ECDSA simply authenticates whichever choice gets made.
The quantum computing threat: Shor’s algorithm vs Grover’s algorithm
This is where AES-256 and RSA part ways most dramatically, and it’s the reason security teams are treating this comparison as more than academic in 2026. Shor’s algorithm, first published by Peter Shor in 1994, can factor large integers in polynomial time on a sufficiently powerful quantum computer. RSA’s entire security model depends on factoring being hard. Once a quantum computer with enough stable qubits exists, Shor’s algorithm doesn’t just weaken RSA, it breaks it completely, reducing effective security toward zero regardless of whether you’re using RSA-2048 or RSA-15360.
AES-256 faces a different, far less severe quantum threat. Grover’s algorithm offers only a quadratic speedup for brute-force key search against symmetric ciphers. Per NIST SP 800-57 guidance, that leaves AES-256 with roughly n/2 bits of effective security against an idealized quantum attacker, which works out to about 128 bits, still comfortably beyond what any foreseeable computer, classical or quantum, could exhaust. That asymmetry is exactly why NIST’s post-quantum cryptography project has spent its effort replacing RSA and elliptic-curve key exchange with lattice-based schemes like ML-KEM, while leaving AES-256 untouched as the bulk-encryption workhorse.
The practical fallout shows up in “harvest-now-decrypt-later” concerns. Encrypted traffic recorded today that relied on RSA for key establishment could, in theory, be decrypted retroactively once a cryptographically relevant quantum computer exists, even if that’s years away. A 2026 industry survey found 87% of security and IT leaders concerned about exactly this scenario, and more than eight in ten respondents believe at least some of their currently encrypted data is already vulnerable to future decryption. Traffic protected purely with AES-256 for the payload doesn’t carry the same retroactive risk, since Grover’s algorithm can’t realistically threaten a 256-bit symmetric key even decades out. The exposure sits specifically in how the AES key got exchanged in the first place, which loops back to RSA or ECDHE.
Security strength: key size doesn’t mean what people think
One of the most persistent myths in cryptography discussions is that a “2048-bit” or “4096-bit” RSA key is stronger than a “256-bit” AES key because the number is bigger. It’s not, and NIST SP 800-57 Part 1’s comparable-strength table settles the question directly. Here’s how the two actually line up.
| NIST security strength | Equivalent RSA modulus | Equivalent AES key |
|---|---|---|
| 80-bit (no longer allowed for new use) | RSA-1024 | — |
| 112-bit | RSA-2048 | — |
| 128-bit | RSA-3072 | AES-128 |
| 192-bit | RSA-7680 | AES-192 |
| 256-bit | RSA-15360 | AES-256 |
Matching AES-256’s actual strength with RSA alone would require a 15,360-bit modulus, a key so large that generating, storing, and transmitting it becomes its own engineering headache, and one that essentially nobody deploys. That gap explains why serious long-term-security designs pair AES-256 with elliptic-curve or post-quantum key exchange rather than trying to scale RSA indefinitely. RSA-3072, the size NIST is pushing organizations toward ahead of the 2030 RSA-2048 deprecation, only reaches AES-128-equivalent strength, not AES-256.
Hardware acceleration and real-world throughput
AES-256 benefits from a hardware advantage RSA never got. Intel and AMD have baked AES-NI instructions into consumer and server CPUs since 2010, turning what used to be a CPU-intensive operation into a handful of dedicated instructions per round. That’s the difference between the 200-500 MB/s AES-256 achieves in pure software and the 3.2-10+ GB/s it hits with AES-NI engaged, according to the OpenSSL-style benchmark synthesis referenced above. ARM chips followed with their own Cryptography Extensions, so mobile devices, cloud instances, and even most IoT boards built in the last decade get AES-256 acceleration essentially for free.
RSA has no equivalent bulk-data accelerator because it was never designed to touch bulk data. Certificate authorities and high-volume signing services instead lean on hardware security modules (HSMs), purpose-built appliances that isolate private keys and parallelize signing operations across dedicated silicon. That’s a fundamentally different scaling strategy: AES-256 gets faster because commodity CPUs do the work natively, while RSA gets faster by throwing specialized, expensive hardware at a comparatively small number of operations per second.
Cost and deployment overhead
Neither algorithm carries a licensing fee. Both are public, patent-free, and implemented in every major cryptography library. The cost differences that actually show up on a cloud bill come from how each algorithm gets used operationally, through key management services and compute overhead.
| Cost factor | AES-256 | RSA |
|---|---|---|
| AWS KMS symmetric operations | $0.03 per 10,000 requests | $0.15 per 10,000 requests (asymmetric tier) |
| Azure Key Vault (software-protected keys) | $0.03 per 10,000 transactions | HSM RSA-2048: ~$1.00 per 10,000; RSA-3072/4096: ~$5.00 per 10,000 |
| Google Cloud KMS | $0.03 per 10,000 operations (symmetric) | $0.15 per 10,000 operations (asymmetric) |
| Customer-managed key storage (AWS) | $1 per key per month | $1 per key per month |
| Compute overhead (c6i.large, AES-NI-capable) | ~$0.085-$0.09/hr, negligible extra cost for encryption | Same base instance cost; signing-heavy workloads may need dedicated HSM budget |
The pattern across all three major cloud providers is consistent: symmetric operations, where AES-256 lives, cost roughly a fifth of what asymmetric operations, where RSA lives, cost per 10,000 calls. That’s not a pricing quirk. Asymmetric key management involves more computationally expensive operations on the provider’s end and, for RSA specifically, often larger keys to store and protect. For an application doing millions of encrypt/decrypt calls a day, that pricing gap over time favors architectures that lean on AES-256 for anything data-heavy and reserve RSA calls for infrequent authentication events, which is exactly the hybrid pattern TLS already uses.
Real-world examples: who uses what
- HTTPS and TLS 1.3: RSA (or ECDSA) signs the server certificate for authentication, and AES-256-GCM or ChaCha20-Poly1305 encrypts every subsequent byte of the session.
- BitLocker and VeraCrypt full-disk encryption: AES-256 (often in XTS mode) encrypts the actual disk sectors. A separate key-wrapping step, sometimes RSA-based in enterprise deployments, protects the volume key.
- Signal and WhatsApp: AES-256 encrypts message content inside the Signal Protocol, while X3DH key agreement (elliptic-curve, not RSA) establishes the shared secret, reflecting the broader industry shift away from RSA for key exchange.
- PGP and S/MIME email encryption: RSA (or increasingly ECC) encrypts a short, randomly generated AES-256 session key, which then encrypts the actual email body and attachments.
- Password managers like 1Password and Bitwarden: AES-256 encrypts the local vault. RSA or elliptic-curve keys are largely absent from the vault-encryption path itself, since there’s no second party needing a public key.
- Cloud storage encryption (S3, Azure Blob, GCS): AES-256 encrypts objects at rest by default, and RSA-backed KMS keys can wrap the AES data key for centralized access control.
Notice the pattern repeating across every example. AES-256 sits directly on top of the data in every single case, encrypting messages, disk sectors, vault contents, and stored objects. RSA, when it shows up at all, is always one step removed: signing a certificate, wrapping a key, or authenticating a handshake. That consistency isn’t a coincidence. It’s the direct result of the performance and key-size math covered earlier in this comparison, and it’s why security reviewers get suspicious the moment they see RSA touching a large payload directly. If you’re auditing code and spot `RSA.encrypt()` being called on anything larger than a session key, that’s usually a sign the hybrid pattern got skipped somewhere it shouldn’t have been.
Migration guide: moving from legacy RSA key exchange to a hybrid AES-256 architecture
If you’re maintaining a system that still relies on old-style RSA key transport, TLS 1.2 with RSA cipher suites, custom file-encryption tools that use RSA to encrypt entire payloads, or certificates sitting below the 2030 NIST deprecation line, here’s the practical path forward.
- Audit your TLS configuration. Check whether your server still offers RSA key-exchange cipher suites (identifiable by suite names without “DHE” or “ECDHE”). Disable them. TLS 1.3 already removes RSA key transport by default, so upgrading your minimum protocol version handles most of this automatically.
- Inventory certificate key sizes. Run an audit of every RSA certificate in your PKI and flag anything at 2048 bits. You have until December 31, 2030 under current NIST guidance, but rotating early avoids a scramble later.
- Move new certificates to RSA-3072 or ECDSA/Ed25519. RSA-3072 buys you 128-bit strength. Elliptic-curve alternatives get there with far smaller keys and faster signing, which is why most major CAs now default to ECDSA for new issuance.
- Never use RSA to encrypt bulk data directly. If you find code that RSA-encrypts a whole file or database export, refactor it to generate a random AES-256 key, encrypt the data with AES-256-GCM, and use RSA (or better, an HSM-backed KMS key) only to wrap that small AES key.
- Verify AES-NI is enabled on your compute layer. Most cloud instances and modern CPUs have it by default, but confirm on any legacy or embedded hardware, since software-only AES falls to a fraction of accelerated throughput.
- Track post-quantum key-exchange rollout. Start testing hybrid ECDHE + ML-KEM configurations in non-production environments now. Your AES-256 bulk cipher won’t need to change, but the key-establishment step feeding it will.
Here’s what a basic hybrid encryption pattern looks like in code, generating a random AES-256 key, encrypting the payload, then wrapping the key with RSA-OAEP for transport:
// Node.js example: hybrid AES-256-GCM + RSA-OAEP key wrapping
const crypto = require('crypto');
// 1. Generate a random AES-256 key for the actual data
const aesKey = crypto.randomBytes(32); // 256 bits
const iv = crypto.randomBytes(12);
// 2. Encrypt the payload with AES-256-GCM
const cipher = crypto.createCipheriv('aes-256-gcm', aesKey, iv);
const encrypted = Buffer.concat([cipher.update(payload), cipher.final()]);
const authTag = cipher.getAuthTag();
// 3. Wrap the AES key with the recipient's RSA public key
const wrappedKey = crypto.publicEncrypt(
{ key: recipientPublicKey, padding: crypto.constants.RSA_PKCS1_OAEP_PADDING },
aesKey
);
// Transmit: wrappedKey + iv + authTag + encrypted
// Only the recipient's RSA private key can unwrap aesKey,
// which is the only thing that can decrypt the payload.Use case recommendations
The right choice almost never comes down to “AES-256 or RSA” in isolation. It comes down to what role you need filled.
- Encrypting files, databases, or backups at rest: Use AES-256-GCM directly. There’s no reason to involve RSA unless you need to share access with a specific keyholder.
- Securing a web application over HTTPS: Let TLS 1.3 handle it. RSA or ECDSA authenticates the certificate, and AES-256-GCM or ChaCha20-Poly1305 covers the session automatically.
- Sharing an encrypted file with someone whose public key you have: Hybrid encryption is correct here, an AES-256 key wraps the data, RSA-OAEP or an elliptic-curve equivalent wraps the AES key.
- Signing software releases or firmware updates: RSA (or Ed25519 for better performance) is the right tool, since signatures verify authenticity rather than provide bulk confidentiality.
- Encrypting traffic on IoT or embedded devices with limited CPU: Favor AES-256 with hardware acceleration where available. Avoid RSA operations on constrained devices, since even RSA-2048 signing can take a noticeable fraction of a second on low-power silicon.
- Long-term data retention where “harvest-now-decrypt-later” is a real threat model: Don’t rely on RSA-based key exchange alone for anything that needs to stay confidential past 2030-2035. Start piloting post-quantum hybrid key establishment now, while keeping AES-256 as the unchanged bulk cipher.
Pros and cons
AES-256
- Extremely fast, especially with AES-NI hardware acceleration (multiple GB/s)
- 256-bit key strength holds up against quantum attacks (Grover’s algorithm only halves it)
- No known practical cryptanalytic break against the full cipher
- Core primitive in essentially every FIPS 140-3 validated module
- Cheapest tier in every major cloud KMS pricing structure
- Cannot establish a shared secret between two parties who’ve never met, and requires an out-of-band or asymmetric mechanism to distribute the key
- A single leaked key compromises everything encrypted with it, with no forward secrecy on its own
RSA
- Solves the key-distribution problem: no shared secret needs to exist beforehand
- Well-understood, decades of scrutiny, broad library and hardware support
- Doubles as a signature scheme for authentication, not just encryption
- Orders of magnitude slower than AES-256, unsuitable for bulk data
- Key sizes needed for long-term security (RSA-15360 to match AES-256) are impractically large
- Broken outright by Shor’s algorithm once large-scale quantum computers exist
- NIST is actively deprecating RSA-2048 for new use starting December 31, 2030
The verdict
AES-256 wins decisively on every metric that matters for encrypting actual data: throughput measured in gigabytes per second versus RSA’s thousands of operations per second, quantum resistance that holds at roughly 128-bit effective strength versus RSA’s total collapse under Shor’s algorithm, and cloud KMS pricing that runs about a fifth of RSA’s asymmetric-operation rate across AWS, Azure, and Google Cloud. If your task is “encrypt this data,” AES-256 is the answer, full stop.
RSA isn’t obsolete, but its job has narrowed. TLS 1.3 already stripped it out of key exchange in favor of ECDHE, leaving it responsible mainly for certificate signatures and authentication, a role it still performs reliably. The pressure it’s under isn’t really from AES-256, they were never competing for the same job, but from elliptic-curve alternatives that do RSA’s authentication job faster and from the 2030 NIST deprecation deadline that’s forcing a migration off RSA-2048 regardless. The realistic long-term picture for RSA is a shrinking niche, with ECDSA, Ed25519, and eventually post-quantum signature schemes taking over the authentication role while AES-256 keeps doing exactly what it’s always done for bulk encryption.
For most engineers building a new system in 2026, the practical takeaway is simple: use AES-256-GCM for anything resembling bulk data, let TLS 1.3 handle the handshake with modern cipher suites, and if you’re issuing new certificates, size RSA at 3072 bits or move to elliptic curve entirely. Don’t try to make RSA do AES-256’s job, and don’t try to make AES-256 solve RSA’s key-distribution problem. That division of labor is precisely why hybrid encryption has survived, largely unchanged in structure, for three decades.
Watch for a handful of mistakes that keep showing up in code review regardless of which algorithm a team picks. Reusing an AES-GCM nonce across multiple encryptions with the same key silently destroys the authentication guarantees GCM is supposed to provide, so always generate a fresh 12-byte nonce per operation. On the RSA side, PKCS#1 v1.5 padding for encryption should be considered legacy at this point, since OAEP closes off a long history of padding-oracle attacks. And on both sides, key rotation policy matters more than algorithm choice: an AES-256 key that never rotates and an RSA certificate that sits unrenewed for a decade both become the weak point in an otherwise sound design, regardless of how strong the underlying math is.
Frequently asked questions
Is AES-256 stronger than RSA-2048?
Yes, by a wide margin. AES-256 provides 256-bit security strength, while RSA-2048 provides roughly 112-bit security strength according to NIST SP 800-57. Matching AES-256’s strength with RSA alone would require a 15,360-bit key, which nobody deploys in practice.
Can RSA replace AES-256 for encrypting files?
Technically yes for very small files, but not practically. RSA can only encrypt data smaller than its modulus size minus padding, roughly 190 bytes for RSA-2048 with OAEP padding, and it’s orders of magnitude slower than AES-256. Every real system encrypts data with AES-256 and uses RSA only to wrap the AES key.
Does TLS 1.3 still use RSA?
Yes, but only for certificate authentication and signatures, not for key exchange. TLS 1.3 removed RSA key transport entirely in favor of ephemeral Diffie-Hellman (ECDHE), which provides forward secrecy. Bulk traffic encryption in TLS 1.3 uses AES-256-GCM or ChaCha20-Poly1305.
Will quantum computers break AES-256?
Not in any practically dangerous way. Grover’s algorithm gives quantum computers only a quadratic speedup against symmetric ciphers, leaving AES-256 with roughly 128 bits of effective post-quantum security, still far beyond what’s computationally feasible. RSA faces a much more severe threat from Shor’s algorithm, which can factor RSA’s underlying math outright.
What is “harvest-now-decrypt-later” and does it affect AES-256?
It’s the practice of recording encrypted traffic today with the intent to decrypt it once quantum computers become powerful enough. It primarily threatens the RSA or ECDHE key-exchange portion of a session, since Shor’s algorithm can eventually break those. The AES-256 payload encryption itself remains resistant even under this threat model, provided the key that protected it wasn’t established through a now-broken asymmetric method.
When does NIST deprecate RSA-2048?
Under the initial public draft of NIST SP 800-131A Rev. 3, RSA keys between 2048 and 3071 bits remain acceptable through December 31, 2030. After that date they’re deprecated for new digital signature generation and key establishment, and permitted only for processing legacy information.
Is AES-256 faster than RSA?
Substantially. AES-256 reaches hundreds of megabytes per second in software and multiple gigabytes per second with AES-NI hardware acceleration. RSA-2048, by contrast, manages roughly a few thousand private-key operations per second in software, and RSA-4096 drops into the hundreds. They’re not designed for the same workload, which is why AES-256 handles bulk data and RSA handles small, infrequent operations like signing.
Should I use RSA-3072 or move straight to elliptic curve?
For new deployments, elliptic-curve options like ECDSA or Ed25519 generally make more sense. They reach comparable or better security strength than RSA-3072 with smaller keys and faster signing, and most major certificate authorities already default to them for new issuance. RSA-3072 remains a valid fallback where legacy compatibility requires RSA specifically.
