<div dir="ltr">On Fri, Jul 12, 2013 at 3:29 PM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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">
<div class="im">On 12/07/13 21:54 PM, Patrick Mylund Nielsen wrote:<br>
</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"><div class="im">
On Fri, Jul 12, 2013 at 2:48 PM, James A. Donald <<a href="mailto:jamesd@echeque.com" target="_blank">jamesd@echeque.com</a><br></div><div class="im">
<mailto:<a href="mailto:jamesd@echeque.com" target="_blank">jamesd@echeque.com</a>>> wrote:<br>
<br>
    On 2013-07-13 12:20 AM, Eugen Leitl wrote:<br>
<br>
        It's worth noting that the maintainer of record (me) for the<br>
        Linux RNG quit the project about two years ago precisely because<br>
        Linus decided to include a patch from Intel to allow their<br>
        unauditable RdRand to bypass the entropy pool over my strenuous<br>
        objections.<br>
<br>
<br>
    Is there a plausible rationale for bypassing the entropy pool?<br>
<br>
<br>
Throughput? Not bypassing means having to wait until enough randomness<br>
has been gathered from trusted sources.<br>
</div></blockquote>
<br>
<br>
Typically, the entropy pool is used to feed a PRNG.  Throughput isn't really an issue because modern PRNGs are fast, and there are very few applications that require psuedo-RNs at that sort of speed.</blockquote><div>
<br></div><div><div style="font-family:arial,sans-serif;font-size:13px">It seems that this indeed was the reason. In the original thread, Linus made the comment:</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px"><div>"The fact is, even if you worry about some back door for the NSA, or some theoretical lack of perfect 32-bit randomness, we can pretty much depend on it. We still do our own hashing on top of whatever entropy we get out of rdrand, and we would still have all our other stuff. Plus the instruction is public and testable - if Intel did something wrong, they'll be *very* embarrassed.</div>
<div><br></div><div>In other words, there's absolutely no reason not to use it, and allow us to get away from /dev/random running out of entropy. We absolutely should use it for bootup randomness (where we currently are somewhat weak), and I absolutely disagree that it should be made into more of a driver abstraction."</div>
</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><a href="https://lkml.org/lkml/2011/7/30/116" target="_blank">https://lkml.org/lkml/2011/7/30/116</a><br>
</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">It still makes sense if you need so much random data that /dev/random doesn't have sufficient entropy in time to re-seed the PRNG.</div>
</div></div></div></div>