- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 22 Feb 2011 19:15:05 -0500
On Tue, Feb 22, 2011 at 6:26 PM, Bill Frantz <frantz at pwpconsult.com> wrote: > On 2/22/11 at 1:36 PM, brendan at mozilla.com (Brendan Eich) wrote: > > However, Math.random is a source of bugs as Amit Klein has shown, and >> these can't all be fixed by using a better non-CS PRNG underneath >> Math.random and still decimating to an IEEE double in [0, 1]. The use-cases >> Klein explored need both a CS-PRNG and more bits, IIRC. Security experts >> should correct amateur-me if I'm mistaken. >> > > I'll see if the security expert hat fits. :-) > > The random() function in many languages has a useful property which is > incompatible with security. By setting its seed, you can get deterministic > execution of a Monte Carlo algorithm. I don't agree that being able to query and set the state of a PRNG is incompatible with security. Most comprehensive, secure PRNG APIs support doing that, eg. LTC's "XXX_import" and "XXX_export" functions. In fact, you can even do that with /dev/urandom in Linux (only as root, since it's shared across users). Neither Math.random nor any of the APIs discussed so far are attempt to be comprehensive APIs, of course. Using Math.random's API for secure random numbers wouldn't make sense, though. Secure random number sources from OS's give bytes, and most (all?) real-world crypto algorithms want bytes (or groups of bytes), so this would just be converting from bytes to floating-point and back to bytes anyway. That's just introducing a lot of new ways to get things wrong. -- Glenn Maynard
Received on Tuesday, 22 February 2011 16:15:05 UTC