RNG (was: Re: SSD drives)

[Amos Shapira]

+1 !


On 5 January 2013 22:44, E.S. Rosenberg <esr+linux-il at g.jct.ac.il> wrote:

> I think xkcd summed it up very well for all those that are afraid of
> secret services, you are the weakest link:
> http://xkcd.com/538/
>
>
> 2013/1/6 Amos Shapira <amos.shapira at gmail.com>
>
>> 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?
>> (one ref:
>> http://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators
>> )
>>
>>
>> On 3 January 2013 11:42, Oleg Goldshmidt <pub at goldshmidt.org> wrote:
>>
>>> On Thu, Jan 3, 2013 at 1:50 PM, Nadav Har'El <nyh at math.technion.ac.il>
>>> wrote:
>>> > On Thu, Jan 03, 2013, Yedidyah Bar-David wrote about "RNG (was: Re:
>>> SSD drives)":
>>> >> RDRAND is also a PRNG, reseeded at most once every 1022 calls, way
>>> >> faster than /dev/urandom (they state 500MiB per second), and you do
>>> not
>>> >> have its source code...
>>> >
>>> > Can anyone give me an example of why on earth anyone would need a
>>> > very high throughput random number generator?
>>> >
>>> > I can understand why things like monte-carlo simulations and ray
>>> tracing
>>> > might need a lot of random numbers, but for them PRNG in the program
>>> > (e.g., rand(3)) is perfectly fine
>>>
>>> It is absolutely lousy for any serious simulation work - it is
>>> absolutely not random, and I know for a fact that in a serious Monte
>>> Carlo it will give you wrong results where a good PRNG will give you
>>> correct ones. In the past I tested many PRNGs on problems I knew the
>>> answer for. The vast majority were rubbish. Those that were very
>>> random (it was before NIST, so I relied on DIEHARD) gave good results.
>>>
>>> Actually, what is needed for simulations is uniform coverage of the
>>> state space, not randomness, which is why low-discrepancy (a.k.a.
>>> quasi-random) numbers work. Lousy PRNGs are not uniformly distributed
>>> (when you plot them the problem can often be seen by the naked eye).
>>> It leads to both lousy simulation results and weak cryptographic
>>> properties. Suitability for simulations does not mean strong
>>> cryptography.
>>>
>>> > for any of these super-duper super-secure generators in the kernel or
>>> the CPU...
>>>
>>> It has to be very random. It has been demonstrated many times how easy
>>> it is to exploit a not very random kernel RNG (guess TCP sequence
>>> numbers and so on). Microsoft: looking at you.
>>>
>>> --
>>> Oleg Goldshmidt | pub at goldshmidt.org
>>>
>>> _______________________________________________
>>> Linux-il mailing list
>>> Linux-il at cs.huji.ac.il
>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>>
>>
>>
>>
>> --
>>  [image: View my profile on LinkedIn]
>> <http://www.linkedin.com/in/gliderflyer>
>>
>> _______________________________________________
>> Linux-il mailing list
>> Linux-il at cs.huji.ac.il
>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>
>>
>


-- 
 [image: View my profile on LinkedIn]
<http://www.linkedin.com/in/gliderflyer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20130105/79227a30/attachment.html>