From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757523AbYERL2f (ORCPT ); Sun, 18 May 2008 07:28:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753139AbYERL20 (ORCPT ); Sun, 18 May 2008 07:28:26 -0400 Received: from www.church-of-our-saviour.org ([69.25.196.31]:40638 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751352AbYERL2Z (ORCPT ); Sun, 18 May 2008 07:28:25 -0400 Date: Sun, 18 May 2008 07:26:57 -0400 From: Theodore Tso To: Andi Kleen Cc: Arjan van de Ven , Chris Peterson , Herbert Xu , Alan Cox , Jeff Garzik , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Brandeburg, Jesse" , tpmdd-devel@lists.sourceforge.net, tpm@selhorst.net Subject: Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM Message-ID: <20080518112657.GK16496@mit.edu> Mail-Followup-To: Theodore Tso , Andi Kleen , Arjan van de Ven , Chris Peterson , Herbert Xu , Alan Cox , Jeff Garzik , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Brandeburg, Jesse" , tpmdd-devel@lists.sourceforge.net, tpm@selhorst.net References: <87abirytxj.fsf@basil.nowhere.org> <20080516105635.6cb1f505@core> <482D5FC5.2070103@firstfloor.org> <20080516121239.GA9627@gondor.apana.org.au> <482DB568.1040704@firstfloor.org> <20080517010136.GA15102@gondor.apana.org.au> <482EBAA8.3040506@firstfloor.org> <20080517130535.02d45372@infradead.org> <4830014F.9040800@firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4830014F.9040800@firstfloor.org> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 18, 2008 at 12:13:35PM +0200, Andi Kleen wrote: > We don't use it for most long term keys, e.g. ssh host keys. That is > because even on high entropy systems /dev/random usually doesn't work > during distribution installation because the system has not run long > enough to collect significant entropy yet. One thing which I'm not sure most people understand is that there isn't that much difference between /dev/random and /dev/urandom. They are fed by the same sources, at the high level. There is a single large entropy pool which gets fed by whatever entropy sources the kernel can get its hands on, which periodically catastrophically seeds separate smaller pools used by /dev/random and /dev/urandom. The only difference is that /dev/random does entropy tracking; /dev/urandom doesn't. Hence, if you don't think the system hasn't run long enough to collect significant entropy, you need to distinguish between "has run long enough to collect entropy which is causes the entropy credits using a somewhat estimation system where we try to be conservative such that /dev/random will let you extract the number of bits you need", and "has run long enough to collect entropy which is unpredictable by an outside attacker such that host keys generated by /dev/urandom really are secure". See why the qualifying statements is so important? If you really believe that there isn't enough entropy after installing a distribution, THEN YOU SHOULDN'T BE GENERATING SSH HOST KEYS. The problem is that the server scenario with no keyboard case is a really nasty one. > See also the distinction between "user controlled visible cryptography" > and "background cryptography" I introduced in a earlier mail on that > topic. gpg can only get away with it because they rely on a high level > of user education (so requiring banging on keys is ok), but that's > not really an option for your normal "everyday background crypto", > including longer term keys. No, this distinction is a specious one, I think. It's really more a level of paranoia. People tend to be much more paranoid about their own personal keys, at leasts if they are well trained. Most people don't bother verifying ssh host keys the first time they contact a host, making them subject to a man-in-the-middle attack. But most people don't mind, by which we can deduce that most folks aren't as careful about their ssh key. If distributions really cared, they could very well introduce keyboard banging as part of the install process; but no, being able to do an unmanned, "turnkey" install is considered more important. That says something about how much they care about security right there. (By the way, if you are at least forcing the user to type in a root password, having the distribution installer mix in the root password into /dev/random would be a Really Good Idea; also, mixing in whatever randomness it can get from the mouse during the install is also a Really Good Idea.) > Instead I think just both urandom and random should try to rely > on TPMs and other hardware rngs and always get high quality bit noise. Sure, if you can get access to a TPM or a hardware rng, that's *always* a better choice. But the reason for /dev/random and /dev/urandom's existence is that hardware manufacturers have either not included a real hardware RNG, or made it impossible to get to it. (I *still* haven't figured out how to access my TPM on my Lenovo laptops. Anyone who can send me turn-key instructions, let me know off-line.) Intel used to provide a true hardware RNG in their chipsets a few years ago (props to them), but then stopped after one generation (boo, hiss). If there is a way that we can at least seed /dev/random from the TPM (without needing any magic enabling keys, etc.) once at boot time, and then rely on what we can get from the environment, maybe we can do it in the kernel without needing to move all of the TPM access/contention control logic from userspace into the kernel. Of course, even if we did this, it wouldn't solve the distro problem (at least for distro's who truly care about the security of ssh host keys), since not all systems have TPM's. - Ted