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 1Nun9X-0000tc-6s for garchives@archives.gentoo.org; Thu, 25 Mar 2010 13:31:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B10F0E08E5; Thu, 25 Mar 2010 13:30:39 +0000 (UTC) Received: from mail1.nippynetworks.com (mail1.nippynetworks.com [212.227.250.41]) by pigeon.gentoo.org (Postfix) with ESMTP id 4D267E08E5 for ; Thu, 25 Mar 2010 13:30:39 +0000 (UTC) Received: from localhost (mail1.nippynetworks.com [127.0.0.1]) by mail1.nippynetworks.com (Postfix) with ESMTP id 5988C6751C8 for ; Thu, 25 Mar 2010 13:30:37 +0000 (GMT) X-Virus-Scanned: amavisd-new at nippynetworks.com Received: from mail1.nippynetworks.com ([127.0.0.1]) by localhost (mail1.nippynetworks.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6n+iYwInsDIn for ; Thu, 25 Mar 2010 13:30:37 +0000 (GMT) Received: from eds-mbp.wildgooses.local (office.nippynetworks.com [94.194.201.187]) (Authenticated sender: edward@wildgooses.com) by mail1.nippynetworks.com (Postfix) with ESMTPSA id 04D9F674955 for ; Thu, 25 Mar 2010 13:30:36 +0000 (GMT) Message-ID: <4BAB657C.8060309@wildgooses.com> Date: Thu, 25 Mar 2010 13:30:36 +0000 From: Ed W User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 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 To: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] Bought an "entropy-key" - very happy References: <4BA92703.4020200@wildgooses.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: aa5e4477-384a-437a-bac9-79aeef409542 X-Archives-Hash: 2fa77e67c109c29283a4afb7ea361949 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=20 >> on a hardened installation the entropy pool never deviates from full=20 >> up... >> >> Now, at =A330 it seems like a bargain for a fancy random number=20 >> generator, but then I read that the daemon can be switched to pipe=20 >> 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=20 >> clients. In my case this solves the problem of how to pipe entropy=20 >> 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=20 >> 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...=20 >> 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=20 > 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=20 that once the entropy pool is depleted on Linux then operations against=20 /dev/random will stall, however, the evolution on linux has been that=20 since /dev/random is "unreliable" most apps now seem to go directly to=20 /dev/urandom which is similar, but doesn't block once the entropy pool=20 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=20 that you can hit with a quick google search, but at least on some of my=20 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=20 processes running on a small machine) I could see that my entropy pool=20 is getting zapped to zero in just seconds. Hence there is clearly a=20 dubiously small amount of randomness left and basically we are working=20 the pseudo random device quite hard The entropy key just compensates by adding another fairly high quality=20 source of randomness - the kernel will incorporate this extra randomness = with what it gets from other sources, so even in the event that the=20 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=20 algorithm, but uses an internal "noise generator" to produce it's randomn= ess Given you can run a bunch of machines from one device it seemed like a=20 very simple solution to the situation Good luck Ed W