| 1 |
On Thu, 25 Mar 2010, Ed W wrote: |
| 2 |
|
| 3 |
> On 23/03/2010 21:02, lists@×××.org wrote: |
| 4 |
>> On Tue, 23 Mar 2010, Ed W wrote: |
| 5 |
>> |
| 6 |
>> > OK, so to conclude the previous thread - I bought an entropy key from |
| 7 |
>> > the nice folks at Simtec via http://entropykey.co.uk |
| 8 |
>> > |
| 9 |
>> > Short version is you plug it in, install the ekeyd package and even on a |
| 10 |
>> > hardened installation the entropy pool never deviates from full up... |
| 11 |
>> > |
| 12 |
>> > Now, at £30 it seems like a bargain for a fancy random number generator, |
| 13 |
>> > but then I read that the daemon can be switched to pipe the data out in |
| 14 |
>> > "egd" format and essentially you can have one machine supply high |
| 15 |
>> > volumes of random numbers for a fair number of networked clients. In my |
| 16 |
>> > case this solves the problem of how to pipe entropy to some cheap rented |
| 17 |
>> > servers where we don't get to touch the physical 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 a |
| 21 |
>> > plug (and really need to work on their presence via google... Searches |
| 22 |
>> > 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 the |
| 26 |
>> 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 that |
| 34 |
> once the entropy pool is depleted on Linux then operations against |
| 35 |
> /dev/random will stall, however, the evolution on linux has been that since |
| 36 |
> /dev/random is "unreliable" most apps now seem to go directly to /dev/urandom |
| 37 |
> which is similar, but doesn't block once the entropy pool is empty (simply |
| 38 |
> the quality of random numbers declines) - however, it's reverting to a pseudo |
| 39 |
> random number algorithm |
| 40 |
|
| 41 |
Right, he simply turned /dev/random into /dev/urandom. |
| 42 |
I was under the impression the entropy key was simply a fancy PRNG. Now that I know it offers |
| 43 |
true randomness, I'm more impressed. Also curious exactly what it uses as a source. |
Archives