secp256k1: Keys as Points on a Curve

The overview made the promise this part has to keep: on a chain of untrusting strangers, the only thing that proves an account is yours is a secret only you hold. There is no bank, no password server, no “forgot my login” flow. This page builds the mathematical object that makes that possible — the key pair — and the single one-way operation that ties a public identity to a private secret.

Everything downstream depends on it. The address you send funds to is a hash of the public key we build here. The signature that authorizes a transaction is a proof, checkable by anyone, that you know the private key without revealing it. Both stand on one curve, secp256k1, and one asymmetry: multiplying is easy, dividing is not.

The whole idea in one line

A private key is a secret number. The public key is that number times a fixed point on a curve. The multiplication is easy to do and — as far as anyone knows — infeasible to undo.

   private key d          public key Q
   (a 256-bit secret) ──► Q = d · G ──► (a point on the curve)
        │                                      │
   keep this hidden                       publish this freely
        │                                      │
        └── recovering d from Q is the ────────┘
            elliptic-curve discrete-log problem: infeasible

That is the entire security model of an Ethereum account, and the rest of this page is just making each word of it precise: what d is, what G is, what ”·” means, and why the arrow only points one way.

The private key is just a random integer

Strip away the mystique: an Ethereum private key is a 256-bit integer d. Nothing more. It is not a file, not a certificate, not something a server issues — it is a number you pick at random and never tell anyone.

There is exactly one constraint. It must lie in the range:

   1 ≤ d ≤ n - 1

where n is the group order of the curve (defined below). A d of 0 is invalid, and any d ≥ n wraps around and is equivalent to a smaller one. In practice a wallet grabs 32 bytes from a cryptographically secure random source and, on the astronomically unlikely chance the result is 0 or ≥ n, draws again.

// The shape of key generation (illustrative). The whole security of the
// account rests on THIS line having real, unpredictable entropy.
let mut d = [0u8; 32];
secure_rng.fill_bytes(&mut d);        // 256 bits from a CSPRNG
assert!(is_in_range(&d));             // 1 <= d <= n-1, else redraw

That is the security boundary of the entire account. Not a login page, not a database — this one call to a random number generator. We will come back to why that matters more than anything else on this page.

n is roughly 1.158 × 10^77. To put that in perspective:

   valid private keys   ≈ 1.158 × 10^77
   atoms in the Earth    ≈ 1.3   × 10^50
   ratio                 ≈ 10^27  (a billion billion billion Earths of keys per atom)

A correctly generated key is one point in a space so large that guessing another user’s key by brute force is not “hard” — it is thermodynamically impossible with any conceivable machine. The threat is never that someone guesses your key. It is that your key was never random to begin with. More on that below.

What is secp256k1?

secp256k1 is a specific, standardized elliptic curve — the same one Bitcoin uses. “Same curve as Bitcoin” is not a coincidence; Ethereum inherited a battle-tested, widely-implemented primitive rather than inventing its own. The name encodes it: security over a prime field, 256-bit, koblitz curve, variant 1.

It is defined by four public parameters. None of them are secret; they are baked into every wallet and node on Earth.

   secp256k1 parameters (all public, all fixed)

   p  the prime field modulus.   All arithmetic is done mod p.
      p = 2^256 − 2^32 − 977
      (a 256-bit prime, chosen to be fast to reduce)

   curve equation:   y² = x³ + 7   (mod p)
      i.e. a = 0, b = 7 — unusually simple, which helps make it fast

   G  the generator point. A single, fixed (x, y) on the curve that
      every key pair is built from.

   n  the group order. The number of distinct points G generates before
      it cycles back to the start. n ≈ 1.158 × 10^77.

The curve, and “points” on it

An elliptic curve over a prime field is just the set of (x, y) pairs that satisfy the equation y² = x³ + 7, where x and y are integers taken modulo the prime p. It is not a smooth line you can draw — it is a scattered cloud of ~n discrete points. But the equation is symmetric in y (if (x, y) is on the curve, so is (x, −y)), which is why a point is fully determined by its x value plus a single bit telling you which of the two y values to take. That fact will matter when we compare compressed and uncompressed keys.

To these points we attach two operations, and here is the crucial part: they are defined to behave like arithmetic, even though the “numbers” are points.

Point addition: adding two points gives a third

Given two points P and Q on the curve, there is a rule — draw the line through them, find where it hits the curve a third time, and reflect over the x-axis — that produces a third point also on the curve. Call it P + Q. You do not need the geometry; you need one fact: the result is always another point on the same curve, and this “addition” obeys the usual laws (it is associative and commutative). There is even an identity element (a “point at infinity”, the curve’s version of zero).

   point addition (the geometric intuition)

        P              a straight line through P and Q
         \            hits the curve at exactly one more point R';
          \  Q        reflect R' over the x-axis to get R = P + Q.
           \/
           /\
          /  \___ R'   (third intersection)
         R            (R = P + Q, the reflection)

