On Thu, Jan 31, 2002 at 02:29:30PM +0100, Niels M�ller wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > The other thing that needs to be done is to add a random device to > > the oskit-mach branch of gnumach (we don't bother with the current > > incarnation of gnumach). This probably means adding a random device to > > oskit. This can then be used by random through the libchannel device class. > > Somewhere on the path between randomness sources and applications, > there has to be some "randomness pool" or mixer.
My random translator contains the GnuPG randomness code. As random and urandom are two different processes (same translator with different options), they both have their own GnuPG randomness code instances running, so there are two randomness pools, and two key pools. > I'm not sure if you > want to put that in the translator or in oskit, but to me, it would > make more sense to add code to oskit that let's its users get access > to things like disk-timing and other hardware dependent sources, and > but the pool management in some user-space process. Well, there is pool management in the user space process, but it doesn't harm if every source of entropy mixed its entropy in its own pool as well. This is important _because_ my random translator is ignorant about the source and the quality of the entropy, it just assumes that for each byte it reads, it gets one byte of "good" entropy, "good" for one byte of "true" randomness. > And the code that manages the pool needs to know what the sources are, > in order to reseed properly. So I'm afraid that a libchannel thing > that interleaves data from all the sources is not good enough. Well, the current assumption is that all sources are equally well. If you want to reseed it, you can just flood /dev/random with good entropy. If you write as much as the pool size (or twice of it, or so, I am not sure), you will replace the internal state completely. So just do a blocked write with enough bytes, and you will have reseeded (I think the current implementation does not worke exactly that way, but it should have the same effect. Your contribution is buffered and will be mixed in over time. There is no special reseed process in GnuPGs random code. But if you write 600 bytes into it, and then read 600 bytes out, you will have replaced the internal state completely, I guess). A lock ensures that during your one large write, no other entropy will be mixed in. > You may want to look at the Yarrow code in Nettle-1.5 which I released > a few hours ago. You can read the chapter on randomness at <URL: > http://www.lysator.liu.se/~nisse/nettle/nettle.html#Randomness>. This is all very interesting, and maybe at one time this can be worked into my random translator as an option, so that you can choose the pool mixing procedure by a command line option. You know where to send the patches to ;) BTW, if you really want weighted entropy, and multiple sources with different quality, and keep them seperate and do your own mixing, you could certainly extend the random translator syntax. For example in the following way: /hurd/random --source device:random --quality 0.5 --source egd:PORT/HOST --quality 0.3 Or in the following: /hurd/random --qualities 0.5:0.3 numberedileave:device:random:egd:PORT/HOST where numberedileave sends two bytes for each byte from the sources, namely INDEX:BYTE, where index is 1 if the byte comes from device:random and 2 if the byte comes from egd. Or it could send INDEX:COUNT:BYTE[:BYTE].... And then it might do its own mixing, reseeding, feeding, munging and frobbing. However, the current code does not have any of these features. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
