Recently, the Debian project made a formal security announcement about a vulnerability in the code used to generate SSH keys. At first I read it with some interest (I’ve been using Debian and debian-based systems for quite some time now) but not too much concern.
In seeing the topic come up around the internet, I even saw the response from some openssh people, and chuckled a little bit inside, taking it as some kindof programming lesson to be applied to futuer situations I might encounter.
That was until I read a more dramatic exposé of the problem:
Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG. Instead of mixing in random data for the initial seed, the only “random” value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.
That basically means a lifetime maximum of 32k ssh private keys for all debian-based systems from 2006-09-17 until 2008-05-13 … around 600 days, or 55 keys generated per day before a collision is (kindof) guaranteed.
That immediately caused me to look up my key and luckily I learned about (and generated my) SSH private keys prior to 2006.
The response is interesting: blacklist the known 32k keys * a variety of keylengths. Probably the best possible mitigation strategy given the circumstances.
Lesson learned? Really seek out and respect a professional opinion when it comes to crypto that you care about.