Re: dev/random

On Tue, Apr 13, 2004 at 09:59:35PM -0400, Chuck Swiger wrote:
> >>Anyway, if /etc/rc.d/initdiskless is available, you've got a root 
> >>filesystem to read from, so can't one nudge the diskless client's 
> >>/dev/random using entropy from a file stored on it?
> >
> >You can use a file at this point, but what file should you use?
> 
> I would choose a file that software like OpenSSL, OpenSSH, GnuPG, the EGD, 
> would expect to read entropy from, preferably by default.  When we also 
> need to consider the context of diskless booting where only a minimal root 
> filesystem is mounted, it seems /etc/entropy is reasonable.

Those programs mostly hope /dev/random works.  EGD provides a fake
/dev/random based on things like ps output.

> >You almost certaintly don't have a /var and there's a good change / isn't
> >writable at all and starting all your hosts with the same entropy is
> >definatly a bad idea.  You also may not have anything in /etc other then
> >what is provided by make distribution.
> 
> Starting all of your hosts with the same entropy is a bad idea, agreed.
> 
> I would say that doing something which lets the hosts start rather than 
> hang is better than not having a host start up at all.  But I think one can 
> do better than use the same entropy for all clients, which is what my next 
> suggestion was about:
> 
> >>Or perhaps the /usr/share/examples/diskless/clone_root script could 
> >>call mknod to create a clone of the server's /dev/random device under 
> >>the diskless root directory, to provide different "real" entropy for 
> >>each diskless client?
> >
> >I'm not sure what you're getting at here. /dev is devfs even in single
> >user so mknod isn't applicable.  It's not optional.
> 
> Excuse me, one used to use mknod to create named pipes.  Under FreeBSD it's 
> now mkfifo.  Maybe a diff would explain what I mean better:
> 
> --- clone_root_20040413 Tue Apr 13 21:01:57 2004
> +++ clone_root  Tue Apr 13 21:08:33 2004
> _at__at_ -94,4 +94,6 _at__at_
>         #       (cd $DEST; cpio -i -H newc -d )
>         echo "+++ Fixing permissions on some objects"
>         chmod 555 $DEST/sbin/init
> +       echo "creating /etc/entropy"
> +       mkfifo ${DEST}/etc/entropy
>  }

I forgot about that use since I rairly use that feature, but see below.

> ...and set up an rc script on the fileserver to do:
>
>       cat /dev/random > ${DEST}/etc/entropy
>
> ...to fill the named pipe with high-quality entropy when and if a
> client machine reads that file.  Hmm, quick testing suggests the cat
> statement will terminate if too much data is read at a time, maybe
> "tail -f" instead?
>
> Somewhere in /etc/rc.d/initdiskless (or somewhere else appropriate),
> have client machines do something like:
>
>       dd if=/etc/entropy of=/dev/random bs=512 count=1 2>/dev/null
>
> Even though the client machines are mounting the diskless root
> read-only, each client that reads /etc/entropy will be getting
> different bits, ie, they'll be grabbing entropy from the server's
> random pool to initialize themselves.

This won't work.  A named pipe is only usable on the local machine much
like a device node.  The filesystem is bairly involved in the process.
As Mark points out, in many environments, this would be a bad idea even
if it worked because it would be easily sniffable.

> >To be clear, the problem is not that you can't open /dev/random for
> >read, it's that read() blocks until sufficent entropy arrives.  It's
> >worth noting that the quality of entropy needed in initdiskless is
> >pretty minimal.  rand() would actually be fine here other then the fact
> >that use of rand should not be encouraged.
> 
> Perhaps it might be useful to have a sysctl for whether /dev/random blocks 
> or whether it switches from providing "true" entropy to providing 
> cryptographicly strong random numbers generated by a decent PRNG seeded by 
> or otherwise merged with what "true" entropy is available.  [aka 
> /dev/urandom]

We've got that already, it's just implemented by dumping junk into
/dev/random and hoping it's good enough like is currently done in
initrandom.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4