Elliptic Curves

Elliptic-curve cryptography gives you the same security as RSA with a fraction of the key size, which is why nearly every modern protocol (TLS 1.3, SSH, Signal, WireGuard) has moved to it. Smaller keys mean less bandwidth on every handshake, faster signing, and less to store and protect.

The discrete-log problem at intuition level

An elliptic curve defines a set of points plus an operation called point addition: given two points you can compute a third. Repeatedly adding a base point G to itself k times is called scalar multiplication, written k * G.

The asymmetry that makes it useful:

• Forward is easy: given k and G, computing P = k * G is fast (even for huge k, via doubling).
• Backward is hard: given P and G, recovering the scalar k is the elliptic-curve discrete-logarithm problem, and no efficient method is known.

So k is your private key (a big random number) and P = k * G is your public key (a point on the curve). This is the same forward-easy, backward-hard shape as RSA’s factoring, just a different problem.

Curve25519/Ed25519 vs NIST curves

Not all curves are equal. Two lineages matter in practice.

Family	Key-exchange curve	Signature scheme	Notes
Bernstein curves	X25519	Ed25519	Designed to be misuse-resistant; no fragile choices exposed
NIST curves	P-256 (ECDH)	ECDSA P-256	Widely mandated (FIPS, many CAs); requires careful nonce handling

The Bernstein curves (Curve25519 for exchange, its Edwards form Ed25519 for signatures) were designed so the dangerous choices are made for you: constant-time by construction, deterministic nonces, no invalid-curve traps. NIST curves are perfectly secure when implemented correctly, but ECDSA in particular is unforgiving about nonce handling, as the sibling Digital Signatures page shows with the PlayStation 3 story.

Why 256-bit ECC is roughly 3072-bit RSA

Both problems can be attacked, but the best known attacks scale very differently. Factoring an RSA modulus benefits from sub-exponential algorithms (the number field sieve), so you must grow RSA keys aggressively to keep pace. Breaking EC discrete log has no such shortcut, so a much shorter key holds the same margin.

Security level	Symmetric equiv	RSA key	EC key
~128-bit	AES-128	3072 bits	256 bits
~192-bit	AES-192	7680 bits	384 bits
~256-bit	AES-256	15360 bits	521 bits

The practical upshot: a 256-bit EC key does the work of a 3072-bit RSA key at a tiny fraction of the size. See the sibling Overview for the broader comparison.

Hands-on: generate EC and Ed25519 keys

cd ~/crypto-lab
# Ed25519: the modern signing default
openssl genpkey -algorithm ed25519 -out ed25519.pem
openssl pkey -in ed25519.pem -pubout -out ed25519.pub.pem

# X25519: the modern key-exchange default
openssl genpkey -algorithm x25519 -out x25519.pem

# NIST P-256 when a standard requires it
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out p256.pem
openssl pkey -in p256.pem -text -noout | head -n 6

Expected output:

Private-Key: (256 bit)
priv:
    3b:9a:...:41
pub:
    04:8c:...:e7
ASN1 OID: prime256v1
NIST CURVE: P-256

Notice the P-256 private key is 256 bits, yet it matches the strength of a 3072-bit RSA key from the sibling RSA page.

Practical Guidance

1. For new work, default to Ed25519 for signatures and X25519 for key exchange. They remove the sharp edges.
2. Use ECDSA P-256 (or P-384) only when a standard, CA, or FIPS requirement forces NIST curves.
3. Do not invent or hand-pick curve parameters. Use named, vetted curves only.
4. Remember that 256-bit ECC already gives ~128-bit security; you rarely need larger unless a policy demands it.
5. With ECDSA specifically, never let the per-signature nonce repeat or be predictable (see Digital Signatures).
6. Protect EC private keys exactly as carefully as RSA keys; smaller does not mean less sensitive (see the Key Management group).