Date: Thu, 26 Oct 2000 09:25:05 -0400 From: "John W. De Boskey" <jwd@bsdwins.com> To: Jordan Hubbard <jkh@winston.osd.bsdi.com> Cc: Kris Kennaway <kris@citusc.usc.edu>, Terry Lambert <tlambert@primenet.com>, Warner Losh <imp@village.org>, Andrej Cernov <ache@nagual.pp.ru>, current@FreeBSD.ORG, markm@FreeBSD.ORG Subject: Re: entropy reseeding is totally broken Message-ID: <20001026092505.A88230@bsdwins.com> 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 References: <kris@citusc.usc.edu> <49276.972562872@winston.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001026092505.A88230>