The takeaway is not the picture. It is that ”+” on points is a real, well-behaved operation.

Scalar multiplication: adding a point to itself, fast

If you can add points, you can multiply a point by an integer — it just means adding the point to itself that many times:

   d · G  =  G + G + G + ... + G     (d copies)

Done naively, computing d · G for a 256-bit d would take ~10^77 additions — impossible. But there is a shortcut, double-and-add, that does it in about 256 steps instead:

   double-and-add: compute d · G in ~256 doublings, not d additions

   read d in binary, from the top bit down:
     start with result = 0 (point at infinity)
     for each bit of d:
        result = result + result          // "double"
        if this bit is 1:
           result = result + G            // "add"
   return result

Each bit costs at most one doubling and one addition, so a 256-bit key needs on the order of a few hundred point operations — microseconds on any laptop. This is the “easy forward” half of the asymmetry.

// double-and-add, in the shape ethmini-style code would use.
// `add` and `double` are the curve's point operations.
fn scalar_mul(d: &Scalar, g: Point) -> Point {
    let mut result = Point::infinity();     // additive identity
    for bit in d.bits_high_to_low() {       // 256 iterations
        result = result.double();           // always double
        if bit {
            result = result.add(&g);         // conditionally add
        }
    }
    result                                   // = d · G
}

The public key: `Q = d · G`

Now the whole construction fits together. Take the fixed generator G, multiply it by your secret d using double-and-add, and the resulting point Q is your public key:

   Q = d · G

Q is a point — a pair of 256-bit coordinates (x, y). You can hand Q to the entire world. Anyone can verify signatures against it (next-but-one page), send you funds via the address derived from it, and learn nothing about d in the process. That last clause is the entire point, and it needs its own section.

Why you cannot go backwards

Forward is easy: d → Q in ~256 steps. Backward — recover d given Q and G — is the elliptic-curve discrete-logarithm problem (ECDLP), and no efficient algorithm for it is known.

Contrast it with ordinary numbers, where “reversing multiplication” is just division and is trivial. On the curve there is no division that recovers d. The best known attacks (Pollard’s rho and friends) take on the order of √n ≈ 2^128 operations — the same “thermodynamically impossible” territory as guessing the key outright.

   the asymmetry that IS the security

   d  ──── multiply by G (double-and-add, ~256 steps) ────►  Q
   d  ◄─── ??? no known efficient algorithm (ECDLP) ───────  Q

   easy one way, infeasible the other. That gap is the whole game.

This is a trapdoor: a one-way function that is cheap to compute and — absent the secret — infeasible to invert. Publishing Q while keeping d is safe only because this asymmetry holds. If someone ever finds a fast way to solve the ECDLP (a large enough quantum computer running Shor’s algorithm is the usually-cited threat, though none exists as of 2024), every account’s private key becomes derivable from its public key, and the security model collapses. That is why the public key — and the address that comes from it — is the thing you can safely reveal, and d is the thing you must never let leak.

How Ethereum uses the public key

Bitcoin and Ethereum share the curve but format the public key differently, and the difference is worth pinning down because it trips people up constantly.

A curve point Q = (x, y) can be written two ways:

   uncompressed:  0x04 ‖ x (32 bytes) ‖ y (32 bytes)   = 65 bytes
   compressed:    0x02 or 0x03 ‖ x (32 bytes)          = 33 bytes

The compressed form drops y entirely and stores one prefix byte (0x02 / 0x03) to say which of the two possible y values to reconstruct — remember, the curve is symmetric in y, so x plus one bit pins the point down. Bitcoin leans heavily on the compact 33-byte form.

Ethereum uses the uncompressed public key, and hashes the raw 64 bytes — the x and y coordinates concatenated, with the 0x04 prefix stripped off:

   full point:            0x04 ‖ x ‖ y        (65 bytes)
   what Ethereum hashes:        x ‖ y         (64 bytes, no 0x04)

That 64-byte value is fed into Keccak-256 to derive the address — the subject of the next page and then From Public Key to a 20-Byte Address. The one detail to carry forward: strip the 0x04, hash the raw x ‖ y. Include the prefix by mistake and you compute a completely different, wrong address.

Under the hood — the same key, three faces

It helps to see that a single account has one secret and several public representations, each a deterministic step from the last:

   d               32 bytes   the secret. Random. Never shared.
     │  Q = d·G  (scalar multiplication on secp256k1)
     ▼
   Q = (x, y)      64 bytes   the public key. x‖y, prefix stripped.
     │  Keccak-256(x ‖ y)
     ▼
   hash            32 bytes
     │  take the last 20 bytes
     ▼
   address         20 bytes   0x… — what you share to receive funds.

