[Gnuk-users] Security of NeuG?

[Jonathan Schleifer]

Am 16.02.2015 um 20:59 schrieb micah <micah at riseup.net>:

> My understanding of haveged's functionality is that if havged wakes up
> and finds the kernel pool needs to be filled it will dominate the pool
> and fill it ALL itself. It will usually be the one that wakes up first,
> because it will get the kernel call faster (because rngd has its own
> loop).
> 
> Haveged does this: 1. gets the current pool size; 2. writes the
> remaining random data to the pool in a single ioctl.
> 
> The way rngd works is it is careful about dominating the pool by having
> a random step function to fill it. This means that haveged dominates and
> results in zero mixing because when rngd wakes up, it sees that the pool
> is filled and doesn't have to do anything.

Yes, this is exactly what I feared. Thus I killed haveged and drained the pool to make sure I get some randomness from the NeuG.

> Someone with some C knowledge could do us all a favor and make haveged
> use a step function to make it more safe!

Actually, I'd rather see a security audit of it. It does a *lot* of questionable things, yet is imported into most distributions. As there's no analysis, it's hard to convince distros that it should not be shipped with the default settings. For starters, the fact that it happily generates megabytes of randomness when it has no entropy scares me (rdtsc returning 0 is something haveged seems to consider perfectly fine). It just passes what ever entropy it does have or doesn't have into a PRNG and then only verifies the output of *that*. Which *obviously* will always pass all statistical tests, even when initialized with all zeros. I don't even think feeding the output from a PRNG into the kernel is the right thing to do, it would be much more useful if it would gather entropy, do some statistical tests on THAT and then feed that entropy into the kernel and let the kernel do the PRNG part.

--
Jonathan