<div dir="ltr"><div>If someone is really concerned about NSA knowing their random seed through Intel's hardware implementation - can't these few people add hardware RNG's to their sources?<br></div>(one ref: <a href="http://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators">http://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators</a>)<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 January 2013 11:42, Oleg Goldshmidt <span dir="ltr"><<a href="mailto:pub@goldshmidt.org" target="_blank">pub@goldshmidt.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Jan 3, 2013 at 1:50 PM, Nadav Har'El <<a href="mailto:nyh@math.technion.ac.il">nyh@math.technion.ac.il</a>> wrote:<br>
</div><div class="im">> On Thu, Jan 03, 2013, Yedidyah Bar-David wrote about "RNG (was: Re: SSD drives)":<br>
>> RDRAND is also a PRNG, reseeded at most once every 1022 calls, way<br>
>> faster than /dev/urandom (they state 500MiB per second), and you do not<br>
>> have its source code...<br>
><br>
> Can anyone give me an example of why on earth anyone would need a<br>
> very high throughput random number generator?<br>
><br>
> I can understand why things like monte-carlo simulations and ray tracing<br>
> might need a lot of random numbers, but for them PRNG in the program<br>
> (e.g., rand(3)) is perfectly fine<br>
<br>
</div>It is absolutely lousy for any serious simulation work - it is<br>
absolutely not random, and I know for a fact that in a serious Monte<br>
Carlo it will give you wrong results where a good PRNG will give you<br>
correct ones. In the past I tested many PRNGs on problems I knew the<br>
answer for. The vast majority were rubbish. Those that were very<br>
random (it was before NIST, so I relied on DIEHARD) gave good results.<br>
<br>
Actually, what is needed for simulations is uniform coverage of the<br>
state space, not randomness, which is why low-discrepancy (a.k.a.<br>
quasi-random) numbers work. Lousy PRNGs are not uniformly distributed<br>
(when you plot them the problem can often be seen by the naked eye).<br>
It leads to both lousy simulation results and weak cryptographic<br>
properties. Suitability for simulations does not mean strong<br>
cryptography.<br>
<div class="im"><br>
> for any of these super-duper super-secure generators in the kernel or the CPU...<br>
<br>
</div>It has to be very random. It has been demonstrated many times how easy<br>
it is to exploit a not very random kernel RNG (guess TCP sequence<br>
numbers and so on). Microsoft: looking at you.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Oleg Goldshmidt | <a href="mailto:pub@goldshmidt.org">pub@goldshmidt.org</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Linux-il mailing list<br>
<a href="mailto:Linux-il@cs.huji.ac.il">Linux-il@cs.huji.ac.il</a><br>
<a href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il" target="_blank">http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">
<a href="http://www.linkedin.com/in/gliderflyer" target="_blank">
<span>
<img src="http://s4.licdn.com/scds/common/u/img/webpromo/btn_viewmy_160x25.png" alt="View my profile on LinkedIn" height="25" width="160">
</span></a></div>
</div>