Shabsi Walfish writes: > I don't disagree with this -- however, I would say the problem is that > urandom may not return 160 "unguessable" bits to start with. Unguessable, of > course, actually means "extremely difficult to predict with better than > probability 1/2, conditioned on all previously observable information (such > as approximate system time, process ids, etc.)". In any case, I was simply > suggesting it would be nice to make available information about the quality > of the entropy being returned by /dev/urandom, which is either going to be > good (because the entropy pool was full) or _possibly_ not good (perhaps > because the entropy pool hasn't ever filled up yet).
Well, personally I don't see any need, and I think it's an unnecessary distraction. I don't see anything that should hold up window.crypto.getRandom. I don't think this even rises to the level of nice-to-have, but even if it did, I think the window.crypto.getRandom effort should focus on must-haves, and not get hung up on nice-to-haves. To explain why I don't think there's any reason to add a way to query the quality of the pseudorandomness returned by /dev/urandom, I have to geek out on cryptographer stuff. To all the non-cryptographers: please ignore the crypto geeking out. The bottom line is, I think /dev/urandom is fine, I think it's perfectly adequate for the job, and I see no basis for delaying or complicating the window.crypto.getRandom API. < cryptographer geek-out > In my opinion, there's no need to check on the quality of /dev/urandom; returning unguessable bits is its entire job and purpose for being. There's a great deal of FUD and misunderstandings out there about /dev/urandom, partly based upon a confusion between information-theoretic security and computational-infeasibility security. It's not helped by the fact that even the /dev/urandom man page lends support to the misconceptions. Here's the issue. /dev/urandom is computationally secure. No, it's not information-theoretically secure, but who cares? Information theoretic security is irrelevant in practice; it's basically only a concern for theoretical la-la land. (Do we reject all modern cryptography, and insist that only the one-time pad is good enough for us? Of course not. That'd be ridiculous.) /dev/urandom is a PRNG, not a RNG, and that's plenty good enough for all the use cases we're talking about. If you hear someone talk about a concern that the "entropy pool might get drained", that's irrelevant to /dev/urandom. That'd only be relevant if we were talking about information-theoretic security -- but we're not. With a computationally-secure PRNG like /dev/urandom, once it's got 160 bits of unguessable entropy in its pool, it's good forever. What about the concern that the entropy pool might never have gotten enough entropy in the first place? I think that's exceedingly unlikely on any system that will be running a browser. In every OS distribution I've ever seen, there is a mechanism to ensure that entropy carries over across boots: usually a shutdown-time script that dumps /dev/urandom's entropy pool to disk, and a boot-time script that reads this saved pool and adds it to the entropy pool. Thus, as long as the /dev/urandom pool ever has enough entropy, it always will from there on, including after every subsequent boot. What about on first boot? Personally, I strongly expect that by the time the browser gets going and Javascript gets a chance to query this interface, there will be sufficient entropy in the /dev/urandom pool. If we're talking about a browser, then it's probably running on a machine with peripherals (e.g., keyboard, mouse, touch screen, or something along those lines). In general, I suspect /dev/urandom is very unlikely to be the weakest point in the system. < / cryptographer geek-out > So, coming back to the discussion: I don't see any barriers to window.crypto.getRandom. As far as I can tell, modern OSes offer enough support for getting randomness that it should not be difficult for browsers to obtain the necessary randomness needed to implement window.crypto.getRandom. And I think it's perfectly adequate to have a simple interface that exposes only one function: get some crypto-quality random bytes. I don't see a need for a more elaborate API. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
