( buga | 2024. 04. 17., sze – 23:21 )

Úgy értelmeztem a leírást a PuTTY vulnerability vuln-p521-bias (greenend.org.uk) oldalon leírtak alapján, hogy alapjában véve itt is a kulcs véletlenszerűségével van a gond, akárcsak a 2008-as debianos incidensnél.  Előfordulhat, hogy valamilyen lényegi különbség miatt (például túl sok van belőle) itt nem előállítható ilyen lista és a key blacklisting nem opció.  A kriptós/matekos hátterem nincs meg a lentiek alapos értelmezéséhez, ezért fogalmaztam óvatosan.
 

This means that it's dangerous to generate DSA signatures on systems with no high-quality source of randomness. Significantly more dangerous than generating the encryption keys for a single session: a leak of the private key compromises far more than one SSH session.

For this reason, since PuTTY was developed on Windows before it had any cryptographic random number generator at all, PuTTY has always generated its k using a deterministic method, avoiding the need for random numbers at all. The clever trick is to compute a secure hash whose input includes the message to be signed and also the private key. Secure hash output is indistinguishable from random data (or else the hash function isn't doing its job), and this generation method can't be repeated by an attacker who's trying to find out the private key – if they could generate the same hash input as you, they'd already have the private key.

This technique is now mainstream, and RFC 6979 documents a specific well-known way of doing it. But PuTTY didn't follow that specification, because we started doing the same thing in 2001, and the RFC wasn't published until 2013.

PuTTY's technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY's technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.

In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.

This bias is sufficient to allow a key recovery attack.