<div dir="ltr"><div class="gmail_extra">>On Mon, Jan 26, 2015 at 10:59 AM, Ralf Senderek <<a href="mailto:crypto@senderek.ie">crypto@senderek.ie</a>> wrote:<br>><br>>> On Mon, 26 Jan 2015 14:12:29 iang wrote:<br>>>><br>>>>  On 25/01/2015 16:35 pm, Ralf Senderek wrote:<br>>>><br>>>> >  When I read bytes from /dev/random with dd and immediately check this<br>>>> >  file again, n bits are missing as a result of the read operation.<br> .....<br>>><br>>><br>>>  My advice:  applications should use /dev/urandom.<br><br><br>>I won't follow your advice, because for the Crypto Pi I want high-quality<br>>keys with a reliable amount of entropy in each of them, not only<br>>pseudo-random numbers<br>.....<br>>I agree that we're in implementation land already, and in the end we<br>>have to assess a working system and not a mathematical notion.<br><br>Since you are in implementation land code in a way that lets you</div><div class="gmail_extra">change the way "*random*" works with minimum impact on the rest</div><div class="gmail_extra">of the code base.  Good design here will let you apply tomorrows lessons</div><div class="gmail_extra">quickly.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The more I read about the BSD decisions on random the more I believe that any</div><div class="gmail_extra">initial expectations may become fragile and need to be updated.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The two obvious /dev/random and /dev/urandom involve system</div><div class="gmail_extra">calls which invoke mutex locks all of which takes more time than</div><div class="gmail_extra">interacting with a well seeded user space PRNG.   </div><div class="gmail_extra"><br></div><div class="gmail_extra">Assuming flaws an important consideration for an attack is knowing </div><div class="gmail_extra">which flawed resource is involved.    In revision two consider multiple</div><div class="gmail_extra">user space PRNG(s) the selection of which is randomized and feed them</div><div class="gmail_extra">into a mixer using a random weight... 10% from PRNG(a), 60% from PRNG(b)</div><div class="gmail_extra">etc... </div><div class="gmail_extra"><br></div><div class="gmail_extra">Any clever idea needs to be subjected to testing... again a design that </div><div class="gmail_extra">isolates these functions facilitates testing to avoid the obvious.  We</div><div class="gmail_extra">all know that double ROT13 is twice as good as single... </div><div class="gmail_extra"><br></div><div class="gmail_extra">Now I am off to play with BSD on my PI</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra"><br clear="all"><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>