Understanding RSA & ECDSA
Big primes vs elliptic curves — same job, different maths.
Why RSA needs 3072 bits to match ECDSA's 256, where each still wins, and the key-size table worth memorising.
RSA — factoring is hard.
RSA's security rests on the difficulty of factoring a product of two large primes. The private key is the two primes; the public key is the product plus an exponent. Modern recommendation: 3072-bit modulus for ~128-bit security, 4096-bit for ~152. Anything shorter than 2048 has been deprecated since 2013. The keys are big because the best-known factoring algorithms (General Number Field Sieve) need exponentially more time as the modulus grows, but grow sub-exponentially — hence the 3072-bit anchor.
ECDSA — discrete logs on a curve.
ECDSA does the same job — signing and key agreement — using the elliptic-curve discrete-logarithm problem. The fastest known algorithm against ECDSA is generic (Pollard rho); there's no equivalent of GNFS. So 256-bit ECDSA keys give ~128-bit security and 384-bit keys give ~192. The size compression is dramatic: 12× smaller keys, 10-50× faster signing, 1-5× faster verification.
The size-security table.
80-bit security: RSA 1024, ECDSA 160. 112-bit: RSA 2048, ECDSA 224. 128-bit: RSA 3072, ECDSA 256. 192-bit: RSA 7680, ECDSA 384. 256-bit: RSA 15360, ECDSA 521. The right column is the modern default. Anything in the 80-bit column is deprecated; SHA-1, DES, RSA-1024 all fall there.
A worked comparison.
For a TLS server certificate at 128-bit security: RSA-3072 public key is 384 bytes; ECDSA P-256 public key is 64 bytes. RSA signature: 384 bytes; ECDSA signature: ~70 bytes (DER-encoded). RSA-3072 sign: ~10 ms on a server CPU; ECDSA P-256 sign: ~0.2 ms. Verification favours RSA (RSA verify is fast because the public exponent is small, usually 65537); ECDSA verify is ~2× slower. Mixed-traffic servers (lots of TLS handshakes signing, occasional verifies) benefit from ECDSA; CDN edges with mostly verifies are fine with either.
RSA-3072 vs ECDSA P-256
same security, different sizes
Compare bytes, ms, and certificate fit.
public 384B vs 64B ; sign 10ms vs 0.2ms ; verify 0.1ms vs 0.2ms
= ECDSA wins almost everywhere
Curve choices.
The NIST P-curves (P-256, P-384, P-521) are the standard ECDSA targets — well-supported, FIPS-blessed, audited. P-256 is the workhorse. The other family is the SafeCurves (Curve25519, Curve448) used in EdDSA — modern, simpler, but a slightly different algorithm. secp256k1 (Bitcoin's curve) is an older Koblitz curve; useful only when interoperating with cryptocurrencies. Default to P-256 for TLS interop, Ed25519 for everything else.
Post-quantum looms.
Both RSA and ECDSA fall to Shor's algorithm on a sufficiently large quantum computer. That computer doesn't exist yet, but NIST has standardised post-quantum replacements: ML-KEM (formerly Kyber) for key encapsulation, ML-DSA (Dilithium) for signatures. Their keys and signatures are 5-50× larger than current ECDSA — the size win flips back to a loss. The migration will take a decade; for now, current key sizes are still safe.