An interactive intro to Elliptic Curve Cryptography (ECC)

Suppose two people want to communicate privately over the internet. They could encrypt their messages, scrambling them so that only someone with the right secret key can read them. But that raises an immediate problem: how do they agree on that secret key in the first place? They can't whisper it to each other. Every message between them passes through the open internet, where anyone could be listening.

One solution is public-key cryptography: each person has two linked keys, a private key they keep secret and a public key they share openly. The keys are mathematically related, but computing the private key from the public key is so hard it's effectively impossible. That one-way relationship is what lets you encrypt messages, agree on shared secrets, and sign data to prove authorship.

The first widely used public-key systems were built on the difficulty of specific math problems. RSA relies on the fact that multiplying two large prime numbers is easy, but factoring the result back into those primes is extremely hard. Diffie-Hellman relies on a similar idea using exponents in modular arithmetic (clock arithmetic where numbers wrap around at a fixed value).

Both systems work, and both are still in use. But they share a practical problem: the keys are enormous. A commonly recommended minimum for RSA today is 2048 bits (about 617 decimal digits), but for 128-bit security equivalence RSA needs 3072 bits. As we push for stronger security, the numbers grow fast: RSA key sizes grow much faster than security targets, because the underlying factoring attacks are sub-exponential.

What if a different mathematical structure could give us the same guarantees (easy in one direction, effectively impossible in reverse) but with much smaller numbers? That structure exists, and it comes from the geometry of curves.

Drawing the curve

A mathematical equation can define a shape. Take the equation $y = x^2$y=x2, which says "y equals x squared." To draw it, you pick values of $x$x, compute $y$y, and plot each resulting point on a grid. Step through the process below:

Each step picks an $x$x value, squares it to get $y$y, and places a dot at that coordinate. As the points accumulate, a curve appears: the parabola. The equation defined the shape all along; we just needed enough points to see it.

Different equations produce different shapes. The equation $x^2 + y^2 = 1$x2+y2=1 gives a circle (every point at distance 1 from the center). Toggle between these below:

An elliptic curve is another equation of this kind:

$$y^2 = x^3 + ax + b$$y2=x3+ax+b

Select $y^2 = x^3 - x + 1$y2=x3−x+1 in the demo above to see one. The $x^3$x3 term makes the right side grow much faster than the left, giving the curve its distinctive looping shape, different from the smooth symmetry of a circle or the open bowl of a parabola.

Despite the name, elliptic curves have nothing to do with ellipses. The name comes from elliptic integrals, which arose historically when computing the arc length of an ellipse. The connection is purely mathematical and not worth worrying about.

The constants $a$a and $b$b determine the curve's shape. Adjust the sliders below and watch the curve change. Click anywhere on the curve to place a point:

Click a few different spots. Every point you place has a mirror: if $(x, y)$(x,y) is on the curve, then $(x, -y)$(x,−y) is too, because squaring a negative number gives the same result as squaring its positive counterpart ($(-y)^2 = y^2$(−y)2=y2). The curve is always symmetric across the x-axis. This symmetry will matter when we define addition.

One constraint on the parameters: certain combinations of $a$a and $b$b produce a curve with a cusp or a self-intersection (a sharp point where the curve crosses itself). These are called singular curves, and they break the algebraic structure we need. Toggle between the three cases below to see what goes wrong:

At a cusp, the curve comes to a sharp point where the tangent line is undefined. At a self-intersection, two branches of the curve cross, giving two tangent lines at one point. Both situations break the point addition we're about to define, which depends on there being exactly one tangent line at every point. The mathematical condition for avoiding singularities is that the discriminant $4a^3 + 27b^2 \neq 0$4a3+27b2=0. Cryptographic curves always satisfy this.

We have a curve. Now what? The idea that turned this into cryptography was to define an arithmetic on the points of the curve: a way to "add" two points together and get a third point, also on the curve.

Adding points on a curve

