Nonce Reuse

Nonce reuse is one of the most dangerous failure modes in digital signatures, including both the ECDSA and Schnorr schemes Bitcoin uses. Every signature requires a secret one-time value — the nonce, often written k or r. If a signer ever produces two signatures over different messages using the same nonce with the same private key, an observer can recover the private key with simple algebra. No brute force, no supercomputer: the key falls out of two equations, and every coin it protects becomes trivially stealable. (This signing nonce is unrelated to the nonce miners grind in a block header — same word, entirely different job.)

The algebra of the leak

In Schnorr signing, each signature has the form s = r + e·x, where r is the secret nonce, x is the private key, and e is a per-message challenge hash. Two signatures sharing the same r over different messages give two linear equations in two unknowns. Subtract them and the nonce cancels: x = (s₁ − s₂) / (e₁ − e₂) modulo the curve order. ECDSA fails the same way with slightly different algebra — reuse of k reveals k, and k reveals the key. Worse, the nonce does not even need to repeat exactly: partial leakage or a slight statistical bias in nonce generation, observed across enough signatures, can be aggregated with lattice techniques into full key recovery. The nonce must be secret, unique, and uniformly random — every time, forever.

Lessons written in stolen coins

This is not a theoretical concern. In 2013, a flaw in Android's SecureRandom left Bitcoin wallet apps generating repeated or predictable ECDSA nonces, and attackers swept funds from affected addresses — a public, well-documented incident that pushed the ecosystem toward deterministic nonces. Years earlier, Sony's PlayStation 3 firmware-signing key was extracted because the console's ECDSA implementation used a constant nonce for every signature. Both cases share the moral: the signature math was fine; the randomness plumbing failed, and the private key paid the price.

Bitcoin's defenses

Modern practice removes the dice roll. RFC 6979 defines deterministic ECDSA nonces derived by hashing the private key and message, so the same input always yields the same safe nonce and no RNG is consulted at signing time. BIP340 hardens Schnorr signing further: the nonce is derived from a tagged hash of the private key, the message, and the public key, mixed with fresh auxiliary randomness — deterministic enough to prevent reuse, randomized enough to blunt fault and side-channel attacks. BIP340 also warns against mixing deterministic nonce schemes across different protocols with the same key, which can itself manufacture a cross-protocol reuse. Multi-party signing raises the stakes again: naive nonce handling in aggregated signatures is exploitable, which is why protocols under signature aggregation add commitment rounds, and why a hardware wallet should never sign the same session state twice.

The operational takeaway

Determinism buys auditability as well as safety. With RFC 6979-style derivation, signing the same message with the same key always yields the same signature, so a device that suddenly produces a different signature for identical input is visibly misbehaving — a property auditors and wallet developers actively use. It also closes an exfiltration channel: a malicious signer with freedom over its randomness can leak key bits through its choice of nonces, and anti-exfiltration protocols exist precisely to let a host verify the device's nonce was honestly constrained. The nonce, in short, is where a signer's honesty is tested.

Users cannot audit nonce generation by eye, so the defense is choosing well-reviewed, widely deployed signing implementations and keeping them updated. For builders, the rule is absolute: never write your own nonce logic, never reuse signing state, and treat any RNG involved in signing as consensus-critical infrastructure.