Date: Tue, 06 Jun 2000 13:05:43 -0400 From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> To: Mark Murray <mark@grimreaper.grondar.za> Cc: Mark Murray <mark@grondar.za>, arch@FreeBSD.org, phk@FreeBSD.org Subject: Re: (2nd iteration) New /dev/(random|null|zero) - review, please Message-ID: <393D2F67.EFC00B39@vangelderen.org> References: <393BEE84.BBAD3E82@vangelderen.org> <200006060814.KAA21235@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Murray wrote: > > > I have finished doing a MI /dev/null and /dev/zero, and I have got a > > > new /dev/random. I'm looking for reviewers. > > > > I've already submitted a MI /dev/[null|zero] for commit to PHK. He > > said he would commit them after testing. It's the same driver you > > have already seen at http://jeroen.vangelderen.org/FreeBSD . > > I stole lots of ideas from you :-); I think mine is faster... There is no way to tell as I can't look at your sources but I'd be interested to find out. Why didn't you submit patches if you knew I had already done the work? > > Split-level. Entropy sources should export an entropy device. Yarrow > > should bind to all available entropy devices and use those. This would > > allow for > > - entropy devices in KLDs. > > - dynamic addition/removal of entropy sources (USB). > > - separation of RNG policy (Yarrow) from entropy gathering. > > - dynamic IRQs not affecting RNG security. > > Makes sense, but I need an actual mechanism for achiving this. BDE > suggested the module event handler; I need to investigate. kobj and kqueue. Entropy devices should be kobjects. Kernel keeps a pool of those and the Yarrow module can pull the ones it uses. The Yarrow module would register with the pool to receive arrival events and DTRT. kobjects should have a type so that you can use the pool for different device types. Something tells me that such a thing is already done for USB and pccard but I don't know for sure. > > > o The RNG is slow; the others are much faster than their originals. > > > > Can be tweaked. Use a 256-bit cipher like Rijndael and build a hash > > out of it. Would improve security too as the entropy pool would hold > > 256 bits. You can also pre-generate a few KB of random bits. > > Hmmm.... Sounds good! Got a Rijndael reference? http://www.esat.kuleuven.ac.be/~rijmen/rijndael/ . I have a 256-bit version (block and key). It's pretty easy to construct a 256-bit hash out of that, using a MD{45}-like padding scheme. This would give us Yarrow-256 as opposed to Yarrow-160 described in Bruce's paper. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_ \_| \ _|/' \/ (_)>(_) (_) (_) (_) (_)' _\o_ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?393D2F67.EFC00B39>