From Groups to ECDSA: Elliptic-Curve Cryptography from First Principles

Elliptic-curve cryptography is a form of public-key cryptography. At the API level, signing and verification can look like black boxes. At the mathematical level, the notation can become dense before it explains anything useful.

The goal here is to take a route between those extremes. We will build ECDSA one layer at a time: groups, finite fields, elliptic-curve point addition, scalar multiplication, and finally the signature algorithm itself. By the end, a verifier’s ability to check a signature without learning the private key should emerge naturally from the arithmetic.

Begin with the group operation

Elliptic-curve cryptography depends on groups, but the formal definition feels more remote than the idea itself. Start with ordinary addition and the claim that zero is the unique additive identity. If a and b are both identities, then a = a + b = b. That short proof introduces the identity using an operation we already understand.

A group is a set with an operation that has four useful guarantees:

1. combining two members produces another member of the set;
2. how successive operations are grouped does not change the result;
3. an identity leaves a value unchanged; and
4. every value has an inverse that returns it to the identity.

The integers under addition already provide most of the intuition. Zero is the identity, the inverse of 5 is -5, and repeated addition gives scalar multiplication. The vocabulary is abstract, but the behavior is ordinary.

The next useful idea is a cyclic group. Starting from one generator and repeatedly applying the operation enumerates the group. Compare addition modulo 4 with addition modulo 5 to make the role of prime order visible. In a cyclic group of prime order, every element except the identity is a generator.

The prime-order group Z₅ makes every nonzero element a generator.

With that framing, elliptic-curve points become another collection of values governed by predictable rules for combination.

Move arithmetic into a finite field

Cryptographic curves don’t use the smooth, continuous number line shown in the familiar curve diagrams. Their coordinates live in a finite field.

For a prime p, arithmetic in the field F_p wraps modulo p. Addition, subtraction, and multiplication stay inside a finite set of values. Division is multiplication by a modular inverse. Every nonzero value has such an inverse because p is prime.

This is the point where modular arithmetic stops being a programming trick and becomes part of the design. The field gives us a finite space with enough algebraic structure to define point addition consistently. Fermat’s little theorem supplies a practical way to find multiplicative inverses, so division remains available.

Now consider secp256k1, the curve defined by y² = x³ + 7. Its production field is far too large to plot usefully, so use the same equation over F₂₂₃ first. There is no continuous arc between the resulting points, but the same algebraic addition rules still apply.

The secp256k1 equation over F₂₂₃ produces a finite set of points; the familiar smooth curve disappears.

Turn curve points into a group

Over the real numbers, the point-addition construction is visual. Draw a line through two points on the curve. It intersects the curve at a third point. Reflect that point across the horizontal axis, and the result is the sum.

The special cases complete the operation:

• a tangent line handles adding a point to itself;
• a vertical line sends a point and its inverse to the point at infinity; and
• the point at infinity acts as the identity.

Point addition: intersect at C, then reflect to obtain A+B.

Over a finite field, the picture becomes a set of dots, so the geometry is no longer something we literally draw between coordinates. The formulas survive. Slope, intersection, and reflection are computed with field arithmetic, including modular inverses.

The points are not merely coordinates satisfying an equation. Together with point addition, they form a group. That gives us an identity, inverses, addition, and repeated addition, which is exactly the machinery public-key cryptography needs.

Scalar multiplication creates the useful asymmetry

Choose a public base point G with a large prime order n. Let e be the private scalar and P the public point:

P = eG

Here eG means adding G to itself e times, although real implementations use much faster algorithms. A point on the F₂₂₃ example makes the first few results of repeated addition concrete.

Scalar multiplication is repeated point addition over the toy field.

Computing P from e and G is efficient. Recovering e from G and P is the elliptic-curve discrete logarithm problem.

That difference is the security boundary. The public key is a point everyone may know. The private key is the scalar that produces it. Properly selected curves and key sizes make recovering that scalar computationally infeasible with known classical methods.

At this point, the public-key construction requires no new kind of object, only a new use for repeated group addition.

ECDSA is arranged so verification reconstructs the same point

ECDSA adds a message hash and a fresh per-signature scalar. Let z be an integer derived from the message digest, and let k be a secret nonce selected for this signature.

Signing follows this outline:

1. Compute the point R = kG.
2. Let r be the x-coordinate of R, reduced modulo n.
3. Compute s = k⁻¹(z + re) mod n.
4. Publish (r, s) as the signature.

Define the verification scalars u and v:

u = z/s mod n
v = r/s mod n
X = uG + vP

The signature is valid when the x-coordinate of X, reduced modulo n, equals r.

The formulas can look arbitrary until the substitutions are written out. Since P = eG:

X = zs⁻¹G + rs⁻¹eG
  = (z + re)s⁻¹G
  = kG

The verifier reconstructs the same point the signer uses without knowing either e or k. This cancellation is the payoff. The preceding layers reveal these few lines as group arithmetic.

The verification recipe reconstructs R and checks that its x-coordinate is r.

The nonce is part of the secret

The private key isn’t the only value that must remain protected. The nonce k must be secret, unpredictable, and never reused with the same private key.

If two messages are signed with the same k, their signatures share enough algebraic structure to recover the nonce and then the private key. Biased or partially exposed nonces can also be dangerous. This is why production ECDSA implementations deserve the same scrutiny around randomness and side channels as they receive around curve selection.

Reusing k makes the private key an algebraic consequence of two signatures.

This exact failure enabled the 2010 PlayStation 3 compromise. It also gives us a broader engineering lesson. A value described as temporary may still carry the full security weight of a long-lived credential. Lifetime and sensitivity are different properties.

Why the layers matter

The point is larger than one signature algorithm. Each abstraction must earn its place in the stack.

Each layer answers one question and introduces the vocabulary needed for the next:

• groups explain the required behavior of an operation;
• finite fields supply a closed arithmetic system;
• elliptic curves supply a useful group of points;
• scalar multiplication produces a public value from a private scalar; and
• ECDSA combines those pieces so a signature can be verified publicly.

Skipping a layer makes the final formula shorter on the page but harder to understand. Spending time on every theorem has the opposite problem. The useful path preserves the dependency chain while choosing the smallest example that makes each dependency concrete.

Start with the behavior a design needs, introduce the mechanism that provides it, and keep the connections visible. Good abstractions compress an idea after it is understood; they don’t hide the idea before it has been examined.

The practical boundary

Understanding ECDSA is valuable. Implementing it for production is a separate matter.

Real cryptographic libraries must address constant-time operations, secure nonce generation, validation of points and parameters, serialization rules, malformed input, and many other details that a conceptual walkthrough intentionally omits. Application code should rely on maintained, reviewed implementations of the algorithm.

For the complete specifications and a production API example, see:

• NIST FIPS 186-5, Digital Signature Standard
• SEC 1: Elliptic Curve Cryptography
• Go’s crypto/ecdsa package