EGD (was: 0.9.1)
wk at isil.d.shuttle.de
Sat Jan 16 13:09:42 CET 1999
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
> 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
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.
More information about the Gnupg-devel