From owner-freebsd-current Thu Oct 26 6:28: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from bsdone.bsdwins.com (www.bsdwins.com [192.58.184.33]) by hub.freebsd.org (Postfix) with ESMTP id 7EB3137B4F9; Thu, 26 Oct 2000 06:27:30 -0700 (PDT) Received: (from jwd@localhost) by bsdone.bsdwins.com (8.11.0/8.11.0) id e9QDP5K88306; Thu, 26 Oct 2000 09:25:05 -0400 (EDT) (envelope-from jwd) Date: Thu, 26 Oct 2000 09:25:05 -0400 From: "John W. De Boskey" To: Jordan Hubbard Cc: Kris Kennaway , Terry Lambert , Warner Losh , Andrej Cernov , current@FreeBSD.ORG, markm@FreeBSD.ORG Subject: Re: entropy reseeding is totally broken Message-ID: <20001026092505.A88230@bsdwins.com> References: <49276.972562872@winston.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <49276.972562872@winston.osd.bsdi.com>; from jkh@winston.osd.bsdi.com on Thu, Oct 26, 2000 at 05:21:12AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan writes a nice piece of mail... If this was happening in -stable I'd be in total agreement. However, we're talking -current, and is not -current the integration area for new technologies, whether they be rough or round edged? This reminds me of the old development arguement: Don't do that, it hurts me. which has caused alot of good code to never see the light of day. -John ----- Jordan Hubbard's Original Message ----- > > The issue is one of seeding the device strongly. If all you care about > > is getting a different fortune when you boot then seeding with > > e.g. the system boot time would be enough, but obviously it doesnt > > make /dev/random cryptographically secure. > > I think there's a more general point being made here - if we're > not seeding /dev/random effectively at startup, fortune is the > least of our worries since all the other startup services will > be unrandom as well. > > This situation I see with /dev/random is kind of disturbing since I > think we're running the danger of falling into the following > all-too-common scenario in engineering: > > 1) Person X falls in love with a new algorithm or technique and > implements it in a fairly key service with quite a few rough > edges. > > 2) The users fail to embrace this new technology all that fervently > since those same rough edges make it a promising but annoying or > downright non-functional implementation. > > 3) Person X vigorously defends himself and/or the algorithm since > he knows it's really a much better thing in the long run and > simply needs "tweaking" to make it fully work. > > 4) The users see this as an attempt to cram broken bits down their > throats and just as vigorously fight back against what they see > as someone's fancy solution in search of a problem to solve. > > 5) Constructive dialog breaks down and it all turns into an exchange > of increasingly irritated words as each side feels the other isn't > hearing what it's trying to say or appreciating the bigger pictures. > > Let's try not to go there with /dev/random, please. :) > > - Jordan > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message