+1 !
On 5 January 2013 22:44, E.S. Rosenberg <esr+linux...@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.shap...@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 <p...@goldshmidt.org> wrote: >> >>> On Thu, Jan 3, 2013 at 1:50 PM, Nadav Har'El <n...@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 | p...@goldshmidt.org >>> >>> _______________________________________________ >>> Linux-il mailing list >>> Linux-il@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@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@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
