Date: Mon, 29 Nov 1999 15:32:50 -0500 From: Dan Moschuk <dan@FreeBSD.ORG> To: Kris Kennaway <kris@hub.freebsd.org> Cc: Dan Moschuk <dan@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, audit@FreeBSD.ORG, Warner Losh <imp@village.org> 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> In-Reply-To: <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>; from kris@hub.freebsd.org on Mon, Nov 29, 1999 at 11:24:38AM -0800 References: <19991129105703.C277@spirit.jaded.net> <Pine.BSF.4.21.9911291103500.51314-100000@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
| 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991129153250.A2999>