Each arrow is one-way (multiplication, then hashing, then truncation), which is why you can publish the bottom of the chain and reveal nothing about the top. Notice there is no curve math below the public key — deriving the address is pure hashing, which is why it gets its own pages. The curve’s only job is the very first arrow: turning the secret d into the point Q.

The security boundary is key generation — nowhere else

Everything above says the same thing from different angles: an Ethereum account is its private key, and the only moment that matters for its safety is the instant that key is created.

There is no server that can reset it, no admin who can freeze it, no “recover account” button. If d leaks, whoever holds it is you, irreversibly — they can drain the account and there is no authority to appeal to, because to the chain a valid signature is indistinguishable from a legitimate one. And if d was generated with weak randomness, an attacker does not need to break the curve at all; they just regenerate the small set of keys your broken generator could have produced and check each address for a balance.

   two ways to lose an account — note that neither involves breaking secp256k1

   1. leaked key        →  attacker has d directly. Game over.
   2. low-entropy key   →  attacker guesses d because it was never
                           random. The curve was strong; the dice weren't.

Two real, dated classes of failure make the point that the dice, not the curve, are the weak link:

Brain wallets. For years people generated private keys by hashing a memorable passphrase (e.g. Keccak/SHA256("correct horse battery staple")). Because human-chosen phrases have far less entropy than 256 bits, attackers pre-computed the addresses for enormous dictionaries of phrases and swept any that ever held funds — often within seconds of a deposit. Documented thefts ran for years across the mid-2010s. The curve was never touched; the entropy was.
The Android SecureRandom flaw (August 2013). A bug in Android’s SecureRandom meant some Bitcoin wallets generated keys (and, worse, reused signature nonces) with predictable randomness, letting attackers recover private keys and steal funds. Same lesson, same root cause: a strong curve fed by a weak random source is a weak system.

The takeaway for Ethereum is identical, because it is the same curve: your account is exactly as secure as the randomness that made its key. Use a well-audited wallet’s key generation; never invent your own.

The architect’s lens

Why does it exist? A chain of strangers needs a way for you to prove “this account is mine” without any trusted party vouching for you. secp256k1 gives every account a self-issued identity: a secret number, and a public point derived from it that anyone can check against but no one can reverse.
What problem does it solve? It replaces accounts held by an authority with accounts held by a key. The one-way map d → Q lets you publish an identity (Q, and the address from it) while keeping the thing that controls it (d) entirely private — the precondition for permissionless, self-custodied accounts.
What are the trade-offs? Absolute self-custody means absolute self-responsibility: no reset, no recovery, no fraud reversal. The security also rests on the unproven hardness of the ECDLP and on the quality of your randomness — two assumptions you inherit rather than verify.
When should I avoid it? When users genuinely need recoverability or shared control, raw single-key EOAs are the wrong tool — that is exactly what smart-contract wallets, multisigs, and social recovery exist to layer on top. The curve stays; the single-point-of-failure key does not.
What breaks if I remove it? Everything. Without the key pair there is no way to authorize a transaction or own an account. The signature, the address, and the very notion of an “owner” all dissolve — the chain would have state but no way to say who is allowed to change it.

Check your understanding

In one sentence, what is a private key, and what constraint must it satisfy?
What operation turns a private key d into a public key Q, and why can it be computed in ~256 steps rather than d steps?
Name the problem that makes recovering d from Q infeasible, and explain why that asymmetry is the entire security basis.
Ethereum and Bitcoin share the curve but format the public key differently. What exactly does Ethereum hash to derive an address, and which byte must be removed first?
If secp256k1 has never been broken, how do attackers steal from accounts anyway? What does that tell you about where the real security boundary sits?

Show answers

A private key is just a random 256-bit integer d, and it must lie in the range 1 ≤ d ≤ n − 1, where n is the group order of secp256k1. It is not a file or a certificate — only a number.
The public key is Q = d · G, the scalar multiplication of the fixed generator G by d. Double-and-add exploits the binary expansion of d: each of its ~256 bits costs one point-doubling and at most one point-addition, so the cost is linear in the number of bits, not in the value d.
The elliptic-curve discrete-logarithm problem (ECDLP). d → Q is cheap (double-and-add) but Q → d has no known efficient algorithm (best attacks are ~2^128). That one-way trapdoor is what lets you publish Q while keeping d secret — the whole account model depends on it.
Ethereum hashes the uncompressed public key as the raw 64 bytes x ‖ y (the two coordinates concatenated), after stripping the 0x04 prefix. That 64-byte value goes into Keccak-256; including the 0x04 yields a different, wrong address.
By attacking the randomness, not the curve — a leaked key hands the account over directly, and a low-entropy key (brain wallets, a broken RNG) lets an attacker regenerate and check the small set of keys the weak source could have produced. The real security boundary is key generation, not any server or the curve’s math.