From owner-freebsd-current Thu Jan 11 22:20:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 24C9037B400; Thu, 11 Jan 2001 22:20:03 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f0C6JQI12558; Fri, 12 Jan 2001 08:19:31 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200101120619.f0C6JQI12558@gratis.grondar.za> To: Doug Barton Cc: Warner Losh , Sheldon Hearn , markm@freebsd.org, freebsd-current@freebsd.org Subject: Re: entropy bikesheds References: In-Reply-To: ; from Doug Barton "Thu, 11 Jan 2001 15:00:35 PST." Date: Fri, 12 Jan 2001 08:19:21 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Barton said: > Since this post actually has some content I'm moving it to > -current. Cool! > > Our /var isn't persistant accross boots, btw. It is a mfs file > > system. Having a requirement that /var contain persistant data would > > likely lead to problems. > > It's precisely for these, and other hairy examples that I haven't > put the thing in /var yet. Even a diskless workstation can read files from > a RO root that the host writes out periodically, but there is no guarantee > that there will be a /var filesystem that we can read from at boot time. I > actually started to write some code to handle some obvious cases and got a > major headache just thinking about it. What is needed is some form of persistant storage to stash the Yarrow state over a reboot or a crash. There are a number of people saying "Over my dead body can you put it ${HERE}!!", without coming up with alternatives that are useful. At BSDCon, the concept of using the first swap partition was discussed, and I think it is a great idea, but the volunteer has yet to offer any code. > > I'm still not sure why we can't do something like: > > > > date > /dev/random > > cat /bin/ls > /dev/random > > fsck > > mount the file systems > > read in the entropy file > > > > Eg, toss some bone to the random pool. Sure, it will be highly > > preditable, but for the mount commands it doesn't matter. We fix > > before anything interesting happens. Just as usable is "echo 'sekrit password' > /dev/random". Might as well not bother. There is no usable randomness here, so rather than pretending, it is better to simply admit to ourselves that the entropy generator is giving crap numbers at this point. I originally put a block-at-startup in precicesly because of this complaint. Remember that on a brand-new system, at first boot, the sshd is going to use /dev/random to make keys. How insecure do you want that? Can we decide this, please - do we want secure startup (which will take some effort to achieve), or can we say "screw it" and start insecure like the old system? I'm happy to accomodate folks, but the constant lack of concensus combined with extreme positions is wearing a bit thin. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message