From the Tales From The Crypto blog comes a new perspective on the Debian OpenSSL bug that I'm surprised I hadn't seen before. (This is a fun blog and I highly recommend it. And yes, I'm ripping off his use of the image below.)

As Debian revealed in their disclosure, the bug was created because they removed a line of code based on a warning from the Purify tool that the code, part of the random number generator, was using uninitialized data.

Of course, this was part of the seed for the generator, and the fact that the data was uninitialized was part of its randomness. In fact, OpenSSL developers had dealt with this issue years before and decided that uninitialized data in this case was a virtue, not a vice. So when they removed the line of code they left the process ID as the only random factor, and it was limited to a 32K range.

Alun Jones, the blogger, them asks the obvious question that I should have asked before, namely why they would leave two weak factors as the random number seed? Actually, it seems that this is how the code works in the absence of an outside randomness source. I thought all you needed for that was a system clock and you mod off the fractions of a second and use that as the seed. Could it be that's not always available?

Jones concludes by saying that these are some of the reasons why he likes the Microsoft Crypto API, and he's got some good points. When a problem is found and Microsoft updates it through Windows Update everyone gets the fix, or at least it's easily available. It's a well-implemented API and pretty well documented as opposed, he says, to OpenSSL.