<p dir="ltr"></p>
<p dir="ltr">Den 28 nov 2016 14:34 skrev "Salz, Rich" <<a href="mailto:rsalz@akamai.com">rsalz@akamai.com</a>>:<br>
><br>
> Ian: Use /dev/urandom<br>
><br>
> Bill: Use /dev/random<br>
><br>
>  <br>
><br>
> So I have a new basic theory about randomness: ask N crypto folks and get at least N+1 opinions.<br>
><br>
>  <br>
><br>
> I look forward to the day when the community can come to consensus.  Until then, OpenSSL will proceed as best as it can and get slammed for it at some point. </p>
<p dir="ltr">Me: use both :) </p>
<p dir="ltr">This was actually mentioned previously in another thread by somebody else, and I like the idea;</p>
<p dir="ltr">At boot, you create /dev/random normally and map /dev/urandom to it such that both work the same - until enough entropy is estimated to have been gathered, they both block and you can't get random numbers. </p>
<p dir="ltr">Once the entropy pool is assumed to be filled, you create/restore the standard /dev/urandom and now remap /dev/random to point to the (regular) /dev/urandom. Now none of them blocks, and they work the same.</p>
<p dir="ltr">After all you just want to block until you have enough entropy, and then never block again (for as long as the pool remains uncompromised), given that we already trust all these symmetric ciphers with the random numbers coming out of the CSPRNGs. Because why trust them with terabytes of data, but yet not trust that the CSPRNG works using the same class of symmetric algorithms based on similar sized entropy pools? </p>
<p dir="ltr">The real difficulty on the software side is entropy estimation. Everything else is mostly normal engineering. Once you know you have enough secret entropy in your pool, deriving unpredictable outputs from it is a solved problem. </p>