On Tuesday 26 Jul 2011 15:01:33 Marcus Meissner wrote:
On Tue, Jul 26, 2011 at 09:35:33AM -0400, Jeff Mahoney wrote:
On 07/26/2011 08:34 AM, Marcus Meissner wrote:
Hi,
The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.
We reviewed haveged for SLE 11, from a integrity security side it is ok.
We reviewed the randomness it generates briefly (!) and found no issues.
However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.
It insanity rating is similar to using /dev/urandom, refering to a previous comment.
That said, we are fine with enabling it if people consider it necessary.
Hrm, if the quality is indistinguishable from /dev/urandom, why wouldn't we just pump from /dev/urandom when /dev/random runs out?
I just wanted to point out that it is hard to differ real entropy and pseudo randomness.
haveged claims to derive randomness from timer fluctuations in calculations and cache timings and cache flushings, and we used timer based randomness when feeding from network cards and human input devices.
As long as the CPUs don't have predictable timings in the used calculations currently haveged can be used for "real" entropy.
Ciao, Marcus
If you find it "too good to be true" then here's a very simple experiment you can do to demonstrate exactly how big of a difference there is between pseudo- random and actually (or indeterminable from random) data there is. 1) remove/disable all sources of entropy as best as you possibly can 2) dd if=/dev/random of=/dev/null obs=16 3) watch /proc/sys/kernel/random/entropy_avail until available entropy drops to around the 100 mark. 4) dd if=/dev/urandom of=/dev/random - we are now dumping pseudo-random data directly into the kernel's RNG entropy pool. 5) observe how it fails to make absolutely any difference to entropy_avail You can thus rest assured that the microtime a CPU takes to perform x number of loops will never be the same ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org