Public and private keys: math that lets you prove who you are

A padlock you can hand to strangers

Imagine you run a shop and you want anyone in the world to be able to send you a sealed box — people you have never met and can never share a secret password with in advance. So you do something clever: you mass-produce thousands of open padlocks and scatter them everywhere. Anyone can grab one, snap it shut around a box, and ship it to you. But only you, holding the single matching key at home, can ever open it. The padlock is public — give it to the whole world. The key is private — it never leaves your pocket.

That asymmetry — one thing everyone can use to lock, that only you can unlock — is the entire idea behind public-key cryptography. Earlier in this rung you met the cryptographic hash, a one-way fingerprint. Public-key crypto adds a second, richer kind of one-way math: a pair of keys that are mathematically bound together, where you can publish one half to the entire planet while keeping the other half secret — and nobody can work backward from the public half to the private one.

Why does a blockchain need this? Because there is no account database, no bank vouching for you, and no "forgot my password" button. Your key pair is your account. This is the cryptographic root of trustlessness: you prove you control an account with math, not with anyone's permission.

Two keys, and a one-way street

Concretely, your crypto wallet holds two numbers. The private key is just an enormous secret integer — picture a random number somewhere between 1 and roughly 10⁷⁷. The public key is computed from the private key by a fixed mathematical rule. The crucial property is the direction of difficulty: going forward (private key → public key) is cheap and instant, but going backward (public key → private key) is, as far as anyone on Earth knows, computationally impossible — you would have to try more numbers than there are atoms in the observable universe.

A function that is easy one way and infeasible to reverse is called a trapdoor (or one-way) function. A hash is one-way too, but it actively throws information away, so it has no inverse at all. A key pair is subtler: the public key really does pin down exactly one private key in principle — there is a unique correct answer — but finding that answer would take longer than the age of the universe. That is what lets you safely broadcast your public key. Paste it on a billboard, carve it in stone: your secret stays secret.

Why elliptic curves?

Elliptic-curve cryptography (ECC) sounds intimidating, but the object itself is simple: an elliptic curve is just the set of points (x, y) that satisfy an equation like y² = x³ + ax + b. Plotted over the real numbers it is a smooth, swooping curve. Its magic feature is that you can add two points on it to get a third point that is also on the curve, using a clean geometric rule: draw the straight line through the two points, find the third place where that line crosses the curve, and reflect it across the x-axis. That reflected point is the "sum."

Now take a fixed starting point G and add it to itself over and over: G, 2G, 3G, …, all the way to kG. Repeatedly adding a point to itself is called scalar multiplication, and here is the trapdoor in one sentence. Given the public starting point G and a secret count k, computing the destination point P = k·G is fast. But given only G and the destination P, recovering the count k — a problem called the elliptic-curve discrete logarithm — is believed to be infeasible. So now you can see exactly what the two keys are:

The secret count k is your private key. The resulting point P = k·G is your public key. Multiplying forward is your wallet computing your public key in a microsecond; the impossible reverse is an attacker who has your public key staring at the curve, unable to count the steps back to your secret.

Scalar multiplication, made concrete

A fair objection: if k is a 256-bit number — around 10⁷⁷ — surely your wallet cannot add G to itself that many times? Correct. Instead it uses double-and-add, the same shortcut as fast exponentiation. Write k in binary, then walk its bits from left to right: at every bit, double the running point, and whenever the bit is a 1, also add G. A 256-bit key needs only about 256 doublings and a handful of additions — milliseconds, not eternity.

# Compute P = k * G on an elliptic curve, by double-and-add.
# k is read most-significant-bit first.
function scalar_mult(k, G):
    R = O                       # O = the "point at infinity", the identity
    for bit in bits_of(k):      # walk k's binary digits, MSB -> LSB
        R = point_double(R)     # R = 2 * R   (one geometric doubling)
        if bit == 1:
            R = point_add(R, G) # R = R + G   (one geometric addition)
    return R                    # R is now exactly k * G

