Public-key cryptography rests on a simple asymmetry: an operation that is easy to perform but hard to reverse. RSA uses integer factorization — multiplying two large primes is trivial, but recovering them from the product is not. Elliptic curve cryptography (ECC) uses a different hard problem, one that turns out to be far more efficient per bit of security.
The result is the same family of capabilities you get from RSA — key exchange, digital signatures, encryption — but with dramatically smaller keys, faster operations, and lower power draw. For the battery-powered device in your pocket, that last point is not a footnote. It is why your phone can negotiate dozens of encrypted connections per second without noticeably draining.
What an Elliptic Curve Actually Is
Despite the name, an elliptic curve is not an ellipse. In cryptography it is the set of points satisfying an equation of the form y² = x³ + ax + b, plotted over a finite field — meaning the coordinates wrap around a large prime modulus rather than ranging over all real numbers. The curve looks less like a smooth arc and more like a scatter of points, but it has a remarkable property: you can define addition on it.
Given two points on the curve, there is a well-defined rule for "adding" them to produce a third point also on the curve. Geometrically, over the real numbers, you draw a line through the two points, find where it intersects the curve again, and reflect that intersection across the x-axis. The reflected point is the sum. This operation is associative and commutative, which is exactly what you need to build a mathematical group.
The Hard Problem: Discrete Logarithms
If you start at a point G and add it to itself repeatedly — G, 2G, 3G, and so on up to kG — computing kG from k is fast, using a technique called double-and-add that takes roughly the number of bits in k. But going backward — recovering k when you only know G and the resulting point kG — is believed to be computationally infeasible for well-chosen curves.
This is the elliptic curve discrete logarithm problem (ECDLP). The private key is the scalar k; the public key is the point kG. Anyone can verify operations using the public point, but nobody can run the multiplication backward to extract your secret scalar.
The best known attacks on ECDLP are generic "square-root" algorithms (Pollard's rho), which take work proportional to the square root of the key space. RSA, by contrast, faces the number field sieve — a sub-exponential algorithm that is far more efficient than brute force. Because ECC has no comparably efficient shortcut, a 256-bit curve resists attack as well as a ~3072-bit RSA modulus.
Key Sizes Compared
The security-level equivalences below come from NIST guidance (SP 800-57). "Security level" is expressed in bits — a 128-bit level means an attacker needs roughly 2¹²⁸ operations to break it.
| Security level | RSA / DH key | ECC key |
|---|---|---|
| 112-bit | 2048-bit | 224-bit |
| 128-bit | 3072-bit | 256-bit |
| 192-bit | 7680-bit | 384-bit |
| 256-bit | 15360-bit | 512-bit |
The gap widens as you climb. At the highest security levels, RSA keys become so large that the computational cost of using them is impractical for high-throughput servers, while the equivalent ECC key stays comfortably small. This is the core reason the industry shifted.
Curve25519 and the Trust Problem
Not all curves are created equal. The specific values of a, b, the prime modulus, and the base point G are called the curve's domain parameters, and a poorly chosen curve can hide weaknesses. For years the dominant curves were the NIST P-series (P-256, P-384), but their parameters were generated from unexplained constants, which raised the uncomfortable question of whether they could have been deliberately weakened.
In 2005, Daniel J. Bernstein introduced Curve25519, designed with parameters chosen for transparent, defensible reasons and engineered to resist entire classes of implementation mistakes — invalid-curve attacks, timing side channels, and the like. Its signature counterpart, Ed25519, followed. These are now the default in OpenSSH, Signal, WireGuard, TLS 1.3, and most modern systems.
"The cryptographer's job is not just to choose a hard problem, but to choose one whose hardness can be argued for in the open. Curves you cannot explain are curves you should not trust." — a paraphrase of the rigid-curve design philosophy behind Curve25519
Where ECC Shows Up in Your Day
You use elliptic curve cryptography constantly without seeing it. When your browser opens an HTTPS connection, the TLS 1.3 handshake almost certainly uses ECDHE — Elliptic Curve Diffie-Hellman Ephemeral — to establish a shared session key. That ephemeral exchange is also what provides forward secrecy, so a stolen long-term key can't decrypt yesterday's traffic.
The same math underlies the Diffie-Hellman key exchange in its elliptic-curve form, the signatures that authenticate software updates and SSH logins, and the ratcheting key agreement inside modern messengers. ECC is not a niche; it is the substrate.
The Quantum Caveat
ECC's elegance comes with one large asterisk. Shor's algorithm, running on a sufficiently powerful quantum computer, would break the elliptic curve discrete logarithm problem just as it breaks RSA factorization. No such machine exists today, and estimates of when one might vary widely — but data captured now could be decrypted later.
This is why the field is migrating toward post-quantum cryptography and hybrid schemes that combine a classical elliptic curve exchange with a quantum-resistant one. The pragmatic stance for the next several years is a hybrid: keep the proven efficiency of ECC, and wrap it in a post-quantum layer so that breaking the message requires defeating both.
The Bottom Line
Elliptic curve cryptography won the efficiency argument decisively. It delivers the security guarantees of RSA at a fraction of the key size and computational cost, which is exactly what an internet of mobile, battery-constrained devices needs. The remaining questions are about curve provenance — answered, for most purposes, by Curve25519 and its relatives — and about the eventual quantum threat, which the hybrid approach is built to absorb.
At Haven, elliptic curve primitives sit underneath the encrypted transport our app relies on, alongside the MLS protocol that handles group messaging. We treat ECC as one well-understood building block among several — useful precisely because its strengths and limits are both clearly mapped.