What happened?
On 16 April 2024, PuTTY maintainers disclosed CVE-2024-31497 — a nonce bias in the terminal’s ECDSA signature implementation that made private keys recoverable from roughly 71 observed signatures. Not 71 million. Seventy-one. Anyone who had used PuTTY’s Pageant to SSH with an NIST P-521 key, and whose connections could be passively logged — a corporate DLP box, a malicious exit node, a tapped wire — had effectively published their key one handshake at a time.
Quick Answer: CVE-2024-31497 meant PuTTY’s ECDSA nonces were biased (generated by clearing ~9 bits of the P-521 nonce), so ~71 recorded SSH signatures let an attacker lattice-attack the private key; fix was 0.81 — and every affected key, once used enough times, was burned and required rotation.
The mathematics was the story. ECDSA security hinges on the nonce — the one-time random value per signature — being unrecoverably secret and uniform. PuTTY generated nonces deterministically from the key plus a counter, then cleared the top bits to guarantee a valid range: each nonce thus leaked a few bits of structure. HNP — the Hidden Number Problem — turns a handful of biased signatures into a lattice-reduction exercise, and with P-521’s parameters the researchers showed the 71-signature threshold. Passive capture plus patience equaled key theft, no memory corruption needed.
Why 71 signatures is a terrifyingly small number
A busy automation host authenticates dozens of times an hour. Git pipelines, cron rsync jobs, CI runners using Pageant — any P-521 client credential produced signatures at a rate that hit the threshold in a single workday. Worse, the attacker did not need to be in-path in real time: full-session PCAPs, lawful-intercept archives, or threat-actor hoards of captured traffic all contained sufficient material. The 2024 disclosure retroactively weaponized years of stored traffic.
| Date | Event |
|---|---|
| ≤2024-03 | Bias discoverers (Strand, Venema, Boverhof) report; keys used after exposure considered compromised |
| 2024-04-15 | PuTTY 0.81 ships with per-signature deterministic nonces RFC 6979-style generation |
| 2024-04-16 | CVE-2024-31497 published; guidance: rotate any P-521 key that ever signed via PuTTY<0.81 |
| 2024-04-20→ | Scanning shows flipped keys re-trusted in some orgs before CRL/known_hosts hygiene catches up |
| 2024-05 | Follow-ons: audit guidance for archived traffic; community discussions about P-521 versus Ed25519 defaults |
The DLP archive problem nobody scoped
The scariestaudit finding of April 2024 was organizational, not cryptographic: session-recording infrastructure — DLP, PAM session capture, compliance PCAP stores — had faithfully preserved years of biased signatures. Security teams found themselves holding the very corpus an attacker would need, and had to decide: does retention of captured handshakes now constitute retention of private-key material? Few policies had an answer. The mature ones added signature-bearing captures to key-rotation trigger criteria and hashed or expired old session archives.
Why the remediation nobody enjoyed
Patching the client was the easy half. The hard half: every ECDSA-P-521 key that had ever been used through PuTTY was presumptively burned — rotation meant new keys, new authorizations, and the awkward question of where those keys had been accepted (bastion hosts, embedded devices, vendor SFTP endpoints that required key re-registration tickets). Organizations with strong key inventories spent a week on this; organizations without spent a quarter discovering their key sprawl the hard way.
- Detect: inventory PuTTY/Pageant usage and any P-521 ECDSA host/client keys — configuration management plus endpoint querying.
- Rotate: generate replacements (Ed25519 or RSA-4096 per new guidance), re-deploy, revoke old authorizations explicitly.
- Assess: if old traffic may have been logged by parties you distrust, treat the key as adversary-held and hunt for its use.
- Prevent: prefer deterministic-nonce implementations, and add signature-count monitoring to long-lived automation credentials.
FAQ
Did this affect Ed25519 or RSA keys in PuTTY?
No — the flaw was specific to ECDSA over P-521 as implemented by PuTTY. Ed25519 (which uses deterministic nonces by design and a different curve) and RSA (no nonce concept) were untouched. The clean lesson many teams took: prefer Ed25519 for new automation keys, partly because its design forecloses this entire bug class.
Was there evidence of in-the-wild key recovery?
No public incidents of exploited recovery emerged in the window — but the attack requires only passive capture, so absence of evidence is weak comfort. The maintainers’ guidance was explicit: any P-521 key used through PuTTY before 0.81 must be rotated, full stop, because by the time you learn otherwise it is already too late.
Why not just clear the bottom bits instead of the top?
Either end leaks structure; the real fix was abandoning biased generation entirely. PuTTY 0.81 moved to a deterministic scheme (RFC 6979-style) where the nonce derives cryptographically from the message and key, eliminating both RNG failure modes and range-clamping bias. That is also the standard answer across modern ECDSA implementations.
What HNP means for defenders
The Hidden Number Problem framing matters because it prices the attack: with each leaked nonce bit, required sample counts drop multiplicatively, and lattice tooling (LLL/BKZ) runs on commodity hardware. Defenders should therefore treat any implementation flagged for nonce bias as immediately key-burning rather than watch-and-wait — the math only gets cheaper. It also explains vendor urgency language: there is no partial exposure with signature bias, only counted-down compromise.
The schema lesson for implementers everywhere
The PuTTY bug joined a lineage — Sony 2010, Android wallets 2013 — of ECDSA implementations where “fixing” one property (valid range) introduced catastrophic bias. For every maintainer of signature code, April 2024’s takeaway was procedural rather than mathematical: never hand-roll nonce generation; library-level deterministic nonces or well-vetted RFC 6979 implementations, and third-party cryptanalysis of your curve arithmetic before shipping — because the attack side needs only 71 samples and a laptop.
