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.
Detection and response playbook
CVE-2024-31421 is a cryptographer’s bug with an operator’s consequences: any observer who collects roughly 71 signatures from a P-521 key can recover the private key. Because the signatures were usually public — SSH handshakes, Git commit signatures — the exposure window is everything you have ever signed. The response playbook is therefore about measurement, not containment speed.
- Count your signatures immediately. For every P-521 ECDSA key: how many handshakes has it produced, and were the ephemeral portions observable? Keys used for interactive SSH to internet-facing hosts are past the threshold; keys used inside a trusted bastion mesh may not be. The number determines priority, and most teams find their worst offenders within an hour of asking.
- Rotate keys, then hunt for persistence. Generate replacements on patched PuTTY (0.81+) or switch to Ed25519, which has no nonce-bias failure mode of this class. Rotation is the easy half: assume the old key was recoverable by anyone who archived your traffic, and inspect hosts in the trust chain for planted authorized_keys entries added during the exposure window.
- Treat passive archives as adversaries. The signature collection does not require interacting with you. Anyone who logged your SSH banner exchanges — ISPs, honeypots, nation-state taps — holds the raw material. This is why “we saw no exploitation” is meaningless for this CVE: key recovery leaves no log entry on your side.
- Fix the generation-side habit. The bias came from PuTTY’s deterministic nonce construction (prefixed SHA-512 with a fixed 64-byte truncation), not from randomness failure. The implementer lesson: bias in deterministic nonces is as fatal as nonce reuse. Prefer vetted libraries and RFC 6979-style constructions over hand-rolled determinism.
- Instrument the exposure class, not this CVE. Add key-type inventory to your vulnerability program: which algorithms, which clients, which versions. The next nonce-class bug will not announce itself with a nice round number like 71.
The reason this bug terrifies implementers elsewhere: the attack is pure offline mathematics against public data. Every control that assumes an attacker must interact with you to hurt you — rate limiting, lockouts, monitoring — is inapplicable. Defense here is patch velocity, key hygiene, and algorithm choice, full stop.
Where this sits in the broader pattern
Nonce-class failures have a distinguished, painful history. The PuTTY bias is a direct descendant of the PlayStation 3 ECDSA blunder of 2010 (repeated nonces) and the Bitcoin wallet losses of 2013, and a sibling of the JWT-ECDSA issues that surfaced across the ecosystem in the same years. The family resemblance: deterministic or weakly-random nonce construction, implemented per-project instead of using a vetted RFC 6979 library, producing signatures that individually look perfect and collectively leak the key.
The observation-cost asymmetry is what makes this class brutal. A typical vulnerability requires an attacker to send you traffic you might log; a nonce bias requires only that someone archive your public signatures — which every passive collector on the internet already does. Post-Snowden traffic-archival assumptions mean the exposure window is since the key was first used, not since exploitation was observed.
The industry response worth watching is algorithm migration: Ed25519’s design eliminates this entire failure mode — the nonce is derived deterministically from the key and message hash, with no bias-sensitive truncation — which is why every modern SSH hardening guide lists it first. For teams still running large ECDSA P-521 estates from legacy client versions, the xz backdoor postmortem offers the adjacent lesson: the most dangerous supply-chain components are the boring ones nobody has audited in a decade, including the SSH client your engineers run daily.
The bottom line. Seventy-one signatures is all it took — not because the cryptography was weak, but because the implementation was human. The key you never rotate, on the client nobody audits, signing the traffic everyone records: that is the exposure formula this CVE made undeniable. Audit your key estate for algorithm and client version today, migrate what you can to Ed25519, and put signature-surface inventory on the same annual cadence as your external attack-surface scan. Mathematics does not negotiate with patch schedules, but it respects the ones that exist.
Frequently Asked Questions
.aiopt-faq-block{border:1px solid var(–aio-border,#e2e8f0);border-radius:8px;overflow:hidden}
.aiopt-faq-item{border-bottom:1px solid var(–aio-border,#e2e8f0)}.aiopt-faq-item:last-child{border-bottom:none}
.aiopt-faq-question{width:100%;text-align:left;padding:16px 20px;background:none;border:none;cursor:pointer;display:flex;justify-content:space-between;align-items:center;font-size:16px;font-weight:600;color:#1e293b;gap:12px}
.aiopt-faq-question:hover{background:#f8fafc}
.aiopt-faq-icon{font-size:20px;transition:transform .2s;flex-shrink:0;color:#6366f1}
.aiopt-faq-open .aiopt-faq-icon{transform:rotate(45deg)}
.aiopt-faq-answer{max-height:0;overflow:hidden;transition:max-height .3s ease}
.aiopt-faq-open .aiopt-faq-answer{max-height:1000px}
.aiopt-faq-answer-inner{padding:0 20px 16px;color:#475569;line-height:1.7;font-size:15px}
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “What is CVE-2024-31421 in PuTTY?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “A nonce-generation bias in PuTTY’s ECDSA signature code (fixed in 0.81). With about 71 observed signatures from a P-521 key, an attacker can mathematically recover the private key u2014 without ever touching your systems.”
}
},
{
“@type”: “Question”,
“name”: “Was my SSH key exposed if I used affected PuTTY versions?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “If you used ECDSA P-521 keys with PuTTY 0.68u20130.80 for SSH authentication or Pageant signing, treat the key as recoverable by anyone who recorded your signatures u2014 including passive network observers u2014 and rotate it.”
}
},
{
“@type”: “Question”,
“name”: “Which key type should I use instead of ECDSA P-521?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Ed25519 is the practical replacement: fast, compact, and immune to this nonce-bias class of failure. RSA-3072 also works where Ed25519 is unsupported.”
}
}
]
}
Related Reading
- What Studying 33 Historic Cyberattacks Taught Me About Defending Systems Today
- Passwordless in 2026: Why Passkeys Are Finally Killing the Password (and How Attackers Are Adapting)
- 2022–2024: Lapsus$, Change Healthcare & the XZ Backdoor
- Authoritative reference: CISA Known Exploited Vulnerabilities
- CurveBall CVE-2020-0601: Forging Trust With One Elliptic Curve Paramet
- MSI’s BootGuard Key Leak: Hardware Trust on the Market
- NIST’s PQC Standards: FIPS 203-205 and the Migration Clock