The geometric construction goes like this. Take two points $P$P and $Q$Q on the curve. Draw a straight line through them. Because the equation is cubic (the $x^3$x3 term), this line will generally intersect the curve at exactly one more point, call it $R'$R′ (special cases like vertical lines or tangencies are handled by the point at infinity and the doubling rule). Now reflect $R'$R′ over the x-axis, which means flipping its y-coordinate from positive to negative or vice versa. The reflected point $R$R is the result. We define $P + Q = R$P+Q=R.

Move the sliders below to slide $P$P and $Q$Q along the curve and watch the addition happen:

The dashed line goes through $P$P and $Q$Q. It hits the curve at $R'$R′ (the unfilled circle). Reflecting $R'$R′ over the x-axis gives us $P + Q$P+Q (the red point).

This "addition" isn't ordinary addition. We're not adding the coordinates together. We're using a geometric recipe (draw a line, find the intersection, reflect) to produce a new point from two existing ones. But mathematicians call it addition because it behaves like addition in the ways that matter.

It's associative, meaning that $P + (Q + R) = (P + Q) + R$P+(Q+R)=(P+Q)+R. There's an identity element called the "point at infinity" $O$O, which acts like zero: $P + O = P$P+O=P for any point $P$P. And every point has an inverse: the point directly below (or above) it, the reflection, since $P + (-P)$P+(−P) gives the point at infinity. These properties make the curve's points a mathematical group. That's the algebraic structure the rest of this article depends on.

Climbing the curve

With point doubling, we can compute $2P = P + P$2P=P+P. Then $3P = 2P + P$3P=2P+P. Then $4P$4P, $5P$5P, and so on. Computing $nP$nP for some integer $n$n is called scalar multiplication: we're multiplying a point by a number to get another point.

The naive approach takes $n - 1$n−1 additions: add $P$P to itself $n$n times. But there's a much faster method. To compute $100P$100P, observe that $100 = 64 + 32 + 4$100=64+32+4 in binary. So compute $2P$2P, $4P$4P, $8P$8P, $16P$16P, $32P$32P, $64P$64P by repeated doubling (six doublings), then add $64P + 32P + 4P$64P+32P+4P (two additions). That's eight operations instead of 99. In general, computing $nP$nP takes roughly $\log_2(n)$log2​(n) operations using this double-and-add algorithm. Even for a 256-bit number (roughly $10^{77}$1077), that's only about 256 doublings and additions, which a computer does in a fraction of a second.

Step through the computation of $nG$nG on a small curve:

Watch the points hop around in what looks like a random pattern. Even on this small curve, there's no visible relationship between $n$n and the position of $nG$nG. The points don't march along the curve in any recognizable order. They scatter unpredictably.

Elliptic curve cryptography depends on that apparent randomness.

The trapdoor

Going forward is easy: given $P$P and $n$n, computing $Q = nP$Q=nP takes roughly $\log_2(n)$log2​(n) steps using double-and-add. Going backward is hard: given $P$P and $Q$Q, finding $n$n such that $Q = nP$Q=nP has no known shortcut on a well-chosen curve.

This is a one-way function (sometimes called a trapdoor): easy to compute forward, practically impossible to reverse. Every public-key system has one. For RSA, multiplying two large primes is easy but factoring their product is hard. For elliptic curves, scalar multiplication is easy but recovering the scalar is hard.

The problem of recovering $n$n is called the Elliptic Curve Discrete Logarithm Problem (ECDLP). The name "discrete logarithm" comes from an analogy with regular logarithms: in regular math, if $b^n = x$bn=x, then $n = \log_b(x)$n=logb​(x). Here, if $nP = Q$nP=Q, we're looking for a kind of "logarithm" in the world of elliptic curve points. "Discrete" means we're working with integers, not continuous numbers.