Let's trace a tiny example by hand with k = 13, whose binary is 1101. Watch how four doublings and three additions land us exactly on 13·G:

1. Start with R = O (the identity) and read 13 as the bits 1, 1, 0, 1 from left to right.
2. Bit 1: double O (still O), then bit = 1 so add G → R = G (that is 1·G).
3. Bit 1: double G to 2G, then bit = 1 so add G → R = 3G.
4. Bit 0: double 3G to 6G, bit = 0 so add nothing → R = 6G.
5. Bit 1: double 6G to 12G, then bit = 1 so add G → R = 13G. Done — four doublings and three adds instead of twelve additions.

How a wallet actually makes a key pair

Now the practical recipe. When a wallet mints a brand-new account, it does essentially three things:

1. Gather 256 bits of genuine randomness (entropy) from a secure source — the operating system's CSPRNG, or dedicated hardware noise. This is the seed of everything; weak randomness here is fatal, as we'll see.
2. Interpret those bits as the integer k, your private key, and check it falls in the valid range 1 ≤ k < n (n is the curve's order). The astronomically rare out-of-range value is simply rejected and re-rolled.
3. Compute the public key P = k·G by the double-and-add scalar multiplication above. That's it: k is kept secret forever, P can be shared freely.

Almost every major chain — Bitcoin and Ethereum included — does this on one specific curve, secp256k1. Its equation is y² = x³ + 7 (so a = 0, b = 7) computed not over the real numbers but over a finite field of integers modulo a 256-bit prime p. It fixes one public generator point G and an order n ≈ 1.158 × 10⁷⁷, which is the count of valid private keys. Your key is one number out of that staggering total — which is exactly why two honest wallets never accidentally generate the same key.

secp256k1 domain parameters  (the curve Bitcoin & Ethereum sign with)

  equation : y^2 = x^3 + 7   (mod p)            # a = 0, b = 7
  p (field): 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
             = 2^256 - 2^32 - 977
  G.x      : 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
  G.y      : 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
  n (order): 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

  private key  k : a random integer in [1, n-1]
  public  key  P : the point  k * G   (an (x, y) pair; 65 bytes raw, 33 compressed)

Where do the twelve words you have seen wallets show fit in? That is a seed phrase. Rather than store one raw private key, modern hierarchical-deterministic wallets turn a single human-readable mnemonic into a master seed, then deterministically derive an entire tree of key pairs from it. Back up the twelve words once and you have backed up every account at once. We unpack that derivation machinery in a later rung; for now, just hold onto the idea that the seed phrase is your private keys, dressed in friendlier clothing.

Guard the secret: what the math does and doesn't give you

The one place this whole scheme breaks in practice is bad randomness. If a wallet's entropy is predictable, an attacker can simply regenerate your private key — the curve never gets touched. This is not hypothetical. In 2013, a flaw in Android's SecureRandom let thieves recompute Bitcoin keys and sweep affected wallets. In 2023, the "Milk Sad" disclosure found that the popular Libbitcoin Explorer tool seeded keys from a mere 32-bit Mersenne Twister, and real funds were drained. The curve arithmetic was sound every time; the weak link was the random number generator feeding it.

One honest caveat about the future. The security of secp256k1 rests on the discrete-logarithm problem being hard for classical computers. A sufficiently large quantum computer running Shor's algorithm could, in principle, recover a private key from a public key. None exists today at anywhere near the scale required, and researchers are actively designing post-quantum signature schemes — but it is a genuine long-term consideration, not magic that is provably safe forever.

Step back and see what you now hold: a secret number only you know, and a public point anyone may see, welded together by a trapdoor no one can reverse. The obvious next question is — what do you actually do with them? In the next guide you use the private key to produce a digital signature with ECDSA on this very curve, so that anyone holding your public key can verify you authorized a transaction, while your secret never once leaves your device. That is how a transaction proves who you are.