Elliptic Curves

Elliptic-curve cryptography (ECC) gives you the same security as RSA at roughly one-eighth the key size. A 256-bit ECC key is comparable to a 3072-bit RSA key. That smaller size translates directly into smaller TLS handshakes, smaller signatures, and faster operations everywhere — which is why almost every modern protocol has migrated to elliptic curves.

What is an elliptic curve, really?

For our purposes: a special kind of equation, plotted over a finite field, whose points form a mathematical group with a tightly defined "addition" operation.

The curves used in cryptography all have the form:

y² = x³ + ax + b   (mod p)

a, b, and p are constants chosen to make the curve secure (no singular points, big enough field, well-studied).

You don't need to do the calculation by hand to use ECC. You need three intuitions:

1. The curve has a fixed base point G (a "generator"). Everyone agrees on it.
2. Multiplying G by a scalar k is easy: Q = k · G. This is repeated addition (in the group sense), done in O(log k) time using double-and-add.
3. Going backwards is hard: given G and Q = k · G, finding k is the Elliptic Curve Discrete Logarithm Problem (ECDLP). There is no known algorithm faster than O(√n) where n is the group order. For 256-bit curves, that's 2¹²⁸ operations — astronomically infeasible.

That's the trapdoor. k is your private key. Q = k · G is your public key. Multiplying is easy; reversing is impossible.

Why ECC keys are so much smaller

For RSA, breaking the system means factoring an integer. The General Number Field Sieve runs in sub-exponential time exp(O((log n)^(1/3) · (log log n)^(2/3))). To get 128-bit security, you need n to be ~3072 bits.

For ECC, breaking the system means solving ECDLP. The best known algorithm is Pollard's rho, running in O(√n). To get 128-bit security, you need a curve with order ~256 bits.

Security level	RSA bits	ECC bits	ECC scheme
80-bit (legacy)	1024	160	secp160
112-bit	2048	224	P-224
128-bit	3072	256	P-256, secp256k1, Ed25519
192-bit	7680	384	P-384
256-bit	15360	512	P-521, Ed448

This is why a TLS handshake using ECDHE + ECDSA is a few hundred bytes smaller than the RSA equivalent — and why Bitcoin can fit a public key into 33 bytes (compressed form).

The named curves you'll meet

Most of crypto practice is recognising these by name and knowing what they're for:

secp256k1

Defined by SECG in 2000. Bitcoin picked it for transaction signatures, and Ethereum followed. The 'k' is for Koblitz — the curve has a special structure that makes scalar multiplication slightly faster.

The choice of secp256k1 over P-256 was unusual and has been explained as Satoshi wanting to avoid NIST-blessed curves (which carried suspicion of NSA backdoors after Dual_EC_DRBG). secp256k1 has no such taint — it was chosen with verifiably random parameters.

P-256 / secp256r1 / prime256v1

The same 256-bit curve, three names. Defined by NIST. The 'r' is for random — its parameters were picked pseudo-randomly, supposedly without backdoors. This is the curve baked into:

• TLS 1.2 / TLS 1.3 (default ECDSA cert curve).
• Smart cards, FIDO2 / WebAuthn keys.
• Most government-compliance systems.

You'll see it called "P-256" in TLS specs, "secp256r1" in OpenSSL, "prime256v1" in older OpenSSL output, and "ES256" in JWT / JOSE specs. Same curve.

P-384, P-521

NIST's larger curves, used when you need 192- or 256-bit security. Top-secret material under NSA's CNSA Suite uses P-384 minimum. Most consumer crypto stays on P-256.

Ed25519

Designed by Daniel J. Bernstein and team in 2011. A different curve form (a twisted Edwards curve, hence "Ed") chosen specifically to:

• Avoid timing side-channels (constant-time operations).
• Make signatures deterministic (same key + same message → same signature). ECDSA fails badly on poor randomness; Ed25519 is immune.
• Avoid NIST entirely (no concern about hidden parameter choices).
• Be faster than the NIST curves on commodity hardware.

Used in: SSH, Signal Protocol, age, sigstore, Tor, most modern systems where the operator gets to pick.

Curve25519 / X25519

The same underlying curve as Ed25519, used for key exchange instead of signatures. Almost universal in modern key-exchange protocols (TLS 1.3, Signal, WireGuard).

How signatures work on a curve

ECDSA, simplified:

sign(m, d):                      verify(m, (r, s), Q):
  1. k ← random nonce               1. e ← hash(m)
  2. (x, y) = k·G                   2. w ← s⁻¹ mod n
  3. r = x mod n                    3. u₁ = e·w mod n,  u₂ = r·w mod n
  4. s = k⁻¹ · (hash(m) + d·r)      4. (x', y') = u₁·G + u₂·Q
     mod n                          5. accept if x' mod n == r

The critical line is step 1: pick a random nonce k. Reuse k across two signatures (or pick a predictable k) and an attacker can recover the private key from the two signatures. This is exactly what happened to Sony's PS3 (every game signed with the same fixed nonce).

Ed25519 dodges this entirely by deriving k deterministically from the private key and the message: k = SHA-512(seed, m). No randomness needed at signing time. Same key + same message → same signature, every time.

Compression

A curve point is (x, y). Both coordinates are 256-bit integers, so a point looks like 64 bytes. But the curve equation y² = x³ + ax + b means that for any x, there are only two possible values of y (the positive and negative square root mod p).

So instead of storing both coordinates, you can store x and one bit of y — 33 bytes total. The verifier recomputes y from the curve equation. Bitcoin uses this trick everywhere; it's why a Bitcoin public key is exactly 33 bytes.

Practical guidance

• Default to Ed25519 when both endpoints are modern. It's faster, smaller, and has no nonce-reuse class of bug.
• Use P-256 when you need to interoperate with TLS, JWT, FIDO2, or NIST-compliant systems.
• Use secp256k1 when you're working with Bitcoin / Ethereum / cosmos blockchains.
• Don't roll your own curve unless you really know what you're doing. The named curves were extensively reviewed; an exotic one isn't.

What this lesson asks of you

The playground asks you to recognise which curve fits which production context (Bitcoin, TLS, SSH, FIDO2). The visualizer compares key/signature sizes for the major curves alongside the equivalent RSA size, so the size advantage becomes visceral.