Re: Not enough entropy in RNG
On Thu, Jan 31, 2002 at 02:29:30PM +0100, Niels Möller wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> 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 brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: