Re: [gentoo-hardened] Bought an "entropy-key" - very happy

[Ed W <lists@wildgooses.com>]

On 23/03/2010 21:02, lists@m8y.org wrote:
> On Tue, 23 Mar 2010, Ed W wrote:
>
>> OK, so to conclude the previous thread - I bought an entropy key from 
>> the nice folks at Simtec via http://entropykey.co.uk
>>
>> Short version is you plug it in, install the ekeyd package and even 
>> on a hardened installation the entropy pool never deviates from full 
>> up...
>>
>> Now, at £30 it seems like a bargain for a fancy random number 
>> generator, but then I read that the daemon can be switched to pipe 
>> the data out in "egd" format and essentially you can have one machine 
>> supply high volumes of random numbers for a fair number of networked 
>> clients.  In my case this solves the problem of how to pipe entropy 
>> to some cheap rented servers where we don't get to touch the physical 
>> hardware...  Very nice
>>
>> I have no relationship with the entropy-key guys other than being a 
>> happy customer.  They seem like a small shop and I think they deserve 
>> a plug (and really need to work on their presence via google... 
>> Searches on this stuff only turn up $400 alternatives... Sheesh)
>
> I'm a bit puzzled how that offers much security.
> Is the advantage that the algorithm for PRNG has to be extracted from 
> the chip inside the key before it can be abused?
>
> Seems no better than, say:
> http://www.debian-administration.org/users/dkg/weblog/56
>
> Apart from at least adding a bit more layers in the algorithm.

I'm not sure what you mean by the link referenced above?  The point is 
that once the entropy pool is depleted on Linux then operations against 
/dev/random will stall, however, the evolution on linux has been that 
since /dev/random is "unreliable" most apps now seem to go directly to 
/dev/urandom which is similar, but doesn't block once the entropy pool 
is empty (simply the quality of random numbers declines) - however, it's 
reverting to a pseudo random number algorithm

I have experimented with most of the other entropy gathering options 
that you can hit with a quick google search, but at least on some of my 
machines these added non-trivial amounts of CPU load and usually for not 
much extra entropy (timer_entropyd was the best for me)

I'm not a total tin hat - it's more that in the case of glibc and kernel 
both compiled with SSP, plus a load of virtual machines (lots of 
processes running on a small machine) I could see that my entropy pool 
is getting zapped to zero in just seconds.  Hence there is clearly a 
dubiously small amount of randomness left and basically we are working 
the pseudo random device quite hard

The entropy key just compensates by adding another fairly high quality 
source of randomness - the kernel will incorporate this extra randomness 
with what it gets from other sources, so even in the event that the 
device is fatally flawed then "probably" you still won't let an attacker 
figure out all your ssh keys.  The ekey is not simply a software 
algorithm, but uses an internal "noise generator" to produce it's randomness

Given you can run a bunch of machines from one device it seemed like a 
very simple solution to the situation

Good luck

Ed W