From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NusfW-0001Ja-VM for garchives@archives.gentoo.org; Thu, 25 Mar 2010 19:24:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 772FDE0920; Thu, 25 Mar 2010 19:23:54 +0000 (UTC) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by pigeon.gentoo.org (Postfix) with ESMTP id 41F79E0920 for ; Thu, 25 Mar 2010 19:23:54 +0000 (UTC) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id xNS41d0031GhbT857XPvDl; Thu, 25 Mar 2010 19:23:55 +0000 Received: from mail.m8y.org ([76.21.160.106]) by omta07.westchester.pa.mail.comcast.net with comcast id xXPt1d00N2J1q1o3TXPtD1; Thu, 25 Mar 2010 19:23:55 +0000 Received: by mail.m8y.org (Postfix, from userid 1000) id 726A710800F; Thu, 25 Mar 2010 15:23:52 -0400 (EDT) Date: Thu, 25 Mar 2010 15:23:52 -0400 (EDT) From: lists@m8y.org To: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] Bought an "entropy-key" - very happy In-Reply-To: <4BAB657C.8060309@wildgooses.com> Message-ID: References: <4BA92703.4020200@wildgooses.com> <4BAB657C.8060309@wildgooses.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1640045225-1269545032=:29587" X-Archives-Salt: affb08a6-90ae-49df-98a3-450609a8cad1 X-Archives-Hash: eb257e61170239237709c55d2f189150 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1640045225-1269545032=:29587 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE 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: >>=20 >> > OK, so to conclude the previous thread - I bought an entropy key from= =20 >> > the nice folks at Simtec via http://entropykey.co.uk >> >=20 >> > Short version is you plug it in, install the ekeyd package and even o= n a=20 >> > hardened installation the entropy pool never deviates from full up... >> >=20 >> > Now, at =A330 it seems like a bargain for a fancy random number gener= ator,=20 >> > but then I read that the daemon can be switched to pipe the data out = in=20 >> > "egd" format and essentially you can have one machine supply high=20 >> > volumes of random numbers for a fair number of networked clients. In= my=20 >> > case this solves the problem of how to pipe entropy to some cheap ren= ted=20 >> > servers where we don't get to touch the physical hardware... Very ni= ce >> >=20 >> > 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=20 >> > plug (and really need to work on their presence via google... Searche= s=20 >> > 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 t= he >> 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 th= at=20 > once the entropy pool is depleted on Linux then operations against=20 > /dev/random will stall, however, the evolution on linux has been that sin= ce=20 > /dev/random is "unreliable" most apps now seem to go directly to /dev/ura= ndom=20 > which is similar, but doesn't block once the entropy pool is empty (simpl= y=20 > the quality of random numbers declines) - however, it's reverting to a ps= eudo=20 > 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 th= at I know it offers true randomness, I'm more impressed. Also curious exactly what it uses as a= source. --8323328-1640045225-1269545032=:29587--