What happens if the random nonce k in ECDSA is reused or predictable?
If k is reused for two different messages, the private key can be trivially recovered from the two signatures — this is a catastrophic implementation failure.
* Two signatures with the same $r$ betray a repeated $k$; subtracting their $s$ equations yields $k$, and then the private key $d$ falls out algebraically. *
The math: Given two signatures $(r, s_1)$ and $(r, s_2)$ for messages $m_1$ and $m_2$ with the same $k$:
- Both have the same $r$ (since $R = k \cdot G$ is the same)
- $s_1 = k^{-1}(h_1 + r \cdot d)$ and $s_2 = k^{-1}(h_2 + r \cdot d)$
- Subtracting: $s_1 - s_2 = k^{-1}(h_1 - h_2)$
- Therefore: $k = (h_1 - h_2)(s_1 - s_2)^{-1} \mod n$
- Once $k$ is known: $d = r^{-1}(k \cdot s_1 - h_1) \mod n$ → private key recovered!
Real-world incident — Sony PS3 (2010):
- Sony used ECDSA to sign PS3 firmware
- They used a fixed value of k (not even reused — literally constant!)
- Hackers (fail0verflow) noticed all signatures had the same $r$
- Extracted Sony's private signing key → could sign custom firmware
- Led to PS3 jailbreaking
Lesson: The random nonce $k$ must be truly random and unique for every signature. Modern implementations use deterministic $k$ generation (RFC 6979) — deriving $k$ from the message and private key via HMAC, ensuring uniqueness without relying on the RNG.
Go deeper:
RFC 6979 — Deterministic ECDSA/DSA — derives $k$ from the key and message, eliminating the whole class of reuse failures.
fail0verflow — Console Hacking 2010 (27C3) — the talk that revealed Sony's constant-$k$ PS3 break live.- ECDSA — Wikipedia (security) — the key-recovery derivation from a repeated nonce.