<div dir="ltr"><div>Links below taken from <a href="https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide">https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide</a></div><div><br></div><div>Here's a diagram which shows what we're offered:</div><div><br></div><div>  <a href="https://software.intel.com/sites/default/files/managed/49/ec/DRNG_img02.jpg">https://software.intel.com/sites/default/files/managed/49/ec/DRNG_img02.jpg</a><br></div><div><br></div>Arnold is saying that if we had access to the output of "Hardware Entropy Source" it might be possible to verify the quality of that data, and to get confidence that the intervening steps aren't subverted by default. As it is, we have a black box, and there's nothing that prevents some secret trigger wiring the DRBG input to a counter.<div><br></div><div>The black box does its own testing which is exposed by the carry flag:</div><div><br></div><div>  <a href="https://software.intel.com/sites/default/files/managed/15/85/DRNG_img04.jpg">https://software.intel.com/sites/default/files/managed/15/85/DRNG_img04.jpg</a></div><div><br></div><div>The "Online Entropy Health Tests" have a 256*256bit buffer of entropy, which is used to sanity check the input and return an error, but which isn't exposed outside of test processors. This also means the DRNG will by design fail and return 0 for an uncontrollable subset of inputs.</div><div><br></div><div>There's some more detail in <a href="http://www.rambus.com/wp-content/uploads/2015/08/Intel_TRNG_Report_20120312.pdf">http://www.rambus.com/wp-content/uploads/2015/08/Intel_TRNG_Report_20120312.pdf</a> (search for "mostly stuck at 1" for an interesting point).</div><div><br></div><div><br></div><div>Mark</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 26, 2016 at 5:41 AM, 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"><span class=""><br>
> On Nov 25, 2016, at 3:55 PM, Arnold Reinhold <<a href="mailto:agr@me.com">agr@me.com</a>> wrote:<br>
><br>
> In addition the need for a proper published audit that bear suggested, the most glaring defect in the Intel design is the lack of access to the un-whitened random bits. Adding a mode that bypassed the whitener would have been simple. Statistical analysis of the raw bit stream can provide ongoing assurance that the RNG is doing what it says. Likely there will be correlations between raw bit statistics and external parameters such as chip temperature and supply voltage. Of course it is possible for a deterministic generator to mimic such variations, but it would have to have a relatively large footprint on the die compared to simply using the whitener in a feedback mode or similar mischief.<br>
<br>
</span>It seems you're hinting at:<br>
<br>
    <a href="https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed" rel="noreferrer" target="_blank">https://software.intel.com/en-<wbr>us/blogs/2012/11/17/the-<wbr>difference-between-rdrand-and-<wbr>rdseed</a><br>
    <a href="https://en.wikipedia.org/wiki/RdRand" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>RdRand</a><br>
<br>
RDSEED first appears in Broadwell CPUs, while RDRAND appears earlier in Ivy Bridge.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
        Viktor.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank">http://www.metzdowd.com/<wbr>mailman/listinfo/cryptography</a></div></div></blockquote></div><br></div>