EGD (was: 0.9.1)

[Werner Koch]

EGD = Entropy Gathering Daemon.

Brian Warner <warner at lothar.com> writes:

> I'll see what I can do. I was thinking about it a bit further.. you'd need
> named pipes instead of sockets (since you can't open() a socket), and since
> the daemon would have no way of knowing how much data had been read, you can't
> keep track of entropy as accurately as the kernel device can (hmm, maybe with

It should be more easy to keep track of this if a message format is
used.

> If I did it in perl, would that seriously impair anybody's ability to use it?

Go ahead if someone does not like it he can rewrite it in C

> as you want, would that be enough? Or is there a good reason for a control
> port of some kind (to query entropy state and do the ioctl-ish things that
> /dev/random can do), or to allow writes that might add to the entropy pool?

No nned for icoctl becuase we look at this as a entroy gathering
devoces and not as a cryptograhic strong RNG.  It would be nice to
have 2 device one which block and one which does not.

> About how much entropy is used? I have a little perl/gtk bar-graph widget to

I'll add a way to gather stats.

> Do you think there is a use for the /dev/random -equivalent for which reads
> block when there isn't enough entropy available? Or just the /dev/urandom

Yes.

It is a good idea to deliver different entroy bytes to each client
even if they come from the same source.  It is easy to achieve this:
Give every connection a random seed (some kind of younter is good
enough for this purpose) and deliver the entropy bytes bytes by
passing them thru some simple stream encipher build upon a hash
function (see Schneier, Applied Cryptography how to to this).

Forking for every client is okay IMHO.


  Werner