# ECDSA nonce reuse directly reveals the private key because two signatures sharing the same r value expose k algebraically In ECDSA, the signature component `r = (k * G).x mod n` depends only on the nonce `k`, not on the message. If two signatures share the same `k`, they share the same `r`. An observer who sees two signatures `(r, s1)` and `(r, s2)` over messages `m1` and `m2` can compute: ``` k = (z1, z2) / (s1, s2) mod n d = (s1 * k, z1) / r mod n ``` where `z1`, `z2` are the message hashes and `d` is the private key. No computational hardness assumption is needed, this is pure algebra that completes in microseconds. The detection signature is the identical `r` value across two signatures. Blockchain researchers scanning the Bitcoin UTXO set have found numerous addresses with reused nonces, every such address had already been drained, because attackers monitor the mempool and sweep within seconds of detecting a reused nonce. This attack is not theoretical. The Sony PlayStation 3 private key was recovered using this technique (from firmware signing operations that shared a nonce). The 2013 Android SecureRandom weakness compromised Bitcoin wallets via insufficient nonce randomness, and blockchain researchers have identified ~1,000 Ethereum addresses with reused nonces, all already drained. The standard defense is RFC 6979 deterministic nonce generation, which derives `k = HMAC(private_key, message_hash)`. Because [[RFC 6979 deterministic nonce generation eliminates ECDSA private key leakage from randomness failures by deriving nonces from message and private key]], a unique nonce is guaranteed for each unique `(private_key, message)` pair without relying on randomness. Beyond nonce reuse, related attacks exploit biased nonces using lattice methods, [[biased ECDSA nonces enable lattice-based private key recovery with as few as two or three signatures]]. The severity of nonce reuse is maximal: exposure is immediate, recovery is algebraically trivial, and detection by an attacker requires only scanning for matching `r` values in the mempool or historical transaction data. --- Relevant Notes: - [[RFC 6979 deterministic nonce generation eliminates ECDSA private key leakage from randomness failures by deriving nonces from message and private key]]: the canonical defense - [[biased ECDSA nonces enable lattice-based private key recovery with as few as two or three signatures]]: extends the nonce vulnerability beyond exact reuse to statistical bias Topics: - [[vulnerability-patterns]]