<div dir="ltr">Note: I do believe David is honest in his stated opinions here, and I suspect if we were allowed to dig into Intel's DRNG design, we would find nothing sinister.  That said, I feel his opinions stated above are dangerous.<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 22, 2016 at 1:19 PM,  <span dir="ltr"><<a href="mailto:dj@deadhat.com" target="_blank">dj@deadhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
><br>
> On 11/20/2016 12:57 PM, Viktor Dukhovni wrote:<br>
><br>
>> Anyone else care to comment on the wisdom or folly of RDRAND as<br>
>> a principal (sole) seeding mechanism for a TLS stack?<br>
><br>
> Don't do that.  It is folly to rely on any *single* source as a<br>
> seeding mechanism.<br>
><br>
<br>
</span>It's a mixed bag.<br></blockquote><div><br></div><div>AFAIK, there are zero cases of PWNing because servers mixed multiple sources instead of relying on just one.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am one of a handful of people who know for sure that RdRand is secure<br>
because we designed, built and tested it.</blockquote><div><br></div><div>It worries me that you "know for sure" that RdRand is secure.  Do you have the analog background to warrant that confidence?  How do you defend against a simple power droop attack?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Other people have to trust it and their basis of trust should be the<br>
independent audit, researcher reviews and SP800-90 certifications which to<br>
a greater or lesser extent mean people have looked at it and declared it<br>
to be exactly what it claims to be.<br></blockquote><div><br></div><div>From what I can tell, the certifications are largely a joke.  This does not inspire trust.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you instead choose to get your random numbers from your OS, that gets<br>
those random numbers from RdRand, all the OS is doing is adding attack<br>
surface and reducing performance.<br></blockquote><div><br></div><div>Just write your random data to /dev/random, and let it do the mixing.  How does that add to the attack surface?  Mixing multiple sources is good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The OS can provide a useful service by combining multiple sources, but<br>
they have to (a) have those multiple sources (b) know how to get at them<br>
and (c) do it right.<br></blockquote><div><br></div><div>Anybody can write the code to feed potentially random data to /dev/random.  It's easy, and even if you mess up, you have not made things worse.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd point you to a good book on extractor theory, but I haven't finished<br>
writing it yet, sorry and I can't make any guarantees as to whether or not<br>
it is good.<br></blockquote><div><br></div><div>The trick is avoiding buggy software like Haskel and rngd that somehow have bugs that cause them to rely exclusively on RdRand.<br></div><div><br></div><div>Bill<br></div></div></div></div>