| 1 |
On 23/03/2010 21:02, lists@×××.org wrote: |
| 2 |
> On Tue, 23 Mar 2010, Ed W wrote: |
| 3 |
> |
| 4 |
>> OK, so to conclude the previous thread - I bought an entropy key from |
| 5 |
>> the nice folks at Simtec via http://entropykey.co.uk |
| 6 |
>> |
| 7 |
>> Short version is you plug it in, install the ekeyd package and even |
| 8 |
>> on a hardened installation the entropy pool never deviates from full |
| 9 |
>> up... |
| 10 |
>> |
| 11 |
>> Now, at £30 it seems like a bargain for a fancy random number |
| 12 |
>> generator, but then I read that the daemon can be switched to pipe |
| 13 |
>> the data out in "egd" format and essentially you can have one machine |
| 14 |
>> supply high volumes of random numbers for a fair number of networked |
| 15 |
>> clients. In my case this solves the problem of how to pipe entropy |
| 16 |
>> to some cheap rented servers where we don't get to touch the physical |
| 17 |
>> hardware... Very nice |
| 18 |
>> |
| 19 |
>> I have no relationship with the entropy-key guys other than being a |
| 20 |
>> happy customer. They seem like a small shop and I think they deserve |
| 21 |
>> a plug (and really need to work on their presence via google... |
| 22 |
>> Searches on this stuff only turn up $400 alternatives... Sheesh) |
| 23 |
> |
| 24 |
> I'm a bit puzzled how that offers much security. |
| 25 |
> Is the advantage that the algorithm for PRNG has to be extracted from |
| 26 |
> the chip inside the key before it can be abused? |
| 27 |
> |
| 28 |
> Seems no better than, say: |
| 29 |
> http://www.debian-administration.org/users/dkg/weblog/56 |
| 30 |
> |
| 31 |
> Apart from at least adding a bit more layers in the algorithm. |
| 32 |
|
| 33 |
I'm not sure what you mean by the link referenced above? The point is |
| 34 |
that once the entropy pool is depleted on Linux then operations against |
| 35 |
/dev/random will stall, however, the evolution on linux has been that |
| 36 |
since /dev/random is "unreliable" most apps now seem to go directly to |
| 37 |
/dev/urandom which is similar, but doesn't block once the entropy pool |
| 38 |
is empty (simply the quality of random numbers declines) - however, it's |
| 39 |
reverting to a pseudo random number algorithm |
| 40 |
|
| 41 |
I have experimented with most of the other entropy gathering options |
| 42 |
that you can hit with a quick google search, but at least on some of my |
| 43 |
machines these added non-trivial amounts of CPU load and usually for not |
| 44 |
much extra entropy (timer_entropyd was the best for me) |
| 45 |
|
| 46 |
I'm not a total tin hat - it's more that in the case of glibc and kernel |
| 47 |
both compiled with SSP, plus a load of virtual machines (lots of |
| 48 |
processes running on a small machine) I could see that my entropy pool |
| 49 |
is getting zapped to zero in just seconds. Hence there is clearly a |
| 50 |
dubiously small amount of randomness left and basically we are working |
| 51 |
the pseudo random device quite hard |
| 52 |
|
| 53 |
The entropy key just compensates by adding another fairly high quality |
| 54 |
source of randomness - the kernel will incorporate this extra randomness |
| 55 |
with what it gets from other sources, so even in the event that the |
| 56 |
device is fatally flawed then "probably" you still won't let an attacker |
| 57 |
figure out all your ssh keys. The ekey is not simply a software |
| 58 |
algorithm, but uses an internal "noise generator" to produce it's randomness |
| 59 |
|
| 60 |
Given you can run a bunch of machines from one device it seemed like a |
| 61 |
very simple solution to the situation |
| 62 |
|
| 63 |
Good luck |
| 64 |
|
| 65 |
Ed W |
Archives