W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] Cryptographically strong random numbers

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 16 Feb 2011 16:02:22 -0500
Message-ID: <AANLkTi=ZoFVwAT5cbM_7tXiueGGtiD+HahXe42Dxc-zG@mail.gmail.com>
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
Received on Wednesday, 16 February 2011 13:02:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC