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.
@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"?
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.
@jalcine no, 521 is right! NIST elliptic curve keys come in three fixed sizes, and one of them isn't the obvious power of 2.
In fact, the difference between 521 and 512 is exactly the cause of the problem – those 9 extra bits are the amount of information that PuTTY was accidentally leaking about the private key per signature.
@simontatham Hi and thanks for the quick bugfix. From what I know, ecdsa-sha2-nistp521 has never been the default key type in Puttygen, so "normal" keys (mostly ssh-rsa and ssh-ed25519) should be fine?
Add comment