Implementation Pitfalls

ECDSA is notoriously easy to break with a bad implementation:

1. Nonce reuse: same k → recovers d.

• Sony PS3 (2010): static k. Anyone could sign as Sony.

• Many Bitcoin wallets in early days. Lost coins.

  d = (s1m2 - s2m1) / (r * (s2 - s1)) mod n -- when r is shared

2. Predictable nonces: PRNG bias → recover d through lattice attacks.

• Java Android wallet bug (2013): predictable RNG. ~50 BTC stolen.

3. Side channels: timing, cache, EM emanations leak k → recover d.

• Lattice attacks on TLS implementations.
• Microarchitectural attacks (FLUSH+RELOAD, branch prediction).

4. Curve param confusion: applications confused which curve is in use.

• Invalid curve attacks: feed bad public key, do scalar mul on weak twist curve, recover d.

5. Signature malleability: (r, s) and (r, n-s) both verify. Bitcoin pre-SegWit suffered.

6. ECDSA cofactor attacks: not for cofactor-1 curves like secp256k1, but real for some.

Defenses:

• Use battle-tested libraries: libsecp256k1, OpenSSL, BoringSSL.
• Use deterministic nonces (RFC 6979).
• Constant-time scalar multiplication (Montgomery ladder).
• Input validation: confirm pubkey is on the curve, in the prime-order subgroup, not at infinity.

For new systems, prefer Ed25519 over ECDSA: deterministic by design, simpler, faster, no nonce concerns. ECDSA is widely deployed but error-prone.

Don't roll your own. Period. Even big companies got it wrong.