What Is an Elliptic Curve, Really?
An elliptic curve used in cryptography is not an ellipse. It is the set of points satisfying an equation of the form y squared equals x cubed plus a times x plus b, evaluated over a finite field rather than over ordinary real numbers. A finite field means arithmetic wraps around modulo some large prime, so the curve is really a finite grid of discrete points, not a smooth continuous shape, even though it helps to picture it as a smooth curve first. Every valid combination of x and y coordinates satisfying that equation, plus one special extra point called the point at infinity, forms the curve's point set. The point at infinity acts as the identity element, playing the same role that zero plays in ordinary addition. Cryptographic protocols pick a specific standardized curve, along with a specific base point on that curve called the generator, often written as G. Popular choices include curves named P-256, Curve25519, and secp256k1, each defined by particular constants a, b, and a particular prime field size. The security of everything built on the curve depends on the size of that underlying field and on the curve having no known structural weaknesses. What makes these curves useful for cryptography is that their points come equipped with a geometric addition rule that turns the point set into a mathematical group. That group structure is what allows scalar multiplication, the elliptic curve equivalent of exponentiation, to be defined and computed efficiently. Everything that follows, from generating key pairs to deriving a shared secret, rests on this single idea: points on a carefully chosen curve can be combined using a well-defined addition operation, and that operation behaves predictably enough to build a full cryptographic protocol on top of it, yet unpredictably enough that reversing repeated additions is computationally infeasible for an outside observer.
Point Addition: The Geometric Engine
Elliptic curve point addition has an elegant geometric description before it becomes pure algebra. To add two distinct points P and Q on the curve, imagine drawing a straight line through them. Because of the curve's cubic equation, that line intersects the curve at exactly one more point. Reflecting that third intersection point across the horizontal axis gives the result, called P plus Q. Doubling a single point P, meaning computing P plus P, works similarly but uses the tangent line at P instead of a line through two separate points, again finding where that tangent meets the curve a second time and reflecting the result. Over the real numbers this all has a literal picture with lines and curves; over a finite field the same algebraic formulas apply, just with coordinates computed using modular arithmetic instead of ordinary arithmetic, so the geometric picture becomes a mental model rather than something you would actually sketch. Crucially, this addition operation is closed, meaning adding two points on the curve always produces another point on the curve, and it obeys the same associative and commutative rules that ordinary addition follows. That is precisely what allows repeated addition of a point to itself, written as scalar multiplication, to behave consistently no matter how the additions are grouped or ordered. Special cases round out the definition: adding a point to the point at infinity returns that same point unchanged, and adding a point to its own reflection across the horizontal axis, called its inverse, yields the point at infinity. These rules together make the set of points on the curve, combined with this addition operation, into a mathematical group, the same kind of structure that integers modulo a prime form under multiplication in classical Diffie-Hellman, but built from geometry instead of exponent arithmetic.
Scalar Multiplication and Double-and-Add
Scalar multiplication takes a point P and a whole number k, and computes the point reached by adding P to itself k times, written as k times P. Doing this by adding P one copy at a time would be hopelessly slow for the huge values of k used in cryptography, values that can be hundreds of bits long. The practical solution is the double-and-add algorithm, a direct analogue of the square-and-multiply technique used for fast modular exponentiation in classical Diffie-Hellman. The algorithm looks at the binary representation of k and processes it bit by bit, repeatedly doubling a running point and conditionally adding the base point P whenever the current bit is one. Because doubling a point takes roughly the same effort as adding two different points, and because the number of bits in k grows only logarithmically with its size, double-and-add computes k times P using roughly as many operations as k has bits, rather than k separate additions. For a 256-bit scalar, that means around a few hundred point operations instead of an astronomically large number of individual additions, making scalar multiplication entirely practical even on modest hardware. This efficiency is what makes elliptic curve key generation and the key exchange itself fast enough for everyday use in browsers, mobile apps, and network protocols. The elegance of double-and-add is that it mirrors exactly how humans compute large exponents efficiently by repeated squaring, just translated into the language of point addition. Speed in the forward direction is essential, because both parties in ECDH need to perform scalar multiplication routinely, but as the next section explains, that same speed does not extend to anyone trying to work backward from the result to the original scalar.
The Elliptic Curve Discrete Logarithm Problem
The entire security of ECDH rests on one asymmetry: given a base point G and a scalar k, computing the resulting point Q equals k times G is fast, but given only G and Q, recovering the scalar k is believed to be computationally infeasible for well-chosen curves and large enough field sizes. This is called the elliptic curve discrete logarithm problem, often abbreviated ECDLP, and it plays the same structural role that the classical discrete logarithm problem plays in traditional Diffie-Hellman over a prime field. The key difference is how hard each problem is relative to the size of the numbers involved. The best known algorithms for solving the classical discrete logarithm problem in a prime field run in what is called sub-exponential time, meaning they are faster than brute force but still slow, which forces classical Diffie-Hellman to use very large primes, commonly around three thousand and seventy two bits, to stay secure. The best known general algorithms for solving the elliptic curve discrete logarithm problem, by contrast, run in fully exponential time relative to the field size, with no known shortcut analogous to the sub-exponential attacks that work against the classical problem. That stronger hardness guarantee means a much smaller elliptic curve field, commonly around two hundred fifty six bits, provides comparable resistance to attack. An eavesdropper who intercepts both public points exchanged during ECDH sees G and both parties' public points, essentially seeing Q one and Q two, but extracting either private scalar from that information would require solving ECDLP, a problem for which no efficient algorithm is known even with substantial computing resources. This gap between easy forward computation and hard reversal is exactly what turns simple point arithmetic into a trustworthy cryptographic primitive.
The Handshake and Why Smaller Keys Matter
Putting the pieces together, an ECDH handshake unfolds in a few clean steps. Both parties agree in advance on a shared curve and a shared base point G, which are public and standardized. Each party then privately chooses a random scalar, playing the role of a private key, call them scalar A for the first party and scalar B for the second. Each computes their own public point by multiplying the shared base point by their own scalar, giving public point A equals scalar A times G, and public point B equals scalar B times G. The two parties exchange these public points openly, even over a channel an attacker can observe. Finally, each party multiplies the other party's public point by their own private scalar. The first party computes scalar A times public point B, and the second party computes scalar B times public point A. Because scalar multiplication is associative and commutative in the underlying group, both computations equal scalar A times scalar B times G, meaning both parties land on the exact same shared secret point without ever transmitting their private scalars. That shared point, or a value derived from its coordinates through a key derivation function, becomes the symmetric key used for subsequent encrypted communication. The practical payoff of choosing curves over prime fields is size: a 256-bit elliptic curve key offers security roughly comparable to a 3072-bit finite-field Diffie-Hellman key, which translates into smaller messages, faster key generation, less memory and CPU usage, and lower power consumption. That efficiency advantage is exactly why ECDH, rather than classical Diffie-Hellman, underlies key exchange in modern TLS and HTTPS connections, the Signal Protocol used in secure messaging apps, and the WireGuard virtual private network protocol, all of which depend on fast, lightweight, and repeatable key agreement.
Frequently asked questions
How is ECDH different from classical Diffie-Hellman?
Classical Diffie-Hellman works with modular exponentiation of integers in a large prime field. ECDH replaces integer exponentiation with scalar multiplication of points on an elliptic curve, using point addition as its core operation instead of multiplication of numbers. Both rely on a similar structural idea, an operation that is easy to compute forward but hard to reverse, but the underlying mathematical objects and the hard problem's difficulty profile are quite different, which is why ECDH can use much smaller keys for equivalent security.
Why can elliptic curve keys be so much smaller than classical Diffie-Hellman keys?
The strongest known attacks against the classical discrete logarithm problem run in sub-exponential time, so classical Diffie-Hellman needs very large primes, around 3072 bits, to resist them. The strongest known general attacks against the elliptic curve discrete logarithm problem run in fully exponential time relative to field size, offering a steeper security-per-bit curve. That means a roughly 256-bit elliptic curve key can match the security level of a roughly 3072-bit classical key, an enormous reduction in key size.
What exactly is being kept secret in ECDH?
Each party's private scalar, essentially a large random number, is the secret that never leaves that party's device. The public points derived by multiplying the shared base point by each private scalar are sent openly. The final shared secret point, computed by each side multiplying the other's public point by their own private scalar, is never transmitted directly; it is independently reconstructed identically by both sides.
What is double-and-add, and why does it matter?
Double-and-add is the efficient algorithm used to compute scalar multiplication, turning a scalar's binary representation into a short sequence of point doublings and conditional point additions. Without it, computing k times G for a large k would require an impractical number of individual additions. Double-and-add reduces that to roughly as many operations as the scalar has bits, which is what makes real-time ECDH key generation and exchange fast enough for everyday secure communication.
Where is ECDH actually used in practice?
ECDH underpins key exchange in modern TLS connections that secure HTTPS websites, in the Signal Protocol that powers end-to-end encrypted messaging apps, and in the WireGuard virtual private network protocol. It is favored in these settings precisely because its small key sizes and fast computation suit constrained environments like mobile devices, browsers performing frequent handshakes, and lightweight networking software.
Try it live
Everything above runs in your browser — open Elliptic Curve Diffie-Hellman: Key Exchange on a Curve and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.
▶ Open Elliptic Curve Diffie-Hellman: Key Exchange on a Curve simulation