4 ms·
So, they solve the problem of having to ensure those issues are not present? Also, it's not exactly unheard of of "good" prngs having bugs making them bad.
by tjoff 9y ago
So, they solve the problem of having to ensure those issues are not present?
Also, it's not exactly unheard of of "good" prngs having bugs making them bad.
- tptacek 9y agoWhen's the last time a kernel CSPRNG in a mainstream operating system had an exploitable vulnerability? We hear about "good" CSPRNGs going "bad" all the time, but invariably these are instances of people adding new userland CSPRNGs to their systems as rubber chicken security measures that later blow up.
- tjoff 9y agoWell, we all know about Debian, there is also Windows XP. And we all hear about bad PRNGs - maybe all those issues can be explained with userland implementations. I don't know. My point is, I don't have to know the answer to any of those questions if I opt for a hardware random generator. Yes, I have to place trust in the hardware random generator instead. From a user perspective it seems like the attack surface (from the perspective of bad configuration, start seed, misuse etc.) is much smaller with a hardware generator. And, conceptually it sounds like a safer option. Is it? Well, we arrive at yet another "I don't know". Note, I'm not advocating the use of a hardware random generator at all, I'm merely responding to the statement that they don't solve any problem at all.
- tptacek 9y agoDebian was OpenSSL's RNG, not the kernel RNG. So, it sounds like your response is that we have to go all the way back to Windows XP to see an example of a "good" RNG going "bad".
- tjoff 9y agoMy bad, but sounds like your response is ignoring all but one of my points. Keep in mind that the issue was present in Windows 2000 yet remained undetected for 7 years after the release of Windows 2000.
- tptacek 9y agoNot only that, but the Windows CryptGenRandom bug you're referring to (1) affects an ancient userland implementation of the Windows RNG, and (2) is principally effective as a second-order attack when someone has compromised the entropy pool. And this is the best example we've thus far come up with for a "kernel CSPRNG going bad". I'm very comfortable with the validity of the argument I'm making, which is that we don't generally need to layer rube goldberg hardware onto our systems to hedge against the likelihood of the LRNG going bad.
- tjoff 9y agoSo, would you be equally comfortable with stating that a hardware random generator doesn't solve any problems related to boot time entropy and the use of insecure RNGs by mistake?
- tedunangst 9y agoHow does plugging this device into a broken Debian system fix it?
- tjoff 9y agoThe problem with the Debian issue was that of a bad seed to the RNG. And I'd argue that getting good seed values is one of the main things that is appealing with a hardware generator (especially at system boot). You'd still have to use it though.
- tptacek 9y agoNo, that's not the Debian problem. The Debian problem was that they literally ifdef'd out the RNG refresh code. And, again, Debian's problem was in their version of the OpenSSL userland RNG. Applications that simply relied on /dev/urandom rather than OpenSSL's janky mess weren't impacted by the bug at all.
- tjoff 9y ago"Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG." https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number...
- tptacek 9y agoWhat's your point? The OpenSSL CSPRNG is a userland RNG, not Debian's built-in RNG.
- loeg 9y agoDebian didn't break the kernel CSPRNG — they broke entropy seeding for OpenSSL. Debian could have unbroken OpenSSL seeding by reading from /dev/urandom.