From owner-freebsd-audit Mon Nov 29 12:30:51 1999 Delivered-To: freebsd-audit@freebsd.org Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12]) by hub.freebsd.org (Postfix) with ESMTP id 0DDDE154F3; Mon, 29 Nov 1999 12:30:36 -0800 (PST) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id PAA03186; Mon, 29 Nov 1999 15:32:50 -0500 (EST) Date: Mon, 29 Nov 1999 15:32:50 -0500 From: Dan Moschuk To: Kris Kennaway Cc: Dan Moschuk , Bruce Evans , Mike Smith , audit@FreeBSD.ORG, Warner Losh Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Message-ID: <19991129153250.A2999@spirit.jaded.net> References: <19991129105703.C277@spirit.jaded.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from kris@hub.freebsd.org on Mon, Nov 29, 1999 at 11:24:38AM -0800 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | Yep - the one in the Linux kernel is 1.06 or so of the same code (we have | 0.95, OpenBSD 1.00). OpenBSD have essentially welded arc4random() to the | output of read_random for their /dev/arandom, whereas we just hash | whatever we can get from the entropy pool (possibly nothing) with MD5 | until we fill the buffer, for /dev/urandom (/dev/random is just the MD5 | hash of as much entropy as is present in both cases). Hashing is done for good reason; if we expose our internal state through random numbers, they are possible to predict. Running the data through MD5 reduces this risk. | It's been a while since I checked, but I think in Linux they (perhaps | gratuitiously) use SHA1 instead of MD5. It looks like there have been some | changes in the entropy-stirring and extraction mechanism in the underlying | code, though, so it's probably worthwhile updating. Whether the arandom | method is better than urandom is I guess open for debate :-) SHA1 generates a bigger hash than MD5, so for that reason it is probably worth switching to. However... | I don't know what Theodore Ts'o's credentials are, but I'm still much more | inclined to trust the work of someone who does this stuff for a living | than a part-time cryptographer. AFAIK no professional cryptographers have | taken a serious look at "our" (Linux/Open/FreeBSD) PRNG and the effects | of any random twiddles people may have done to them over time. ... I have to agree with you here. If we were to pit Theodore Ts'o's routine against the possibility of using Yarrow, I would choose Yarrow. Just because OpenBSD uses this, doesn't mean we have to. In fact, ideally what I would like to see is this: i) Yarrow (or possibly something else should your research yield Yarrow as ``unsafe'') routines built into the kernel. ii) Replace random() with yarrow_random() in all instances iii) Replace /dev/*random with routines from Yarrow. Indeed this is a little bit of work, but anything that allows me to further put off NFS locking is OK with me. :-) Although Yarrow is quite a virgin algorithm as far as cryptographical standards go, I do trust the work of two widely respected professional cryptographers over that of an amateur. Cheers, -- Dan Moschuk (TFreak!dan@freebsd.org) "Cure for global warming: One giant heatsink and dual fans!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message