From owner-freebsd-current Thu Oct 26 5:24:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 211C637B4E5; Thu, 26 Oct 2000 05:24:13 -0700 (PDT) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id e9QCLC449280; Thu, 26 Oct 2000 05:21:12 -0700 (PDT) (envelope-from jkh@winston.osd.bsdi.com) To: Kris Kennaway Cc: Terry Lambert , Warner Losh , Andrej Cernov , current@FreeBSD.ORG, markm@FreeBSD.ORG Subject: Re: entropy reseeding is totally broken In-Reply-To: Message from Kris Kennaway of "Thu, 26 Oct 2000 02:17:37 PDT." <20001026021737.B69282@citusc17.usc.edu> Date: Thu, 26 Oct 2000 05:21:12 -0700 Message-ID: <49276.972562872@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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