Schnorr Forge

Schnorr Signatures · BIP-340 · secp256k1

An interactive, browser-only lab for BIP-340 Schnorr signatures. Generate a key, sign a message, and verify it with real elliptic-curve arithmetic — then step through the signing equation, reuse a nonce to watch the private key fall out by algebra, and see how two signatures add into one.

Not production cryptography — a teaching demo. Keys are generated per-session in memory and never stored or transmitted. There is no backend. For real signing, use the audited @noble/curves schnorr implementation — which this demo cross-checks against byte-for-byte.

What It Is

Schnorr is the signature ECDSA wishes it were: one clean, linear equation.

sign:    s = k + e·x            e = tagged-hash(R.x ‖ P.x ‖ m)
verify:  s·G = R + e·P          R = k·G,  P = x·G

• x private key · P = x·G public key (x-only, 32 bytes in BIP-340)
• k one-time secret nonce · R = k·G the public commitment
• e the Fiat–Shamir challenge · s the response

The primitives are BIP-340 Schnorr over secp256k1 (x-only public keys, tagged hashes, 64-byte signatures) with BIP-340 deterministic nonce derivation. Group arithmetic comes from @noble/curves; the BIP-340 layer itself — tagged hashes, the commit/challenge/respond equation, x-only/even-y encoding, and verification — is hand-rolled in src/schnorr/bip340.ts so every intermediate value is inspectable. The security model is standard EUF-CMA signatures: unforgeable without the private key, provided the nonce is never reused.

That last clause is the whole drama of this lab. Schnorr's linearity is exactly what makes multisig and threshold signing possible — and exactly what turns one reused nonce into total key compromise.

Exhibits

1. Sign & Verify — Pick or randomize a key, supply a message as UTF-8 text or exact hex bytes, choose deterministic or randomized (hedged) nonce derivation, and sign. See the three moves (commit R, challenge e, respond s), the 64-byte signature, and a compute-both-sides verification that shows s·G and R + e·P byte-for-byte. A "Break it" button flips one message byte and watches the real verifier reject it, an optional BIP-340 details disclosure exposes the even-y/parity normalization on real intermediates, and copy/export/shareable-verify-link actions handle only public artifacts (private key copy is separately marked).
2. Verify Workbench — Paste an x-only public key, signature, and message (UTF-8 or hex) from any BIP-340 implementation — no private key needed — and watch the explicit five-stage pipeline decide: parse & lengths → range checks → lift points → recompute challenge → compare s·G against R + e·P. Curated presets cover a valid signature and the malformed rejections (off-curve key, out-of-range scalar, changed message, wrong length).
3. The Equation — A user-driven, step-at-a-time walk through commit → challenge → respond → verify, ending in the algebra s·G = (k + e·x)·G = R + e·P. Motion is tied to your clicks; nothing loops on its own.
4. Nonce Reuse → Key Recovery — The break-it centerpiece. A deliberately faulty signer reuses one nonce across two messages; the panel then runs the actual recovery x = (s₁ − s₂)·(e₁ − e₂)⁻¹ mod n and shows the recovered key equals the real secret. Isolated and clearly marked broken — never the default path.
5. BIP-340 Test Vectors — All 19 official vectors run through the same hand-rolled verify(), including the malformed cases that must be rejected (point off the curve, out-of-range scalars, negated values). Each row expands to its full artifacts and the exact failing stage, and can be sent to the Verify Workbench. Green means our verdict matched the spec.
6. Why Linearity Matters — Two independent signers produce responses s₁, s₂ that literally add into one combined signature the ordinary verifier accepts against the summed key — the seed of Schnorr multisig, pointing to MuSig2 and FROST.

Several exhibits end with an optional quick check — a one-question prediction with an immediate explanation — targeting a common misconception. The lab stays fully usable whether or not you answer them.

When to Use It

• Use Schnorr/BIP-340 when you want short, linear, aggregatable signatures — Bitcoin Taproot, multisig, threshold signing.
• Use deterministic (or hedged) nonce derivation always — never a bare RNG for the nonce.
• Do NOT roll your own signer for production from this code. It is optimized for transparency, not constant-time safety. Use @noble/curves, libsecp256k1, or an equivalent audited library.
• Do NOT ever reuse a nonce, derive it from anything an attacker can force to repeat, or truncate its entropy. Exhibit 4 shows exactly why.

Live Demo

https://systemslibrarian.github.io/crypto-lab-schnorr-forge/

Sign a message, flip a byte and watch verification fail, force a nonce reuse and recover a key, and combine two signers into one signature — all in the browser, no install.

This is the beginning of the README. Read the rest at the original. Read the full README ↗