RSA vs Elliptic-Curve vs Post-Quantum Cryptography: Key Sizes, Speed, Quantum Resistance and Migration Compared
All three are public-key cryptography, used to share keys (key exchange or key encapsulation) and for digital signatures. RSA rests on the difficulty of factoring large numbers, and elliptic-curve cryptography on the difficulty of the discrete logarithm problem on elliptic curves; for the same security, elliptic-curve cryptography needs much shorter keys than RSA. Both, however, would be broken by Shor's algorithm once a large fault-tolerant quantum computer exists. Post-quantum cryptography rests on problems such as lattice problems that are believed to be hard even for quantum computers; in August 2024 the US NIST published standards including the key encapsulation mechanism ML-KEM (FIPS 203) and the signature scheme ML-DSA (FIPS 204). Their main drawback is large keys and signatures.
| Aspect | RSA | Elliptic-curve cryptography | Post-quantum cryptography (ML-KEM, ML-DSA) |
|---|---|---|---|
| Underlying hard problem | Factoring large numbers | The discrete logarithm problem on elliptic curves | For ML-KEM and ML-DSA, lattice problems (such as Module-LWE, recovering a secret from linear equations with small errors added); there is also SLH-DSA (FIPS 205), a signature scheme based only on hash functions |
| Key size (guideline) | In the NIST SP 800-57 table, the guideline for 128-bit security is a 3072-bit n (384 bytes); 2048 bits corresponds to 112-bit security | In the same table, the guideline for 128-bit security is 256 bits; in X25519 key exchange the public value sent is 32 bytes | An ML-KEM-768 public key (encapsulation key) is 1,184 bytes, far larger than the 32 bytes of X25519 |
| Ciphertext and signature size | Both ciphertexts and signatures are as long as n (384 bytes for 3072 bits) | An ECDSA (P-256) signature is two 256-bit values, r and s, for 64 bytes (slightly more depending on the encoding) | An ML-KEM-768 ciphertext is 1,088 bytes and an ML-DSA-65 signature is 3,309 bytes |
| Speed | Because the public exponent can be small (such as 65537), encryption and signature verification are fast; decryption, signing and key generation are heavy | Key generation and signing are much faster than RSA at the same security; signature verification is often slower than RSA | ML-KEM computation is light and is considered no slower than elliptic-curve key exchange; the size of the data sent tends to be the bigger issue than computation |
| Quantum resistance | None: Shor's algorithm breaks it on a large fault-tolerant quantum computer | None: Shor's algorithm also solves the discrete logarithm problem, so it is broken like RSA | Believed to be hard to solve efficiently even with quantum computers (this has not been proven) |
| Standardization | Invented in 1977; in practice used with randomized padding such as OAEP for encryption and PSS for signatures | Curves such as P-256, and X25519 and Ed25519 based on Curve25519, are widely used | Published by NIST in August 2024 as FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) |
| Typical uses today | As of the mid-2020s, mainly certificates and software signing; TLS 1.3 removed key exchange that sends key material encrypted with RSA | As of the mid-2020s, the mainstay of TLS key exchange (ECDHE); also ECDSA and EdDSA signatures, and resource-constrained devices such as smart cards and embedded systems | As of 2025, hybrid key exchange combined with X25519 (such as X25519MLKEM768) has started to be used in TLS 1.3; migration of signatures is following after key exchange |
| Migration | A target of the migration to post-quantum cryptography; replacing signatures, such as in certificates and code signing, is the challenge | A target of the migration; during the transition it serves as one half of hybrid key exchange with ML-KEM, providing security against classical computers | For now, migration proceeds step by step with hybrid schemes that combine it with conventional cryptography; designs that make algorithms easy to swap later (crypto agility) are emphasized |
| Implementation cautions | Never use textbook RSA without padding; key generation needs good-quality randomness | Reusing or biasing the per-signature random value (nonce) lets attackers recover the private key; received points must also be checked to lie on the correct curve | Large keys and signatures require checking the impact on packet sizes and memory-constrained devices; watch for bugs in new implementations and for side-channel attacks |
Figures are typical orders of magnitude and vary by process generation and product.