On a well-chosen curve, the best generic attacks (like Pollard's rho) require roughly $O(\sqrt{n})$O(n​) operations, no fundamentally better shortcut is known.

Step through a brute-force search to see what "going backward" looks like:

On the small curve in this demo, the search finishes quickly because $n$n is small. In real cryptography, $n$n is roughly $2^{256}$2256 (a number with 77 digits). Even the best known algorithms would need about $2^{128}$2128 operations. If every computer on Earth worked on the problem, it would take longer than the age of the universe.

From smooth curves to scattered dots

Everything so far used real-number coordinates: smooth curves, infinite precision, irrational slopes. Real cryptography can't work this way. Computers represent real numbers with floating-point arithmetic, which introduces tiny rounding errors. In cryptography, a single wrong bit means the wrong answer. We need exact arithmetic.

The fix is to work over a finite field. Instead of using all real numbers, we use only the integers from $0$0 to $p - 1$p−1, where $p$p is a prime number. All arithmetic wraps around at $p$p, the same way a clock wraps around at 12.

This is called modular arithmetic (written $\bmod p$modp). For example, if $p = 7$p=7, then $5 + 4 = 9 \equiv 2 \pmod{7}$5+4=9≡2(mod7) because 9 divided by 7 has remainder 2.

The curve equation becomes:

$$y^2 \equiv x^3 + ax + b \pmod{p}$$y2≡x3+ax+b(modp)

Now $x$x and $y$y are integers from $0$0 to $p - 1$p−1. Division is replaced by modular inverse, a number that, when multiplied, gives 1 modulo $p$p. (For example, the inverse of 3 modulo 7 is 5, because $3 \times 5 = 15 \equiv 1 \pmod{7}$3×5=15≡1(mod7).) The point addition formulas stay exactly the same, just computed mod $p$p.

The visual result is completely different. The smooth curve becomes a scattered cloud of dots:

Click any point to see its inverse (the point with the same x-coordinate but negated y-coordinate, mod $p$p). Despite looking random, these points satisfy the same equation and obey the same addition rules. The algebraic structure is fully preserved even though the geometry is gone. It's this version of the curve (over a finite field with a very large prime) that real cryptographic systems use.

The number of points on the curve is close to $p$p (more precisely $p + 1 - t$p+1−t, where $|t| \le 2\sqrt{p}$∣t∣≤2p​ by Hasse's theorem, so the count is close to $p$p in relative terms). Cryptographic systems typically use a large prime-order subgroup of size $n$n close to $p$p. For curves using 256-bit primes, this gives roughly $2^{256}$2256 points to work in.

The trapdoor still applies. Scalar multiplication over a finite field is just as fast ($\log_2(n)$log2​(n) steps via double-and-add), and the ECDLP is at least as hard as it was over the reals — harder, in fact, because the scattered-dot structure eliminates geometric intuition an attacker might exploit. All the constructions that follow (key exchange, signatures, encryption) work over this finite field.

Exchanging secrets on a curve

With a set of points, an addition operation, and a one-way function (scalar multiplication that's easy to compute but hard to reverse), we can build a protocol for two people to agree on a shared secret over an open channel, without ever sending the secret itself.

This protocol is called ECDH (Elliptic Curve Diffie-Hellman). Alice and Bob agree publicly on a curve and a starting point $G$G called the generator. If you compute $G, 2G, 3G, \ldots$G,2G,3G,…, the points eventually cycle back to the start.

The number of steps before the points cycle is called the order of $G$G, written $n$n. For cryptographic curves, $n$n is roughly $2^{256}$2256, so the generator produces an enormous set of distinct points before repeating. Private keys are random scalars in the range $[1, n-1]$[1,n−1]. (Some curves like X25519 accept 32 random bytes and deterministically "clamp" the bits into a safe scalar, simplifying key validation.)

1. Alice picks a random secret integer $a$a as her private key. She computes $aG$aG (her public key) and sends it to Bob.
2. Bob picks a random secret integer $b$b as his private key. He computes $bG$bG (his public key) and sends it to Alice.
3. Alice takes Bob's public key $bG$bG and multiplies it by her private key: $a(bG) = abG$a(bG)=abG.
4. Bob takes Alice's public key $aG$aG and multiplies it by his private key: $b(aG) = baG$b(aG)=baG.

Since scalar multiplication is associative, $abG = baG$abG=baG. Both arrive at the same point, the shared secret. An eavesdropper sees $G$G, $aG$aG, and $bG$bG (all sent over the public channel), but computing $abG$abG from those values requires solving the ECDLP: finding $a$a from $G$G and $aG$aG, or $b$b from $G$G and $bG$bG.

Adjust the private keys below and watch the shared secret update:

Both sides always arrive at the same point. In practice, the shared secret (usually just the x-coordinate of this point) is fed through a key derivation function to produce a symmetric encryption key, which is then used to encrypt the actual conversation.

Signing with curves

Key exchange lets two people establish a shared secret. But cryptography also needs digital signatures: a way to prove that a message came from a specific person and hasn't been tampered with. This is what you use when you sign a software update, authenticate a TLS certificate, or authorize a cryptocurrency transaction.

ECDSA (Elliptic Curve Digital Signature Algorithm) works like this. The signer has a private key $d$d (a secret integer) and a public key $Q = dG$Q=dG (a point on the curve, published for anyone to see).

The math works out so that only someone who knows $d$d can produce a valid $(r, s)$(r,s) for a given message, but anyone who knows the public key $Q$Q can verify it. Adjust the parameters below to see signing and verification with small numbers:

Two security requirements: the nonce $k$k must never be reused across different messages, and $k$k and its inverse must be protected like the private key itself. If an attacker sees two signatures that used the same $k$k with different messages, the two equations leak enough information to compute the private key $d$d directly. In 2010, Sony's PlayStation 3 code signing key was extracted because they used the same nonce for every signature.

Encrypting with curves

ECDH gives us key agreement and ECDSA gives us signatures. But what about encryption? If Alice wants to send an encrypted message to Bob using his public key, she needs ECIES (Elliptic Curve Integrated Encryption Scheme).

Try the demo below (using simplified XOR encryption instead of AES to keep the demonstration clear):

ECIES lets you encrypt a message directly to someone's public key without a prior key exchange. Full ECIES specifications also include a key derivation function (KDF) and a MAC or AEAD scheme for integrity. Ethereum's devp2p/RLPx protocol uses ECIES during the handshake to establish shared session keys; the ongoing transport then uses symmetric encryption. Signal Protocol uses a variant called the X3DH key agreement protocol that builds on similar elliptic curve principles.

Why curves win

The practical advantage of elliptic curve cryptography comes down to key size. For the same level of security, ECC keys are much smaller than RSA or Diffie-Hellman keys:

"Security level" means the number of operations an attacker would need to break the system. At 128-bit security (the standard for most applications today, meaning an attacker would need $2^{128}$2128 operations), an ECC key is 256 bits while an RSA key is 3,072 bits. That's a 12x difference. At higher security levels the gap grows: 256-bit security needs 512+-bit ECC keys (e.g., P-521) versus 15,360-bit RSA keys.

Smaller keys are faster to compute and cheaper to transmit, which matters especially on constrained devices like smart cards. This is why TLS 1.3, Signal, SSH, and Bitcoin all use ECC.

Elliptic curves give us key exchange and digital signatures with keys that fit comfortably in a text message. There is a caveat, though. All public-key cryptography, including ECC, is theoretically vulnerable to quantum computing: an algorithm called Shor's algorithm can solve the ECDLP efficiently on a sufficiently powerful quantum computer. No such computer exists yet, but the threat has motivated work on post-quantum cryptography, which uses different mathematical structures (lattices, error-correcting codes, hash trees) that quantum computers can't efficiently break.