<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 26, 2015 at 9:50 AM, Kent Borg <span dir="ltr"><<a href="mailto:kentborg@borg.org" target="_blank">kentborg@borg.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 01/26/2015 09:57 AM, Henry Baker wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So what's the best practice for random numbers on a virtual machine.<br>
</blockquote>
<br></span>
If I may carp: "best practice" is a horrible term.</blockquote><div>...... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">t want the best way you want bad ways, too, including discussions of what makes the bad!<span class=""><font color="#888888"></font></span></blockquote><div> </div><div>Buttons are good especially when they ring clear and unambiguous alarms.  </div><div><div>The concurrent discussion about the Rand-Pi illuminates this need.</div></div><div><br></div><div>A better practice might be to export random bits from one or</div><div>more devices on the network and blend them together in </div><div>a way that you know and hopefully understand.       </div><div><br></div><div>Virtual machines have difficulty exporting individual hardware resources </div><div>to multiple VMs.  The hardware foundations of good RNG devices do not lend themselves</div><div>to virtualization  and/or  multiplexing the way network connections do.  So </div><div>yes, better solutions should be considered.   Multiplexing the host random</div><div>bits can involve a mutual exclusion lock that slows things down.  Owning</div><div>the host itself is not an option in many cloud solutions.</div><div><br></div><div>Network connection to a port on a set of machines you have some control over</div><div>and a process on each that can  read /dev/*rand* and deliver a little or a lot depending on </div><div>the hardware.  Use  good programming practices and perhaps iptables to limit connections </div><div>as well as design the process to throttle connections and share the bits.  </div><div><br></div><div>You can insert entropy into the local RNG under /dev/*rand* or address your </div><div>needs in different ways. </div><div><br></div><div>No matter what you elect to do you will promptly find a better way so make sure</div><div>to isolate what you do so the new and better solution is easy to install.</div><div><br></div><div>There are network available random numbers that should not be trusted</div><div>as a single source.  Mixing three and adding bits of your own can seed </div><div>your local PRNG to good effect.  Good enough to invite critical review.</div><div><br></div><div>There are three obvious /dev/random /dev/urandom and library functions</div><div>like random(), rand() see srand().  <br><br>See what this returns:</div><div>   cat /proc/sys/kernel/random/entropy_avail</div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>