From owner-freebsd-current@FreeBSD.ORG Tue Apr 13 21:38:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11DCC16A4CE for ; Tue, 13 Apr 2004 21:38:11 -0700 (PDT) Received: from out007.verizon.net (out007pub.verizon.net [206.46.170.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id A399443D5C for ; Tue, 13 Apr 2004 21:38:10 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out007.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040414043809.URMJ28276.out007.verizon.net@mac.com>; Tue, 13 Apr 2004 23:38:09 -0500 Message-ID: <407CC0A2.1010302@mac.com> Date: Wed, 14 Apr 2004 00:40:02 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <200404131550.i3DFocIn099231@grimreaper.grondar.org> <428207C0-8D7B-11D8-B697-003065ABFD92@mac.com> <20040413191058.GF20550@Odin.AC.HMC.Edu> <20040413232816.GB25818@Odin.AC.HMC.Edu> <407C9B07.9070108@mac.com> <20040414031017.GA20404@Odin.AC.HMC.Edu> In-Reply-To: <20040414031017.GA20404@Odin.AC.HMC.Edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out007.verizon.net from [68.160.247.127] at Tue, 13 Apr 2004 23:38:09 -0500 cc: freebsd-current@freebsd.org Subject: Re: dev/random X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 04:38:11 -0000 Brooks Davis wrote: > On Tue, Apr 13, 2004 at 09:59:35PM -0400, Chuck Swiger wrote: [ ... ] >>> You can use a file at this point, but what file should you use? >> >> I would choose a file that software like OpenSSL, OpenSSH, GnuPG, the EGD, >> would expect to read entropy from, preferably by default. When we also >> need to consider the context of diskless booting where only a minimal root >> filesystem is mounted, it seems /etc/entropy is reasonable. > > Those programs mostly hope /dev/random works. EGD provides a fake > /dev/random based on things like ps output. Sure, I agree with your assessment. OpenSSL can fall back to using EGD and /etc/entropy for circumstances where /dev/random does not work. Aren't such circumstances what we're talking about? :-) Or have you found a good way of feeding /dev/random? >> Even though the client machines are mounting the diskless root >> read-only, each client that reads /etc/entropy will be getting >> different bits, ie, they'll be grabbing entropy from the server's >> random pool to initialize themselves. > > This won't work. A named pipe is only usable on the local machine much > like a device node. The filesystem is bairly involved in the process. Maybe I'm missing something. Isn't the nfsd serving the root filesystem to diskless clients running locally on the fileserver? If need be, one could simply pull 512 bytes (or whatever) from /dev/random and store it as a flat file, and shuffle it each time one sees a tftpd log record of a kernel being booted go by (or some such trigger). On the other hand, any such mechanism does not address your second point: > As Mark points out, in many environments, this would be a bad idea even > if it worked because it would be easily sniffable. True. There's no magic solution to security, I think. Mark also mentioned, in reference to a lab machine, would you "trust _anything_ on that machine's hard disk?" However, if you're concerned about entropy being sniffed on the network as a possible security concern, shouldn't one also be just as concerned about an intruder sniffing passwords or equivalents, or someone trojanning the kernel on the fileserver one of these diskless thingy's boots from with a keystroke logger or worse? Or them setting up a rogue DHCP/BOOTPD host, or breaking into the machine via a security hole in some service, etc? Where else are you going to get entropy from but the network (or human events, assuming you've got a willing and patient operator present :-) if the system is a diskless workstation? >> Perhaps it might be useful to have a sysctl for whether /dev/random blocks >> or whether it switches from providing "true" entropy to providing >> cryptographicly strong random numbers generated by a decent PRNG seeded by >> or otherwise merged with what "true" entropy is available. [aka >> /dev/urandom] > > We've got that already, it's just implemented by dumping junk into > /dev/random and hoping it's good enough like is currently done in > initrandom. I see. Yes, that seems to be the case for 5.x. That's not the case for 4-STABLE, though? 47-sec# repeat 10 do (cat -u /dev/random | wc -c ; sleep 0) done 512 5 6 5 10 5 6 5 10 5 48-sec# repeat 10 do (cat -u /dev/random | wc -c ; sleep 1) done 512 406 408 407 406 406 407 410 406 406 Higher sleep times give a uniform 512 bytes. A machine without crypto hardware gives: 6-pi# repeat 10 do (cat -u /dev/random | wc -c ; sleep 0) done 8 0 2 3 2 2 0 2 2 0 6-pi# repeat 10 do (cat -u /dev/random | wc -c ; sleep 1) done 66 4 5 4 3 3 3 4 5 5 It's moderately interesting to compare entropy gathering rates: something like a 7951 chip produces ~400 bytes of usable entropy per second? Is that right? -- -Chuck