Lesson 7 of 7 · about 12 minutes

The real thing

Same six formulas, 256-bit numbers, real code in your browser. Sign, verify — and then work out why a genuine-looking signature refuses to pass.

Nothing new remains to learn. P-256 — also called secp256r1 or prime256v1 — is the same six formulas over a larger field, and this lesson is where you run them on the genuine article, in this browser, with an audited library rather than by hand.

P-256, the curve in most TLS certificates and passkeys

p = 2^256 - 2^224 + 2^192 + 2^96 - 1
a = -3
b = 5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f6
    3bce3c3e 27d2604b
n = ffffffff 00000000 ffffffff ffffffff bce6faad a7179e84
    f3b9cac2 fc632551          (the group order: ~1.16 * 10^77 points)

a private key is one integer below n
a public key is one point:      64 bytes
a signature is two integers:    64 bytes

The proportions are worth pausing on. An RSA key offering comparable security is 3072 bits — twelve times the size — and its signatures are twelve times larger too. That difference is why passkeys, modern TLS certificates, SSH keys and blockchain addresses all converged on elliptic curves.

Why real signatures fail

In practice, a signature that will not verify is almost never a broken curve. It is two programs disagreeing about something outside the mathematics. The short list, roughly in order of how often it happens:

The hash. One side used SHA-256, the other SHA-384 or SHA-512. Or one side hashed a value that had already been hashed. z differs, so everything after it differs.
The encoding. DER wraps r and s in an ASN.1 sequence with length bytes and sign padding; the raw form is just the two integers concatenated to fixed width. Feeding one to a parser expecting the other produces an error that mentions neither.
The message. A trailing newline, CRLF instead of LF, a different Unicode normalisation, JSON keys serialised in a different order. All of these change the bytes, and the bytes are what was signed.
The key. The wrong key in a rotating set, a key for a different curve, or a compressed point handed to code expecting an uncompressed one.

The exercise below gives you one of these to diagnose. You get the message, the public key and a signature that fails the ordinary check, plus a panel that lets you change one variable at a time. That last part is the actual skill: not knowing the answer in advance, but knowing how to isolate it. It is the same procedure the Error Explainer automates for library error messages.

Your turn

Sign and verify with real cryptography

Same six formulas, 256-bit numbers, running in this tab. Generate a key pair, sign a message, verify it — then change one character of the message and verify again. You are done when you have seen the check pass and seen it fail.

Message

○ watched a signature verify
○ watched one fail after the message changed

What is actually happening under those buttons

keygen   d  = random 32 bytes in 1..n-1
         Q  = d*G                       (one double-and-add ladder)
sign     z  = sha256(message)           (leftmost 256 bits, as an integer)
         k  = RFC 6979 deterministic    (derived from d and z, never random here)
         r  = (k*G).x mod n
         s  = inv(k) * (z + r*d) mod n
verify   u1 = z * inv(s) mod n
         u2 = r * inv(s) mod n
         ok = (u1*G + u2*Q).x mod n == r

Every line is one you have already computed by hand. RFC 6979 is the one addition: instead of drawing k from a random source, it derives k from the private key and the message hash with HMAC, which removes the failure mode from lesson 5 entirely — no randomness, no chance of repeating a nonce.

Your turn

Find out why this signature will not verify

Below is a real P-256 signature that someone swears is valid, along with the message and the public key it was made for. Verified the ordinary way — SHA-256 over the message — it fails. The bytes are not damaged, though, and nothing here is a trick. Change one variable at a time until the check flips, then say what was wrong.

message

I verified an ECDSA signature by hand.

public key (uncompressed)

046af0951cb496f722233b8484cf16b07b509a2c3a5fae47630e85c238bab4ccf10607bd5b4197e561f7f073e00ad28fd1721b0a75635ef46fdcb2fa9fcf2fe59d

signature

r = 758fa41aaa623c12352e98edb0ead2c092840874883fd9d7bc71c8cff4dcca66 s = 2029128655938cd1a5f9e6ee7434237311d930b693277e29f49499e922a45e76

Digest the message with

Why does the ordinary check fail?

The signature bytes are corrupted or random.The signature was made over a different message.The public key belongs to a different key pair.The signature was made over a different hash of this same message.

Where to take this next

Real failures look exactly like the one you just diagnosed: something on one side of the exchange disagrees with the other about the hash, the encoding, the curve or the key. The Error Explainer takes an error message from a library and walks the same short list of suspects. The Signature Verifier lets you paste your own key and signature and see which combination passes, and the Nonce Reuse Checker looks for the lesson-5 catastrophe in real signature sets.

Loading the elliptic-curve library…

What you now know

P-256 signing and verification are the toy formulas with a 256-bit prime.
A failed verification usually means a mismatch, not broken math: wrong hash, wrong message, wrong key or wrong encoding.
The fastest way to diagnose one is to change a single variable at a time and watch which change flips the result.