0.9.1

[Brian Warner]

wk at isil.d.shuttle.de (Werner Koch) writes:

> Brian Warner <warner at lothar.com> writes:
> 
> > If we turned the rndunix code into a persistent daemon, with a pair of
> > unix sockets to correspond to /dev/random and /dev/urandom, couldn't that
> > drop into
> 
> That's the way we do it.  It also has the advantage that we don't have
> to care about GPL/cryptlib license conflicts.  I'd suggest not to call
> it /tmp/[u]random but /tmp/[u]entropy  and use a message format to
> pass information about the entroy quality along with the bytes of
> entropy.
> 
> What's need is a buffer as the entropy pool.  The /dev/random code
> together with the current rndunix.c is a goof starting point for such 
> a daemon.
> 
> Brian - do you have the time to work on it? 

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
userfs...:). So you basically have to fill the fifo until you cannot write any
more, then refill if necessary, losing some fixed amount (8k?) of bytes per
reading process.

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

If the interface is as simple as 'dd if=/tmp/uentropy of=bits', read as much
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?

> Print a message that the user should either ask the sysadm to install
> the daemon or to put it into his ~/.profile. - ah yes: we need an
> option (or better an environment var) to tell GnupG the name of the
> sockets. 

If it is a system-wide thing, I would put it in /tmp or even (perhaps a little
pretentious here) /dev. If a user starts it for themselves we could just throw
it in ~/.gnupg/[u]entropy.

> > Except for the lack of the special ioctls (to measure or change entropy
> > count), would such a device be at all discernible from the real
> > kernel-based /dev/random?
> 
> No and given the fact that the kernel based /dev/random is only used
> to seed the GnuPG RNG there is should be not much difference.

About how much entropy is used? I have a little perl/gtk bar-graph widget to
show me how much entropy is available in my /dev/random pool (the default
maximum is 4096 bits), and when generating keys it all gets used up
(encrypting messages is maybe 1000 bits? Hard to be sure). Given that the
userspace random device will invariably spill some entropy, we should have it
use a larger pool. 

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
version which depletes the entropy count but doesn't stop when it gets to
zero?

Off to figure out named fifos...

 -Brian