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):<div>
<br></div><div><span class="Apple-style-span" style="font-size: 13px; line-height: 19px; font-family: sans-serif; ">"It is also possible to write to <code style="font-family: monospace, 'Courier New'; background-color: rgb(249, 249, 249); ">/dev/random</code>. This allows any user to mix random data into the pool. Non-random data is harmless, because only a privileged user can issue the <a href="http://en.wikipedia.org/wiki/Ioctl" style="text-decoration: none; color: rgb(6, 69, 173); background-image: none; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: initial; background-position: initial initial; background-repeat: initial initial; ">ioctl</a> needed to increase the entropy estimate. The current amount of entropy and the size of the Linux kernel entropy pool are available in <code style="font-family: monospace, 'Courier New'; background-color: rgb(249, 249, 249); ">/proc/sys/kernel/random/</code>." </span></div>
<div><span class="Apple-style-span" style="font-size: 13px; line-height: 19px; font-family: sans-serif; ">( </span><a href="http://en.wikipedia.org/wiki//dev/random">http://en.wikipedia.org/wiki//dev/random</a> )</div><div>
<br></div><div>So, yes re Mark's:</div><div><br></div><div>".. or even just have a boot script that stirs in some unique per-node data?  (say low-order rdtsc salted with the node's</div><div>MAC.) ..."</div>
<div><br></div><div>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.</div>
<div><br></div><div>Peter</div><div><font class="Apple-style-span" face="sans-serif"><span class="Apple-style-span" style="line-height: 19px; "><br></span></font></div><div><font class="Apple-style-span" face="sans-serif"><span class="Apple-style-span" style="line-height: 19px;"><br>
</span></font><br><div class="gmail_quote">On Sat, Feb 26, 2011 at 5:32 PM, Mark Hahn <span dir="ltr"><<a href="mailto:hahn@mcmaster.ca">hahn@mcmaster.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> nodes using CentOS 5.  One of our users just ran onto a problem with<br>
> /dev/random blocking due to the lack of entropy.<br>
<br>
</div>/dev/random should be reserved for generating non-ephemeral keys.<br>
<div class="im"><br>
> Do others have this problem?  What do you do?<br>
<br>
</div>I've only ever heard of it on servers that do a lot of ssl transactions,<br>
and were configured to use /dev/random for transient keys or nonces.<br>
<div class="im"><br>
> Do you modify network drivers to introduce entropy?<br>
> Are there other suggested methods of adding entropy to /dev/random?<br>
<br>
</div>good questions.  I haven't been following the state of kernel entropy<br>
gathering - I guess I assumed that they'd worked out a basic set of<br>
reasonable sources and had a (eg) /proc interface for enabling others<br>
that would be site-specific (such as eth).<br>
<div class="im"><br>
> Are there ways to introduce entropy from the random number generator<br>
> on some Intel systems?  Did Intel remove this from more recent chips?<br>
<br>
</div>appears so:<br>
<a href="http://software.intel.com/en-us/forums/showthread.php?t=66236" target="_blank">http://software.intel.com/en-us/forums/showthread.php?t=66236</a><br>
<div class="im"><br>
> How reliable is /dev/urandom without initial entropy?  We boot from<br>
<br>
</div>my understanding is urandom is a crypto hash of the entropy pool:<br>
if the entropy pool never changes or is perfectly guessable,<br>
urandom is only as good as the hash.  since the crypto hash is not<br>
broken in general, I'd consider it plenty good.<br>
<div class="im"><br>
<br>
> stateless disk images and don't carry any entropy over from previous<br>
> boots.<br>
<br>
</div>boot scripts normally save and restore entropy, so why can't they do so<br>
to/from some server of yours?  or even just have a boot script that stirs<br>
in some unique per-node data?  (say low-order rdtsc salted with the node's<br>
MAC.)<br>
<br>
this is a good question - not a burning issue I think, but something to<br>
not forget about.  we're starting to use NFS-root login nodes, for instance,<br>
which could conceivably run into entropy issues.<br>
<div><div></div><div class="h5">_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
</div></div></blockquote></div><br></div>