In his blog Glen writes on the Debian OpenSSL stuffup:
Hopefully this fiasco will re-energise hardware manufacturers into providing hardware-based randomn number generation. The current scavenging across the operating system for any source of entropy isn’t acceptable and is one of the root causes of this current flaw.
But this wouldn’t have helped in this situation as OpenSSL already supported those sources but the patch ((which was posted to the openssl-dev list for comments prior to being applied, well worth a read as it’s a short thread )) effectively removed the call to add those (and all other) sources of entropy into the pool, leaving just the PID – hence 32,768 possible keys.. 🙁
If you’re an LWN subscriber (and if you’re not, you should be!) this article is well worth a read (it’ll become accessible to non-subscribers on Thursday, Australian time)..
Hi Chris,
My point was that the reason the code even existed in the form that it did (using uninitialised memory and all) was to scavenge for entropy.
Sure the maintainer correctly patched it and incorrectly patched the similar-looking code as well.
But the maintainer would never have approached the code if it were cleaner, and it wasn’t cleaner because “all sperm^H^H entropy sources are sacred”.
I probably should have made the argument more fully in my blog entry. I was aiming more for a note than an essay, and I’m not sure that my approach worked.
Best wishes, Glen
[ LWN subscriber 🙂 ]
Hi Glen!
Gotcha – I thought you were saying that having HW random number generators would solve people writing bad code.
cheers!
Chris
PS: The LWN bit was aimed at the general public, not you! 🙂