Re: Not enough entropy in RNG
On Wed, Jan 30, 2002 at 08:53:24AM -0500, Derek L Davies wrote:
>
> I've got /dev/random and /dev/urandom as well as a running egd . Now
> I'm looking for a suitable trick to hook egd's TCPIP port to
> /dev/random (and /dev/urandom). While looking I found:
>
> http://mel.interspace.dk/~sune/hurd/entropy.html
>
> I haven't tried it or even looked at the code, but it looks like they
> did a fair amount of work (ostensibly duplicating the work Marcus did
> to hack up {u}random).
It's the other way round, I knew about that stuff, but I wrote random
anyway. The reason is that I think although the above software is sound, it
requires a new protocol to talk to the entropy daemon, and uses only one
pool for random and urandom.
My code uses the normal file system i/o protocol (that's why the quality of
the entropy is not quantified), and uses seperate pools for urandom and
random. This has the advantage that reading from urandom doesn't empty the
entropy that is used by urandom (the same problem has the Linux kernel,
reading urandom drains the entropy pool completely). I don't know if my
implementation is complete respective to this, but the core is there and it
can be made configurable later.
> I would say the egd_glue part looks a bit suspisious to me. It seems
> like the cleaner thing to do would be to have the {u}random
> translators recogzize some flag, say, --egd <host:port>, and read the
> data directly. But maybe that would make it so that people couldn't
> write data to the translator while egd is writing to it or cause some
> other undesirable interference that I'm not anticipating? I have the
> sneaking suspicion I'm missing something ;-)
This is in general a good idea, and the major flaw with my implementation is
that it is waiting for entropy being pushed rather than polling it itself.
This is what I meant with the libchannel stuff. If you have libchannel, you
can just route some channels into the /dev/random translator, for example
with
settrans /dev/random /hurd/random ileave:device:random:egd:HOST/PORT
or something like that (where device, egd and ileave would be channel
classes. device would be a mach device channel, that is used for character
devices to read kernel generated entropy. egd would be a special channel
device that reads qualified entropy and turns it into a simple entropy
stream. ileave interleaves two channels into one).
This is all hypthetical, such a libchannel doesn't exist. But you get the
idea (compare it with libstore). It is very powerful and more flexible than
just putting the support into the random translator itself.
The random translator would just read from the channel to get the entropy.
> Before I go on with this can anyone comment? Does Sune's work have
> anything that Marcus's does not?
The comparison is like this:
Sune's: requires a new protocol mine: uses std protocols
Sune's: uses a common entropy pool mine: seperate pools
Sune's: linux kernel pool mixing(?) mine: GnuPG pool mixing
Sune's: uses qualified entropy mine: assumes 1 entropy is good for one random byte
Sune's: interface to match egd mine: interface to match the Hurd design
Considering the copyright and interface issues, I think that what I wrote
is (or will be with libchannel), a better fit for the Hurd.
> then
> merge Marcus and Sune's stuff together if it makes sense, but just
> from reading the announcements in entropy.html I think I would
> probably just go the way of modifying Marcus' stuff and leaveing the
> other stuff alone since it doesn't seem to add anything new/better.
If you want to improve on it, work on the libchannel abstraction library!
This will be a very important system library, for all character based data
streams in the Hurd. Changing random to use libchannel is not very hard,
and then we have the optimal solution in my opinion.
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.
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: