Every ECDSA key is one scalar and one point addition, repeated. Here the same arithmetic runs over a field small enough to draw: pick a curve, add points, slide k and watch kG jump around — then see why running that backwards is the hard part.
100% local — everything runs in your browser, nothing is sent to any server
Big enough that the point cloud stops looking like a pattern, small enough that a full search takes a few dozen steps. Its 100 points do not form a single cycle — the longest run any generator produces here is 50.
Click any point to make it the generator G. The dashed line is y = p/2: every point has a partner mirrored across it, and that partner is its negative −P. Points on the line itself (y = 0) are their own negatives.
1G = 1 × (0, 10)
(0, 10)
Nobody computes 1G by adding G to itself 0 times. Write k in binary and you only need one doubling per bit, plus one addition per 1-bit — the idea behind every ECDSA implementation, which then adds windowing and constant-time handling on top.
The reverse question — given G and 1G, find k — is the elliptic-curve discrete logarithm problem. On a curve this small it is not a problem at all: just walk the sequence.
That last number is the whole point. A machine doing 10⁹ curve operations per second, run on 10⁹ machines in parallel, would still need about 10¹³ years — several hundred times the current age of the universe. No faster general algorithm against a well-chosen curve is publicly known; that assumption, not any secrecy in the formulas, is what an ECDSA key rests on.
Nothing changes between this page and a production key except the size of the numbers. secp256k1 — the curve behind Bitcoin and Ethereum — is y² = x³ + 7, the same equation as the mini-curve above, over a prime just under 2²⁵⁶ instead of 127. P-256, the curve in most TLS certificates and passkeys, is y² = x³ − 3x + b over a different 256-bit prime. Both have a published generator point G and a group order n of about 2²⁵⁶.
A key pair is exactly the two things the Scalar multiplication tab shows. The private key is the scalar k: a random integer in 1 … n − 1. The public key is the point kG: the generator added to itself k times, computed by the same double-and-add ladder, about 256 doublings and a couple of hundred additions. Publishing kG reveals nothing usable about k for the same reason the slider does not — the only known way back is to search, and the search space is the size of the group.
Signing adds one more scalar: a per-signature nonce, multiplied by G to produce r, with s tying the message hash and the private key together. That is why nonce handling is the sharp edge of ECDSA — the arithmetic on this page is unforgiving of a repeated random value. Generate real key pairs and signatures with the Test Vector Generator, or read how this compares with the factoring problem in ECDSA vs RSA.
The playground enumerates every solution of y² = x³ + ax + b modulo a small prime p by squaring each field element once and matching the results against the right-hand side — a few thousand operations, which is why the plot appears instantly and why the same approach is hopeless for a 256-bit prime. Point addition uses the standard chord-and-tangent formulas with a modular inverse computed by the extended Euclidean algorithm, and kG uses double-and-add, the same ladder a real signing routine walks.
Two sanity checks run on the arithmetic itself: the number of points found always lands inside the interval Hasse's theorem allows around p + 1, and the order of every point divides the group order, as Lagrange requires. The real-number tab draws the identical formulas with ordinary floating-point math, which is only ever a teaching aid — cryptography needs the exactness of integers modulo a prime. Everything is computed locally in your browser; the page makes no network requests and has no inputs worth keeping.