From owner-freebsd-current Fri Oct 27 19:19:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 947D837B479 for ; Fri, 27 Oct 2000 19:19:09 -0700 (PDT) Received: from gorean.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id TAA44924; Fri, 27 Oct 2000 19:18:56 -0700 (PDT) (envelope-from DougB@gorean.org) Message-ID: <39FA3790.E734C21C@gorean.org> Date: Fri, 27 Oct 2000 19:18:56 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 5.0-CURRENT-102 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: current@FreeBSD.ORG, Matt Dillon , Mark Murray Subject: Re: entropy reseeding is totally broken References: <200010280019.RAA03328@usr01.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > This is sweet! Seems it would give us the full benefits of Mark's > > > randomdev, and fit nicely with our normal configuration framework and > > > gives good flexibility. > > > > It also describes just what we have currently, except it misses the > > advantages of putting the entropy file on the root partition which makes > > it available immediately, and doesn't have mounting races built in. > > What currently exists does not allow a read-only /. Which sucks. Please keep a couple things in mind. First, there is no one solution that is going to suit everyone. It's exactly because my /var is not on / that I got interested in patching the current implementation of "save some randomness at boot and read it back in at startup" in the first place. I kept read-only and diskless / cases in mind when I tied my idea into the existing ability to specify the file AND used /var as a failsafe. Second, Mark has always intended and is currently working on ways to make entropy harvesting happen in the boot phase. No one expected, or represented this file-based method as the ultimate solution. Third, Schneier's paper suggests loading a file of written-out entropy at boot as an additional reseeding source, so we need to work out the store a file across boot in any case. It's entirely possible that this won't work for some edge cases, but harvesting entropy in the boot process will help alleviate that. Finding answers to the current problems will be easier if we keep the goals clear. Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message