Personal Index
← All writing

October 6, 2026

Why ECDSA Nonces Must Never Repeat

ECDSA has a sharp edge that most engineers learn about only after reading an incident report: the signature depends on a per-signature secret value, the nonce k, and if that value ever repeats, the private key falls out with a few lines of arithmetic.

The signing equation

Let G be the curve's generator, n its order, d the private key and z the hash of the message. To sign:

k←$[1,n−1]r=(k⋅G)x mod ns=k−1(z+rd) mod nsignature=(r,s)\begin{aligned} k &\xleftarrow{\$} [1, n-1] \\ r &= (k \cdot G)_x \bmod n \\ s &= k^{-1}(z + r d) \bmod n \end{aligned} \qquad \text{signature} = (r, s)

The nonce k is a one-time secret. It is never published, and the signature is only safe because nobody can recover it from (r, s).

What happens when it repeats

Suppose two different messages z1 and z2 are signed with the same k. Both signatures share the same r, which is already a visible tell. Subtract the two s values:

s1−s2=k−1(z1−z2)k=z1−z2s1−s2 mod n\begin{aligned} s_1 - s_2 &= k^{-1}(z_1 - z_2) \\ k &= \frac{z_1 - z_2}{s_1 - s_2} \bmod n \end{aligned}

Everyone can compute k now, since z1, z2, s1 and s2 are all public. Rearranging either signing equation gives the key:

d=s1k−z1r mod nd = \frac{s_1 k - z_1}{r} \bmod n

No brute force, no special hardware. Two signatures are enough.

This has happened

  • In 2010 it was shown that the PlayStation 3 firmware signed with a constant k, which allowed recovery of Sony's signing key.
  • In 2013, a flaw in Android's SecureRandom produced repeated r values in Bitcoin wallet signatures, and funds were stolen from the affected addresses.

Both are the same failure: a perfectly good curve and a broken source of randomness.

Biased nonces are also fatal

Exact repetition is the obvious case. The subtler one is a nonce that is merely predictable in a few bits, for example a generator that leaves the top bits zero. Each signature then yields a linear relation over d with a small unknown, which is an instance of the hidden number problem. With enough signatures, lattice reduction recovers the key, and published attacks have worked with fewer than 8 bits of bias per signature. "Random enough" is not a good enough standard here.

How it is avoided

  • Deterministic nonces (RFC 6979). Derive k from the private key and the message hash with HMAC-DRBG. The same message always gets the same k, different messages get unrelated values, and nothing depends on an RNG at signing time.
  • EdDSA by design. Ed25519 computes the nonce as a hash of a secret prefix of the key and the message, so determinism is part of the scheme rather than an add-on.
  • Distributed signing. In threshold and MPC schemes, the nonce is itself generated jointly. Each party contributes randomness, which means one weak participant doesn't determine k, but the protocol has to be careful that no participant can bias the result across many signatures.

Takeaways

  • Treat the nonce as exactly as sensitive as the private key.
  • Prefer implementations that don't need you to supply randomness at signing time.
  • If you ever see two signatures from one key with the same r, assume the key is compromised and rotate it.

The broader lesson is that a signature scheme's security proof assumes its randomness is ideal. Most real-world breaks come from the place where that assumption meets an actual operating system, library or device.