RSA-2048 vs RSA-4096: key size, speed, the 2030 deadline

RSA-2048 vs RSA-4096 is the most common key-size question in PKI. RSA-2048 is the minimum allowed for publicly trusted certificates and sits at NIST's 112-bit security level; RSA-4096 sits well above 128 bits. The cost of the larger key shows up in signing time, key generation time and every signature on the wire, so the right answer depends on how often a key signs and how long it must stay trustworthy.

At a glance

Measured with openssl speed rsa2048 rsa3072 rsa4096 on one core of an Apple M4 Max.

Security margin

RSA security comes from the difficulty of factoring the modulus with the general number field sieve, whose cost grows sub-exponentially with key size, which is why RSA keys must grow much faster than elliptic-curve keys. NIST SP 800-57 Part 1 equates 2048-bit RSA with 112-bit security, 3072 bits with 128 and 7680 with 192; it gives no row for 4096 bits, which falls between 128 and 192. The largest publicly factored RSA challenge number has 829 bits (RSA-250, 2020), far from 2048.

The deadline that matters more is quantum. Shor's algorithm factors all three sizes in polynomial time on a large fault-tolerant quantum computer, and doubling the key roughly doubles the qubits and increases the run time modestly; it does not change the outcome. Craig Gidney's 2025 estimate put RSA-2048 at under a week on fewer than one million noisy qubits. NIST IR 8547 (an initial public draft) therefore proposes the same end date, 2035, for every RSA size, with RSA-2048 additionally deprecated after 2030 because of its 112-bit classical level. RSA-4096 extends your classical margin; it does not extend your post-quantum deadline.

Performance

Private-key operations grow roughly with the cube of the modulus size, public-key operations with the square:

openssl speed -seconds 2 rsa2048 rsa3072 rsa4096

                   sign    verify    encrypt   decrypt   sign/s verify/s  encr./s  decr./s
rsa  2048 bits 0.000334s 0.000009s 0.000009s 0.000339s   2994.9 114178.1 108513.6   2950.3
rsa  3072 bits 0.000957s 0.000019s 0.000019s 0.000965s   1044.7  53948.7  52312.0   1036.7
rsa  4096 bits 0.002117s 0.000032s 0.000032s 0.002121s    472.4  31522.3  30870.7    471.6

For a TLS server that signs once per full handshake, moving from 2048 to 4096 multiplies that cost by about six. For a CA root that signs a few intermediates per decade, the cost is irrelevant. Key generation also slows sharply because it searches for two large primes: about 26 ms on average for 2048 bits on this machine against a quarter of a second for 4096, with a long tail, which matters on small devices and in tests that generate keys repeatedly.

Verification stays cheap at every size because the public exponent is small (65537), which is why RSA keeps its place in certificate chains verified billions of times.

Hardware and protocol limits

Size limits come from the surroundings more than from RSA itself:

• Smart cards and tokens: many PIV cards and older security tokens support RSA-2048 only; newer devices add 3072 and 4096. Check before ordering hardware.
• HSMs and cloud KMS: all three sizes are standard (AWS KMS offers RSA_2048, RSA_3072 and RSA_4096), but per-operation pricing and throughput limits make 4096 noticeably more expensive at volume.
• DNS: a 4096-bit DKIM key is 736 base64 characters and must be split into several TXT strings; some DNS providers and old resolvers handle long records badly. DNSSEC zones with RSA-4096 produce large responses that may need TCP.
• Certificate chains: each RSA-4096 certificate adds about 512 bytes of signature and 550 bytes of key compared with a few hundred bytes for ECDSA, which matters for constrained clients.

When to choose which

• New TLS server certificates: ECDSA P-256 first; if it must be RSA, RSA-2048 is still accepted by every client and CA, but RSA-3072 gives a margin beyond 2030.
• Root and long-lived intermediate CAs: RSA-4096 (or ECDSA P-384); signing cost is negligible and lifetimes are long. Let's Encrypt's ISRG Root X1 is RSA-4096 while its RSA intermediates are RSA-2048.
• JWT signing (RS256): RSA-2048 is common and allowed (RFC 7518 requires at least 2048), RSA-3072 for new keys; consider ES256 instead.
• SSH keys: prefer Ed25519; if RSA, at least 3072.
• Code-signing and document-signing keys: RSA-3072 or 4096, matching the CA's offering and the signature's expected lifetime, plus timestamps.
• Constrained hardware: what it supports, usually RSA-2048, with a documented replacement plan.

Migration notes

Changing RSA key size means a new key pair and, for certificates, a new certificate.

1. Inventory keys by size: certificates (openssl x509 -noout -text), JWKS (n length), SSH keys (ssh-keygen -l), DKIM records and HSM key handles. RSA-2048 keys with lifetimes past 2030 are the first to rotate.
2. Generate new keys in place: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072, or the HSM's equivalent; avoid exporting keys to resize them.
3. Overlap old and new keys: publish both in JWKS with distinct kid values, add the new DKIM selector before switching, serve both SSH host keys during the transition.
4. Test consumers with the larger key: fixed-size buffers, DNS record limits and embedded TLS stacks are the usual failures.
5. Use the rotation to reconsider the algorithm: if every consumer supports ECDSA or EdDSA, moving off RSA entirely is usually the better investment, and post-quantum signatures will need a further rotation before 2035.

References

• NIST SP 800-57 Part 1 Rev. 5, Table 2
• NIST IR 8547 initial public draft
• FIPS 186-5 §5, RSA
• RFC 8017, PKCS #1 v2.2
• RFC 7518 §3.3, minimum RSA key size for JWS
• Gidney (2025), factoring RSA-2048 with less than a million noisy qubits
• CA/Browser Forum Baseline Requirements §6.1.5