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

[Mark Hahn]

> 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.