We found it by investigating the security of SSH as part of a larger research program focussing on SSH, which also resulted in our publication of the Terrapin vulnerability.

This particular bug basically fell into our hands while staring at the source code during our investigation of the security of SSH client signatures.

Public money very well spent...

Thank you, we all need more of that.

Ironically, DJB considers the 521 curve to be the only NIST standard that uses reasonable primes.

"To be fair I should mention that there's one standard NIST curve using a nice prime, namely 2^521 - 1; but the sheer size of this prime makes it much slower than NIST P-256."

http://blog.cr.yp.to/20140323-ecdsa.html

http://safecurves.cr.yp.to/rigid.html

The 521 curve is the only one using a Mersenne prime, which has significant advantages when you do calculations, but also feels less arbitrary.

This vulnerability has very little to do with P-521 per se. The issue is with ECDSA: any use of ECDSA with biased nonce generation, regardless of the elliptic curve it's implemented over, immediately causes secret key leakage.

(Rant: All these years later, we're all still doing penance for the fact that Schnorr signatures were patented and so everyone used ECDSA instead. It's an absolute garbage fire of a signature scheme and should be abandoned yesterday for many reasons, e.g., no real proof of security, terrible footguns like this.)

Schnorr wouldn't have helped in this specific case, since Schnorr is equally vulnerable to biased nonces (https://ecc2017.cs.ru.nl/slides/ecc2017-tibouchi.pdf).

EdDSA, which is essentially deterministic Schnorr, does solve the problem.

Also, the use of P-521 didn't specifically cause the vulnerability, but the bad interaction between SHA512 and P-521 did play a role. It is unfortunate that nature conspired against us to make 2^511 - 1 a composite number. The fact that you have to go up to 521 bits to get a Mersenne prime whereas the natural target length for a hash output is 512 bits is the fatal interaction here.

Excellent points all around, and thank you for the pointer to the ECC slides :)

(And indeed, nature could have been kinder to us and given us a Mersenne between 127 and 521...)

Shouldn't there be another close enough prime? Like 2^510-1 or 2^511-19?

I’m over here wondering why someone would want deterministic nonces.

Isn’t it kind of the point to just roll random numbers? When would you calculate?

It says in the OP. Windows at the time did not provide a cryptographic quality random number source.

I saw that, and wondered why PuTTY didn't contain it's own good CSPRNG, something like Fortuna, if Windows didn't offer one.

You still need a source of entropy, which is easier for an OS. An app has to resort to the user moving the mouse or bashing keys, which is a worse UX, although I guess they did that for actual key generation (if PuTTY did that) but it would be annoying to do it every time you made a connection.

> Schnorr signatures

Never heard of (which probably demonstrates that I know pretty much nothing about cryptography?), so seeing a name spelled like "Schn...r" in this context makes at least me think of an entirely different luminary in the area. Thought it was a typo at first.

Assuming I'm reading it right, this is an absolutely classic vulnerability, something people who study cryptographic vulnerability research would instinctually check for, so what's taken so long is probably for anyone to bother evaluating the P-521 implementation in PuTTY.

Correct. Every time I've seen P-521 in a professional setting, it is the very first thing I check for.

How often do people get it wrong? It doesn't seem particularly difficult to generate 521 random bits.

This is the first time it's ever actually happened. I'm just painfully aware of missing developer ergonomics and ways to shoot oneself in the foot.

It was found a bunch a decade or so ago. PuTTY is just a more obscure codebase.

Sorry, I should've been clearer: all the times I've checked for this specific bug, I did not find it in the code I was looking at. All the times I looked for it was the series of events I was reflecting on.

That's what I meant by "the first time it's happened". I shouldn't write comments before my first cup of coffee.

The classic FOSS tragedy of the commons: we'd all benefit from an in-depth security review of the PuTTY codebase, but no one will fund it.

You should be using pageant to store the secret ssh keys, and you only need to unlock the key on reboot/first use.

Windows has a built in ssh-agent included with openssh, no need for pagent anymore.

Ssh agent will manage your ssh keys through windows registry windows login process.

Also if you use wsl, you can access your ssh keys in wsl from the windows ssh-agent via npiperelay

You don't even need a relay to use the windows SSH agent from wsl. Simply use ssh.exe instead of /bin/ssh. I've been doing that for a while (I make a symlink in a folder from my PATH that gets picked up before /bin) and haven't encountered any issues so far.

Good to know, I had an issue when I tried that, but thinking back it was a ssh version incompatibility between the default windows and ubuntu.

Or just use a hardware key and enable touch to sign so you have to touch it for every action even when it's unlocked

100% agreed.

For me, the stakes are very low. It's my windows "gaming" machine, and has access to a few low-value hosts.

Otherwise I'd invest the time to learn wtf is pageant ;D

If the hosts are under your control, and never connect to untrusted hosts, then you are ok. The user authentication is encrypted, so the signatures are not visible to a man in the middle.

Pageant is `ssh-agent`.

How are public keys a pain in the ass?

Windows 10+ now have openssh proper by Microsoft. No need to use putty with it's own custom key format among other nonsense.

This entire comment thread hurts my soul.