<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 19, 2016 at 7:59 PM, Viktor Dukhovni <span dir="ltr"><<a href="mailto:cryptography@dukhovni.org" target="_blank">cryptography@dukhovni.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
What is the crypto community's current state of concern around<br>
RDRAND?  Should Haskell's Crypto avoid seeding exclusively from<br>
RDRAND?<br></blockquote><div><br></div><div>Intel's "DRNG" should not to be trusted if your threat model includes the NSA.  It remains secretive, and simple potential attacks like a "power droop" attack have not been properly addressed by Intel, IMO.  However, if you just need random-looking numbers for simulations, RDRAND is good.</div><div><br></div><div>Clearly, Haskell should include all attackers in its threat model.  If what you say is true, I think the authors of that code should provide an explanation of how this happened.</div><div><br></div><div>I find it disturbing that this same bug keeps showing up.  I found the exact same bug in rngd, the standard Linux deamon for gathering entropy from true random number generators: rngd.  The authors and maintainers of rngd I think owe us an explanation as well.  Has it been fixed yet?</div><div><br></div><div>As for Intel's DRNG, there are no published attacks against it AFAIK, and I doubt there will be any - it is just too difficult to reverse-engineer.  However, it is negligent to build a random number source that could be used for cryptography that relies only on Intel's secretive RNG for entropy. <br></div><div><br></div><div>My best guess is the Intel designers did an honest job of Intel's DRNG, but I never did get a competent answer to how they would defend against a trivial power-droop attack, where the CPU just does a ton of multiplications in a loop for a while.  The incompetent answer provided was that back-to-back inverters naturally provide high power supply rejection.  Now days, this is simply not true, because side-by-side transistors usually have significantly different thresholds.  They could easily counter this problem with large slow transistors, but given the speed they run, clearly they did not.</div><div><br></div><div>Bill<br></div></div></div></div>