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

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

[Ed W]

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)

Ed W

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

[lists]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1383 bytes --]

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.

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

[Rob Kendrick]

> > > 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?

There is no PRNG inside the key.  It's a hardware true random number
generator.  What makes the Entropy Key different from most other
plug-in entropy devices is that it goes to extraordinary lengths to
make sure the entropy that is injected into your pool can't be sniffed
before it gets there, as well as running loads of statistics to make
sure the device itself isn't being attacked.

(Disclaimer: I /do/ have a relationship with the entropy key guys.)

B.

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

[pageexec]

On 25 Mar 2010 at 13:10, Rob Kendrick wrote:

> it goes to extraordinary lengths to make sure the entropy that is
> injected into your pool can't be sniffed before it gets there, 

out of curiosity, what's that mean exactly?

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

[Rob Kendrick]

On Thu, 25 Mar 2010 19:50:23 +0200
pageexec@freemail.hu wrote:

> > it goes to extraordinary lengths to make sure the entropy that is
> > injected into your pool can't be sniffed before it gets there,   
> 
> out of curiosity, what's that mean exactly?

That somebody with a few probes and a 50 quid USB logic analyser can't
capture the entropy that was delivered to the system.  (One of the
target markets is installation in shared co-location facilities.)

B.

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

[pageexec]

On 25 Mar 2010 at 20:12, Rob Kendrick wrote:

> On Thu, 25 Mar 2010 19:50:23 +0200
> pageexec@freemail.hu wrote:
> 
> > > it goes to extraordinary lengths to make sure the entropy that is
> > > injected into your pool can't be sniffed before it gets there,   
> > 
> > out of curiosity, what's that mean exactly?
> 
> That somebody with a few probes and a 50 quid USB logic analyser can't
> capture the entropy that was delivered to the system.  (One of the
> target markets is installation in shared co-location facilities.)

do they also protect against impersonation? from your other answers
i infer that there's some (mutual?) authentication between the device
and the kernel, so it should be possible ;).

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

[Ed W]

On 25/03/2010 19:38, pageexec@freemail.hu wrote:
>
>> That somebody with a few probes and a 50 quid USB logic analyser can't
>> capture the entropy that was delivered to the system.  (One of the
>> target markets is installation in shared co-location facilities.)
>>      
> do they also protect against impersonation? from your other answers
> i infer that there's some (mutual?) authentication between the device
> and the kernel, so it should be possible ;).
>
>
>    

That's what it says here:
     http://www.entropykey.co.uk/tech/

It certainly needs an encryption key on the userspace daemon bit, which 
unless the person coding is very silly, usually implies that the PC is 
defended against impersonation

It seems way overkill for what I wanted, but the end result is that it 
does seem to be a very well thought out device, even more so considering 
all the other hardware devices I found through google are in the 400 
euro area (and at least two I looked at were thunking great big 
bricks...).  This thing is well inside my toy buying threshold...

Ed W

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

[Rob Kendrick]

On Thu, 25 Mar 2010 21:38:20 +0200
pageexec@freemail.hu wrote:

> > That somebody with a few probes and a 50 quid USB logic analyser
> > can't capture the entropy that was delivered to the system.  (One
> > of the target markets is installation in shared co-location
> > facilities.)  
> 
> do they also protect against impersonation? from your other answers
> i infer that there's some (mutual?) authentication between the device
> and the kernel, so it should be possible ;).

Yes.  There's a shared secret printed on a security card in the box
that in written into some one-time-programmable memory in the device.
You then use this key to generate another key, which is then stored on
the machine, and used to generate session keys.  (ie, the master key on
the security card is never stored on the machine, so even if your
machine is compromised, you can still use the device safely elsewhere.)

B.

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

[Ed W]

On 25/03/2010 17:50, pageexec@freemail.hu wrote:
> On 25 Mar 2010 at 13:10, Rob Kendrick wrote:
>
>    
>> it goes to extraordinary lengths to make sure the entropy that is
>> injected into your pool can't be sniffed before it gets there,
>>      
> out of curiosity, what's that mean exactly?
>
>    

I believe that the random numbers are encrypted out of the device?  I 
say that because when you start up the userspace daemon you tell it a 
long random number supplied with the device.  I assume this is designed 
to make sure that some local process can't sniff the entropy (over the 
USB bus, or whatever) before it's added to the kernel pool?

Although this seems like a basic feature for an entropy source, it 
wasn't particularly a feature I was looking for.  From my point of view 
it just seemed like a cheap plentiful entropy source which works pretty 
much out of the box just by plugging in...

Cheers

Ed W

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

[Rob Kendrick]

On Thu, 25 Mar 2010 20:17:12 +0000
Ed W <lists@wildgooses.com> wrote:

> > out of curiosity, what's that mean exactly?
> >
> I believe that the random numbers are encrypted out of the device?  I 
> say that because when you start up the userspace daemon you tell it a 
> long random number supplied with the device.  I assume this is
> designed to make sure that some local process can't sniff the entropy
> (over the USB bus, or whatever) before it's added to the kernel pool?

