- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 05 Feb 2011 22:54:35 -0500
On 2/5/11 10:22 PM, Roger H?gensen wrote: > The "bad script" is already inside the house anyway, but just in the > other room right? Whatever that means. > This is just my oppinion but... If they need random number generation in > their script to be cryptographically secure to be protected from another > "spying" script... > then they are doing it wrong. Use HTTPS, issue solved right? No. Why would it be? > I'm kinda intrigued about the people you've seen asking, and what exactly it is > they are coding if that is an issue. *laughs* You may want to read these: https://bugzilla.mozilla.org/show_bug.cgi?id=464071 https://bugzilla.mozilla.org/show_bug.cgi?id=475585 https://bugzilla.mozilla.org/show_bug.cgi?id=577512 https://bugzilla.mozilla.org/show_bug.cgi?id=322529 and then you'll know everything I know about the problem. ;) > Besides, isn't there several things (by WHATWG even) that prevents such > spying or even makes it impossible? Do read the above bug reports. > But with the multithreaded and multicore CPU's, clock variations, and so > on, trying to exploit the pattern in say a Mersienne Twister PRNG Which is a heck of a lot harder to guess than the PRNG Math.random actually uses in Gecko, fwiw. > by pulling lots of random numbers > would either A. not work or B. cause a suspicious 100% cpu use on a core. Suspicious to whom? Most users don't watch their CPU usage; they have better things to do with their time! > And don't forget that browsers like Chrome runs each tab in it's own > process, which means the PRNG may not share the seed at all with another > tab Well, yes, that's another approach to the Math.random problems. Do read the above bug reports. -Boris
Received on Saturday, 5 February 2011 19:54:35 UTC