RNG (was: Re: SSD drives)

[Oleg Goldshmidt]

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