Pretty much.  It is worth noting that the entropy is decrypted before
being added to the pool; it's not just a whitening scheme.

(Rootly processes can, of course, pretty much know whatever they want
to.  The encryption and hand shaking is there to prevent physical
access to the outside of the case being as much of an issue.)

B.

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

[Ed W]

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

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

[lists]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2313 bytes --]

On Thu, 25 Mar 2010, Ed W wrote:

> 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

Right, he simply turned /dev/random into /dev/urandom.
I was under the impression the entropy key was simply a fancy PRNG.  Now that I know it offers
true randomness, I'm more impressed. Also curious exactly what it uses as a source.

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

[Tóth Attila]

On Csü, Március 25, 2010 20:23, lists@m8y.org wrote:
> On Thu, 25 Mar 2010, Ed W wrote:
>
>> 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
>
> Right, he simply turned /dev/random into /dev/urandom.
> I was under the impression the entropy key was simply a fancy PRNG.  Now
> that I know it offers
> true randomness, I'm more impressed. Also curious exactly what it uses as
> a source.

http://www.entropykey.co.uk/tech/

Be aware of a 2.6.31 USB serial driver bug - already fixed.

Regards:
Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057, 06-30-5962-962
Attila Toth MD, Radiologist, +36-20-825-8057, +36-30-5962-962

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

[Rob Kendrick]

On Thu, 25 Mar 2010 15:23:52 -0400 (EDT)
lists@m8y.org wrote:

> Right, he simply turned /dev/random into /dev/urandom.
> I was under the impression the entropy key was simply a fancy PRNG.
> Now that I know it offers true randomness, I'm more impressed. Also
> curious exactly what it uses as a source.

From http://www.entropykey.co.uk/tech/:

"The Entropy Key uses P-N semiconductor junctions reverse biassed with
a high enough voltage to bring them near to, but not beyond, breakdown
in order to generate noise. In other words, it has a pair of devices
that are wired up in such a way that as a high potential is applied
across them, where electrons do not normally flow in this direction and
would be blocked, the high voltage compresses the semiconduction gap
sufficiently that the occasional stray electron will quantum tunnel
through the P-N junction. (This is sometimes referred to as avalanche
noise.) When this happens is unpredictable, and this is what the
Entropy Key measures."

It's a pretty standard trick.  What's special is that it uses two, and
mixes the contents together, and so it can detect when one fails.  Oh,
and its price.  (Other, much less sophisticated devices, cost as much
as ten times more and are toys in terms of their security against
attack.)

B.

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

[Ed W]

On 25/03/2010 20:11, Rob Kendrick wrote:
> ...
> It's a pretty standard trick.  What's special is that it uses two, and
> mixes the contents together, and so it can detect when one fails.  Oh,
> and its price.  (Other, much less sophisticated devices, cost as much
> as ten times more and are toys in terms of their security against
> attack.)
>    

It seems that you get quite a lot of tech here for the price?  Seems 
pretty decent that you can pickup an ARM processor, temp sensor and all 
the other bits for around £30..  I presume they are shifting quite a few 
since that seems like quite a mass market price?

I noticed a munin script in the ekeyd download - haven't tried it, but 
the quantity of variables you can monitor from the device seemed quite 
impressive.  Who would have thought you would have wanted to graph the 
temperature of your random number generator, but for those who do, you 
are in luck...

Ed W

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

[RB]

On Thu, Mar 25, 2010 at 14:34, Ed W <lists@wildgooses.com> wrote:
> I noticed a munin script in the ekeyd download - haven't tried it, but the
> quantity of variables you can monitor from the device seemed quite
> impressive.  Who would have thought you would have wanted to graph the
> temperature of your random number generator, but for those who do, you are
> in luck...

Thermal and power fluctuations are common approaches to subverting the
entropy available in an RNG.  Thermal noise based entropy generators
are particularly sensitive to this - reduce the temperature, reduce
the entropy.  IIRC, the VIA RNG is based on a pair of thermal sensors,
but since they're on-die it's regarded more as difficult to subvert
than an external set.

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

[Tom Hendrikx]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On 25/03/10 21:34, Ed W wrote:
> On 25/03/2010 20:11, Rob Kendrick wrote:
>> ...
>> It's a pretty standard trick.  What's special is that it uses two, and
>> mixes the contents together, and so it can detect when one fails.  Oh,
>> and its price.  (Other, much less sophisticated devices, cost as much
>> as ten times more and are toys in terms of their security against
>> attack.)
>>    
> 
> It seems that you get quite a lot of tech here for the price?  Seems
> pretty decent that you can pickup an ARM processor, temp sensor and all
> the other bits for around £30..  I presume they are shifting quite a few
> since that seems like quite a mass market price?
> 
> I noticed a munin script in the ekeyd download - haven't tried it, but
> the quantity of variables you can monitor from the device seemed quite
> impressive.  Who would have thought you would have wanted to graph the
> temperature of your random number generator, but for those who do, you
> are in luck...
> 

Please stop writing about all these fancy features. I feel an increasing
need to take out my credit card, even though I have no direct need for a
RNG right now. :)

At that price, it even invites for funshopping!

