We've released #PuTTY version 0.81. This is a SECURITY UPDATE, fixing a #vulnerability in ECDSA signing for #SSH.

If you've used a 521-bit ECDSA key (ecdsa-sha2-nistp521) with any previous version of PuTTY, consider it compromised! Generate a new key pair, and remove the old public key from authorized_keys files.

Other key types are not affected, even other sizes of ECDSA. In particular, Ed25519 is fine.

This vulnerability has id CVE-2024-31497. Full information is at https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-bias.html

PuTTY vulnerability vuln-p521-bias

@simontatham @indigoparadox If I understand from skimming the link, this solely affects PuTTY (on Windows) and /not/ other implementations of SSH, right?

@lispi314 @indigoparadox PuTTY on any platform, actually. PuTTY can run on Unix too, though it's less popular there. And its ECDSA signing code is the same wherever it's running.

Independent implementations such as OpenSSH aren't affected, that's correct.

@simontatham @lispi314 @indigoparadox Am I paranoid when I connect this vulnerability with the xz-backdoor? To get the private keys an attacker needs access to ssh-servers, which the xz-backdoor could have provided. So it's imaginable that the group behind the backdoor found the ecdsa-sha2-nistp521 problem and thought: "how make the most of it"?

@agitatra @lispi314 @indigoparadox interesting thought – hadn't occurred to me!

Off the top of my head I'd guess the number of P521 users is _relatively_ small. As another commenter pointed out, it's never been PuTTY's default; and generally the NIST curves seem to have mostly gone out of fashion these days, in favour of Ed25519.

So I doubt this was _all_ the xz backdoor actors were after. It doesn't seem worth all the effort by itself. But it could have been one thing on their shopping list.

@simontatham @lispi314 @indigoparadox "Let no private key behind"...