Why is the pid used for this at all? There is practically no entropy
in it, so the effect of using it is to hide deficiencies in the proper
entropy sources.
Posted May 16, 2008 19:58 UTC (Fri) by johnkarp (guest, #39285)
[Link]
My impression is that there is rarely any single good source of entropy,
so it must be scrounged up from as many minor sources as possible...
hardware interrupt timings, mouse movements, etc. The PID probably only
adds a bit or two, but every bit helps.
Impact of the Debian OpenSSL vulnerability
Posted May 16, 2008 21:08 UTC (Fri) by bronson (subscriber, #4806)
[Link]
A PID offers so little additional entropy that it's basically worthless. Still, it can't hurt
to include it, right?
Dunno about thiat... If the PID weren't mixed into the randomness, this vulnerability would
have been found within days if nothours. The slight additional complexity of mixing the PID
in managed to hide a massive security problem for two years.
So, if /dev/random is good enough, perhaps mixing in a tiny amount more entropy ends up being
more harmful than helpful. It seems to have been in this case.
Impact of the Debian OpenSSL vulnerability
Posted May 17, 2008 15:18 UTC (Sat) by ikm (subscriber, #493)
[Link]
I'd say just not mess with the others' sources lightly. Some people like to come and say oh
here, what the hell is this? Let's just cut it out! A story about a girl who tried to treat
her hamster for a "pimple" he had spurs to my mind.
Impact of the Debian OpenSSL vulnerability
Posted May 18, 2008 6:49 UTC (Sun) by muwlgr (guest, #35359)
[Link]
gettimeofday gives you more entropy than getpid.
One could add contents of some /proc files to the mix (like: interrupts, meminfo, vmstat,
diskstats, ...).
No need to read unitialized data at all.
Impact of the Debian OpenSSL vulnerability
Posted May 19, 2008 4:17 UTC (Mon) by gdt (subscriber, #6284)
[Link]
gettimeofday gives you more entropy than getpid.
Many certificates have an expiry date typically some whole years after generation. In those cases, gettimeofday() does not add entropy which cannot be calculated by an attacker.
Entropy for key generation has to be random, unpredictable and not influenced by external events. That's harder to find then you would hope, which is why even a kernel-based entropy collector doesn't produce much of it.
Using /proc/interrupts would not meet that requirement. At the least you would need to exclude interrupts from the network card (externally influenced) and from the quantum timer (predictable). Even then the attacker knows the value is monotonically increasing. The time of arrival of selected interrupts is a better source of entropy. But if you imagine the attacker holds an account on the same multiuser machine even that isn't too unpredictable.
In short, this is a problem which looks easy on the surface but is a nightmare when closely examined.