News for hackers. Stuff that matters.
Re:PuTTY vulnerability vuln-p521-bias by chasil on Monday April 15, 2024 @04:23PM (#40045129)
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

Re:PuTTY vulnerability vuln-p521-bias by pclmulqdq on Monday April 15, 2024 @04:43PM (#40045320)
The 521 curve is the only one using a Mersenne prime, which has significant advantages when you do calculations, but also feels less arbitrary.
Re:PuTTY vulnerability vuln-p521-bias by kwantam on Monday April 15, 2024 @06:11PM (#40046277)
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.)

Re:PuTTY vulnerability vuln-p521-bias by djao on Monday April 15, 2024 @10:43PM (#40047887)
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.

Re:PuTTY vulnerability vuln-p521-bias by kwantam on Tuesday April 16, 2024 @12:17AM (#40048301)
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...)

Re:PuTTY vulnerability vuln-p521-bias by GoblinSlayer on Tuesday April 16, 2024 @05:19AM (#40049937)
Shouldn't there be another close enough prime? Like 2^510-1 or 2^511-19?
Re:PuTTY vulnerability vuln-p521-bias by SV_BubbleTime on Tuesday April 16, 2024 @01:53AM (#40048758)
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?

Re:PuTTY vulnerability vuln-p521-bias by ajb on Tuesday April 16, 2024 @03:38AM (#40049329)
It says in the OP. Windows at the time did not provide a cryptographic quality random number source.
Re:PuTTY vulnerability vuln-p521-bias by denton-scratch on Tuesday April 16, 2024 @05:31AM (#40050004)
I saw that, and wondered why PuTTY didn't contain it's own good CSPRNG, something like Fortuna, if Windows didn't offer one.
Re:PuTTY vulnerability vuln-p521-bias by ajb on Tuesday April 16, 2024 @05:42AM (#40050074)
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.
Re:PuTTY vulnerability vuln-p521-bias by CRConrad on Tuesday April 16, 2024 @04:40AM (#40049680)
> 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.