dev/random
Brooks Davis
brooks at one-eyed-alien.net
Tue Apr 13 20:10:38 PDT 2004
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
> @@ -94,4 +94,6 @@
> # (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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20040413/3ade0a87/attachment.bin
More information about the freebsd-current
mailing list