-- 
Regards,
	Tom


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Brian Kroth]

[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]

Ed W <lists@wildgooses.com> 2010-03-25 20:34:
> On 25/03/2010 20:11, Rob Kendrick wrote:
>> ...
<snip/>
> I noticed a munin script in the ekeyd download - haven't tried it, but  
> the quantity of variables you can monitor from the device seemed quite  
> impressive.  Who would have thought you would have wanted to graph the  
> temperature of your random number generator, but for those who do, you  
> are in luck...

Here's another graphing tool I started using since whoever started this
thread got me hooked on the subject :)
http://collectd.org/wiki/index.php/Plugin:Entropy

Things are much worse, even for physical machines, than I originally
suspected, so I'm now thinking about trying to setup something like this
in conjunction with both the entropy key and the timer_entropyd so that
I can provide an entropy service to various clients.
http://www.vanheusden.com/entropybroker/

This probably won't actually happen until some distant point in the
future, but I'm especially interested in getting it to virtual machines.
Unfortunately, from what I can find there's no nice interface between
the host's rng and the vm for vmware esx like there is for kvm (eg:
virtio_rng).  Anyone know of one?

With the entropy broker the thing I'm not totally clear on is how
entropy bits transferred over the network (presumably without encryption
as that might require entropy) would be worthwhile entropy?  What makes
it different from the situation where you're using the network device
interrupts as an source of entropy?  Couldn't both be observable?

Another question - I keep seeing people suggesting to hook rngd (from
rng-tools) up to /dev/urandom.  Doesn't that just feed your system
entropy with an prng most of the time?  I feel like this just gives the
illusion of a decent sized entropy pool.  Might as well hook your app up
to /dev/urandom instead, correct?

In any case, waiting anxiously for delivery of my entropy key so I can
start playing.

Cheers,
Brian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Rob Kendrick]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

On Fri, 26 Mar 2010 09:15:19 -0500
Brian Kroth <bpkroth@gmail.com> wrote:

> This probably won't actually happen until some distant point in the
> future, but I'm especially interested in getting it to virtual
> machines. Unfortunately, from what I can find there's no nice
> interface between the host's rng and the vm for vmware esx like there
> is for kvm (eg: virtio_rng).  Anyone know of one?

The tool you previously mentioned, Entropy Broker, is amongst the
better choices.

> With the entropy broker the thing I'm not totally clear on is how
> entropy bits transferred over the network (presumably without
> encryption as that might require entropy) would be worthwhile
> entropy?  

I believe Entropy Broker encrypts, so it should be safe in that
respect.  Not that it's much of a problem on a VM where the network
cable in question is a completely virtual one.

> What makes it different from the situation where you're
> using the network device interrupts as an source of entropy?
> Couldn't both be observable?

Such interrupts aren't great choices for entropy because they're so
easily manipulable, anyway.

> Another question - I keep seeing people suggesting to hook rngd (from
> rng-tools) up to /dev/urandom.  Doesn't that just feed your system
> entropy with an prng most of the time?  I feel like this just gives
> the illusion of a decent sized entropy pool.  Might as well hook your
> app up to /dev/urandom instead, correct?

Yep.

B.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Ed W]

On 26/03/2010 14:15, Brian Kroth wrote:
> Here's another graphing tool I started using since whoever started this
> thread got me hooked on the subject :)
> http://collectd.org/wiki/index.php/Plugin:Entropy
>    

Nice

For those using snmpd (eg cacti) all I did was add this line to my 
/etc/snmp/snmpd.conf file:
exec .1.3.6.1.4.1.2021.60 entropy /bin/cat 
/proc/sys/kernel/random/entropy_avail

Then I used a template from the cacti mailing list to easily pull that 
into a graph in cacti and plot it

> Things are much worse, even for physical machines, than I originally
> suspected, so I'm now thinking about trying to setup something like this
> in conjunction with both the entropy key and the timer_entropyd so that
> I can provide an entropy service to various clients.
> http://www.vanheusden.com/entropybroker/
>    

I don't have audio, video or builtin hw rand on my servers, so I could 
only user timer_entropyd.  This chewed about 2-5% CPU on one very 
lightly loaded quad core intel board and kept the entropy at about 
80-100%.  On my other AMD dual core live server, it chewed more like 
5-15% cpu (not sure why) and mostly it keeps entropy at 70-100%, but 
with regular dips to zero (server is pretty lightly loaded, load average 
around 0.2).  Unless you are a complete tinfoil hatter then this is 
probably plenty

The ekeyd keeps the machine at 100% entropy (actually it keeps it at 
slightly *over* 15,000 bytes which is the pool size - I'm not quite sure 
how/why it's keeping the pool at 101% filled, but there you go).  CPU 
load is zero

For distributing entropy around, the entropykey comes with a basic egd 
compatible socket and you simply setup an egd client (also supplied) to 
read from that socket.  I don't believe this is encrypted, so 
entropybroker looks better over a real network, but it's also not yet in 
portage (anyone got some time to contribute an ebuild?)

So from a "it's done" point of view, the entropy key really is a very 
simple and low CPU solution.

Ed W