EGD (was: 0.9.1)

Brian Warner warner at
Wed Jan 20 11:19:12 CET 1999

Hash: SHA1

wk at (Werner Koch) writes:
> EGD = Entropy Gathering Daemon.

I made some progress on the entropy daemon this week. I hope to have a
prototype for everyone to try out by this weekend. I wanted to post an
interface for folks to comment on.

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

You're absolutely right: simply opening a named pipe doesn't provide enough
control over what you get. I had hoped to create a drop-in replacement for
/dev/random but that's just not going to happen.

EGD will accept connections from clients (consumers of entropy) on either unix
sockets or tcp sockets, with names and port numbers depending upon how it is
started. Something like
 egd --unix ~/.gnupg/egd --tcp 10101 &
to listen on two ports. The typical operation would be to start just a unix
socket, in some directory that is private to the user. The sockets can be
configured to be read-only or read-write-control sockets.

The usual read-only socket accepts just two commands:

 -> 0x01  (read some entropy)
 -> 0xNN  (bytes desired)
 <- 0xMM   (how many bytes are coming)
 <- MM random bytes

 -> 0x02  (query entropy level)
 <- 0xMM  (msb of 32-bit number of estimated bits of entropy in the pool)
 <- 0xmm
 <- 0xll
 <- 0xLL  (lsb)

The read-write-control socket adds some more:

 -> 0x03  (write entropy)
 -> 0xMM  (msb of bits of entropy being added)
 -> 0xLL  (lsb)
 -> 0xNN  (bytes of data that are coming)
 -> NN bytes

and probably another for forcibly setting the entropy level, and maybe even
some for getting the current list of active entropy sources.

If you ask for more entropy than is available in the pool, you are given as
much as is available (it will not block to gather more). You can only get 255
bytes per request. You open the socket, send a request, get the response,
repeat as desired, close the socket. [would it be useful to add a command that
returns as many bytes as you request despite the entropy running out? Would
such a command available in a system-wide daemon allow any kind of attack
(maybe where someone uses up all your entropy?)]

You might want to have gpg (or the rand_egd module or wherever you put this
interface) have an option to set the path to the unix socket so that some users
could run a private copy with the socket in ~/.gnupg, while others could have
it started at boot time in a world-readable place, maybe /dev/egd .

Internally, the daemon loops through a list of gatherer calls (copied from the
set in rndunix.c), which each have parameters like the entropy density of the
output (bits per byte), the maximum number of bits of entropy to accept from
this source in a single call, how long to wait for the command to complete
before killing it off (to avoid hangs in netstat calls that might try to do
name lookups), how long to wait before calling it again. There are also
parameters to control how large the entropy pool is and how many gatherers can
be running simultaneously (to avoid the rndunix behavior that shoots the
system load up to about 10 very quickly). The daemon keeps a few gatherers
running at a time until the entropy pool is filled, then slowly decays the
entropy count. Any time the count drops below a threshold (that is close to
the size of the pool), new gatherers are spawned off as needed to refill it.
(actually, come to think of it, I should add a delay in here, because just
after someone comes and reads from the pool, the system will be busy doing
work for them for a little while).

The pool will be stirred and added to just like /dev/random.

There is a big select loop inside that allows multiple gatherers to be
pending, multiple clients to be requesting, and the whole thing never blocks
anyone who doesn't need to be blocked and never spins idly. (I snarfed code
from an old project that was a kind of game server that you telnet
into.. gotta love code reuse).

Anyway, just wanted to share some thoughts and plans. I should have something
that can do most of this by this weekend, and I'll post it here.


Version: GnuPG v0.9.1 (GNU/Linux)
Comment: For info see


More information about the Gnupg-devel mailing list