[whatwg] Cryptographically strong random numbers

Glenn Maynard glenn at zewt.org
Wed Feb 16 13:02:22 PST 2011


On Mon, Feb 14, 2011 at 8:03 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> but we're now talking about a pure ECMAScript function so DOM conventions
> shouldn't be applicable.  But consistency with common JavaScript practices
> should be.
>
> If you want to apply it to an already allocated array then making it method
> on Array.prototype would be a more internally consistent way to do it.
>
> Although, I also a bit partial to the string based formulation and I assume
> that relatively small string values should be fairly efficient to allocated.
>
> In either case, it does sound like premature optimization relative to
> everything else that is likely to beging on the the JS code that actually
> uses these random values.
>

This isn't an optimization; it's simply a different design.  Optimization is
one underlying rationale, but not the only one.

I don't think optimization is an important consideration here for crypto,
since you usually don't need a lot of random data to generate a key--often
on the order of a few dozen or hundred bytes.  You're not reading a megabyte
of data to generate a key.  There can be uses for generating large blocks of
randomness for non-crypto, though, of course.

However, it also allows specifying the type of the data to return: whether
the random data should be interpreted as 8-bit arrays, 16-bit arrays, and so
on.  I don't know if that's actually important (havn't seen specific use
cases), but that was another rationale.  I think it was also intended to
avoid encoding 8-bit data in a UTF-16 string.

-- 
Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110216/cdcb6816/attachment.html>


More information about the es-discuss mailing list