Compare AES, RSA, Diffie-Hellman, ECC and hash key sizes at equal security strength, on NIST SP 800-57 Table 2 plus the CMVP formula for the rest.
SP 800-57 Part 1 Rev 5, Table 2. Note the top two rows: at 80 and 112 bits the symmetric algorithm is Triple-DES, not AES. FIPS 197 defines AES at 128, 192 and 256 bits only, and 3TDEA has been disallowed since 2023.
| Strength | Symmetric | DH L / N | RSA k | ECC f | Hash |
|---|---|---|---|---|---|
| ≤ 80 | 2TDEA | 1,024 / 160 | 1,024 | 160–223 | SHA-1 |
| 112 | 3TDEA | 2,048 / 224 | 2,048 | 224–255 | SHA-224 |
| 128 | AES-128 | 3,072 / 256 | 3,072 | 256–383 | SHA-256 |
| 192 | AES-192 | 7,680 / 384 | 7,680 | 384–511 | SHA-384 |
| 256 | AES-256 | 15,360 / 512 | 15,360 | 512+ | SHA-512 |
Quoted from the source documents. Where a standard is silent, that silence is recorded rather than filled in.
| Standard | Requirement | What the document says |
|---|---|---|
| NIST SP 800-57 | At least 112 bits now, 128 bits from 2031 | Table 4 grades strength as acceptable, legacy use or disallowed. It sets no expiry for 128 bits and above. |
| PCI DSS | At least 112 bits of effective key strength; 128 bits for new work | The PCI SSC glossary defines strong cryptography by effective key strength and warns that it "can be shorter than the actual 'bit' length of the key". |
| GDPR | No key size is specified | Article 32 requires measures "appropriate to the risk" taking account of "the state of the art", and names encryption as an example. It names no algorithm, key size or bit count. |
Security strengths are estimates of the cost of the best known attack, as published by NIST. They are not guarantees: an implementation flaw, a side channel, a weak random number generator or a stolen key defeats any key size. Check the requirements that apply to your own system before relying on these figures.
You might also find these calculators useful
Map RSA, ECC and AES to their NIST post-quantum replacement
Guess resistance, crack time and NIST 800-63B rev 4 checks
Generate and verify SHA-256, MD5, SHA-1, SHA-512 and SHA-3 digests
Crack times by hash algorithm, work factor and GPU count
Three thousand and seventy-two. An elliptic curve needs 256 bits for the same job, and a symmetric cipher needs 128. Key sizes are not comparable across algorithm families, because the fastest attack on each family is a different algorithm with a different cost curve, so a bigger number does not mean a stronger key. This tool converts between them using the table NIST publishes for exactly this purpose, and computes the sizes the table leaves out.
Security strength is the number of operations the best known attack needs, expressed as a power of two: 128-bit strength means roughly 2^128 operations. Key length is just how many bits the key occupies. NIST states the difference plainly in the notes to Table 2: "the security strength is not necessarily the same as the length of the key due to attacks on those algorithms that provide computational advantages." Triple-DES is the clearest case. 3TDEA carries three 56-bit keys, so 168 bits of key material, and provides 112 bits of strength, because a meet-in-the-middle attack collapses the rest. RSA is the extreme case: a 2048-bit modulus provides 112 bits, because the general number field sieve factors it far faster than trying every key. Elliptic curves lose exactly half, to Pollard's rho. Only symmetric ciphers give you what the key length says.
CMVP equivalent-strength formula for an RSA modulus of k bits
An ECDSA P-256 certificate and an RSA-3072 certificate provide the same 128 bits. One handshake is far cheaper than the other, which is why the ecosystem moved to curves.
Confirm the transport key is at least as strong as the key it carries. CMVP requires exactly this, and annotates the module certificate when it does not hold.
Turn a key size into the effective strength figure that PCI DSS, FIPS and internal policies are written in, with the source table beside it.
Find every 112-bit component: RSA-2048, DH-2048, P-224, SHA-224. These are the ones Table 4 stops allowing first.
It provides about 150 bits against RSA-3072's 128, for roughly seven times the signing cost. The tool computes the exact figure so the trade is visible.
See at a glance which parts of a system Shor ends and which parts survive, before scoping a post-quantum migration.
RSA-2048 has eight times the bits of AES-256 and provides less than half the strength. Comparing the digits instead of the strengths is how systems end up with a strong cipher behind a weak key exchange.
SP 800-57 is explicit: wrap an AES-256 key with a 2048-bit RSA key and the whole exchange provides 112 bits, not 256. The largest number in your configuration tells you nothing; the smallest strength does.
Table 4 marks 112-bit strength acceptable through 2030 and disallowed from 2031. RSA-2048 and P-224 sit exactly on that line, so anything that must stay confidential past then needs planning now, not later.
PCI DSS defines strong cryptography as a minimum of 112 bits of effective key strength and warns in the same sentence that this can be shorter than the key's bit length. You cannot check that requirement by reading a key size.
Shor's algorithm ends RSA, DH and ECC outright, whatever the key size. Grover only reduces symmetric search, and by less than the arithmetic suggests. The two halves of your stack are on completely different timelines.
NIST publishes five rows. Real systems run RSA-4096, RSA-1536, P-521. The CMVP formula covers all of them, and it is the same formula NIST points to from the table itself.
No, and the comparison only makes sense at equal strength. RSA-2048 provides 112 bits, less than AES-128's 128 bits, despite having sixteen times the key material. To match AES-256 an RSA key needs a 15,360-bit modulus. They also do different jobs: AES encrypts bulk data, RSA establishes keys and signs. Almost every real system uses both.
They are not substitutes, but on strength alone AES-256 provides 256 bits against RSA-2048's 112 — a gap of 2^144 in attack cost. In practice a system using both is only as strong as the weaker one, so pairing AES-256 with RSA-2048 gives you a 112-bit system. NIST says this directly in SP 800-57 section 5.6.2.
For new federal work at the 112-bit level, yes: NIST SP 800-57 Table 4 disallows 112-bit strength, which includes RSA-2048, from 2031. Larger RSA keys remain acceptable classically. Separately, all of RSA, DH and ECC are broken outright by Shor's algorithm on a sufficiently large quantum computer, which is why NIST has standardised post-quantum replacements. Increasing the RSA key size does not help against that.
Both, in different roles. The handshake uses a public-key algorithm — today usually ECDHE with an ECDSA or RSA certificate — to agree a shared secret. Everything after that is encrypted with a symmetric cipher, normally AES-GCM or ChaCha20-Poly1305. The session's real strength is the lower of the two, which is why a 128-bit curve is paired with a 128-bit cipher.
About 150. It is not in NIST's table, which jumps from 3072 bits at 128-bit strength to 7680 bits at 192-bit strength, so it has to be computed with the CMVP formula. The gain over RSA-3072 is roughly 22 bits for several times the computational cost, which is why most standards stop at 3072 and move to elliptic curves instead.
It depends on which property you need. Against collisions — what a digital signature relies on — the birthday bound halves it to 128 bits. Against preimages, which is what HMAC and key derivation need, it provides the full 256. SP 800-57 Table 3 keeps these in two separate columns for exactly this reason, and quoting one number for "SHA-256 security" always hides one of them.