From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5AE58200ABA for ; Thu, 22 Sep 2011 10:43:49 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g5t0006.atlanta.hp.com (Postfix) with ESMTP id 2EE35C1F5; Thu, 22 Sep 2011 17:43:48 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id C0B2514144; Thu, 22 Sep 2011 17:43:47 +0000 (UTC) Message-ID: <4E7B73D2.9070002@hp.com> Date: Thu, 22 Sep 2011 10:43:46 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Dave Taht Subject: Re: Preliminary results of using GPS to look for clock skew References: <20110921230205.2275820C2E5@snark.thyrsus.com> <20110922021137.GB21302@thyrsus.com> <4E7B6D48.2040205@hp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: esr@thyrsus.com, Eric Raymond , bloat-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 17:43:49 -0000 On 09/22/2011 10:34 AM, Dave Taht wrote: > On Thu, Sep 22, 2011 at 10:15 AM, Rick Jones wrote: >> >>> >>> One thing that surprised me of late is >>> http://www.bufferbloat.net/issues/271 >>> >>> while not related, surprises are the last thing we need as regards to >>> time. >>> >> >> The decision to stop letting networking contribute to entropy goes back a >> few years actually :) > > I wasn't paying attention then. > >> In another context, also where running-out of entropy was a problem, someone >> mentioned there are RNGs on USB keys that can be used to provide >> randomness/entropy/whatnot. The one mentioned in that discussion was the >> "Entropy Key" from these folks: http://www.entropykey.co.uk/ > > While I would like RNGs to be on-chip, the lack of randomness in a system > that supposedly does a lot of WPA encryption does concern me. > > https://dev.openwrt.org/ticket/9631 > > Secondly, routers at least have multiple interfaces to get randomness from > which would be hard to spoof all at the same time. > > and wireless routers have more noise sources and interfaces... > > so while I find the decision to eliminate networking as a source of randomness > makes some sense in a device with only one interface, I find it indefensible to > have nearly no entropy pool at all as a result for devices with > multiple interfaces. I don't necessarily disagree, but there were a number of reasons given, many of which I believe are/were independent of the number of interfaces in the host. I believe at least some of it can be found at http://lkml.indiana.edu/hypermail/linux/kernel/0805.3/0370.html though I don't think it has the thread all the way back to its beginning. rick