[Beowulf] /dev/random entropy on stateless/headless nodes

[Peter St. John]

After scanning a bunch of man pages (incidentally, "man urandom" explains
the difference between random and urandom; "man random" does not) and
experimenting to produce my reply (above), I found this when google pointed
into wiki (sheesh):

"It is also possible to write to /dev/random. This allows any user to mix
random data into the pool. Non-random data is harmless, because only a
privileged user can issue the ioctl <http://en.wikipedia.org/wiki/Ioctl> needed
to increase the entropy estimate. The current amount of entropy and the size
of the Linux kernel entropy pool are available in /proc/sys/kernel/random/
."
( http://en.wikipedia.org/wiki//dev/random )

So, yes re Mark's:

".. or even just have a boot script that stirs in some unique per-node data?
 (say low-order rdtsc salted with the node's
MAC.) ..."

So (from the wiki) piping dumb data into /dev/random is harmless since the
entropy measure wouldn't be fooled, so then yes, just anyone can pipe some
bytes in anytime. So yeah, the rtdsc, I just meant my 9 digits of
nanoseconds as something easy to try at boot time, and shuffling that with
the MAC is a good idea. (Since a light-nanosecond is about what 10 cm? the
lengths of cables in the server room would be enough to give every node
different boot times, in nanoseconds, right? or no, because your cables are
all standard lengths, but coiled as needed?). So just sticking in a script
that flushes such stuff into /dev/random at boot time (or anytime) should be
practicable and easy.

Peter



On Sat, Feb 26, 2011 at 5:32 PM, Mark Hahn <hahn at mcmaster.ca> wrote:

> > nodes using CentOS 5.  One of our users just ran onto a problem with
> > /dev/random blocking due to the lack of entropy.
>
> /dev/random should be reserved for generating non-ephemeral keys.
>
> > Do others have this problem?  What do you do?
>
> I've only ever heard of it on servers that do a lot of ssl transactions,
> and were configured to use /dev/random for transient keys or nonces.
>
> > Do you modify network drivers to introduce entropy?
> > Are there other suggested methods of adding entropy to /dev/random?
>
> good questions.  I haven't been following the state of kernel entropy
> gathering - I guess I assumed that they'd worked out a basic set of
> reasonable sources and had a (eg) /proc interface for enabling others
> that would be site-specific (such as eth).
>
> > Are there ways to introduce entropy from the random number generator
> > on some Intel systems?  Did Intel remove this from more recent chips?
>
> appears so:
> http://software.intel.com/en-us/forums/showthread.php?t=66236
>
> > How reliable is /dev/urandom without initial entropy?  We boot from
>
> my understanding is urandom is a crypto hash of the entropy pool:
> if the entropy pool never changes or is perfectly guessable,
> urandom is only as good as the hash.  since the crypto hash is not
> broken in general, I'd consider it plenty good.
>
>
> > stateless disk images and don't carry any entropy over from previous
> > boots.
>
> boot scripts normally save and restore entropy, so why can't they do so
> to/from some server of yours?  or even just have a boot script that stirs
> in some unique per-node data?  (say low-order rdtsc salted with the node's
> MAC.)
>
> this is a good question - not a burning issue I think, but something to
> not forget about.  we're starting to use NFS-root login nodes, for
> instance,
> which could conceivably run into entropy issues.
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
> To change your subscription (digest mode or unsubscribe) visit
> http://www.beowulf.org/mailman/listinfo/beowulf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20110226/3ab241fe/attachment.html>