[whatwg] Cryptographically strong random numbers
shabsi at google.com
Mon Feb 14 14:46:50 PST 2011
This depends on what you consider to be the basic use case. Generating
long-lived cryptographic keys absolutely requires high quality entropy... if
you are only generating short-lived authenticators (that are not used for
encryption) then you could get away with weaker entropy. You will get the
most mileage out of this feature if it can be used to generate encryption
keys, or long-lived signing keys.
On Mon, Feb 14, 2011 at 2:40 PM, Adam Barth <w3c at adambarth.com> wrote:
> IMHO, that's not needed for the basic use case. I'd like to punt all
> non-essential use cases to the ES-Harmony feature-rich take on a
> crypto library.
> On Mon, Feb 14, 2011 at 2:37 PM, Shabsi Walfish <shabsi at google.com> wrote:
> > It'd be nice if there was at least a way to explicitly detect if you were
> > getting "weaker" entropy... In linux, for example, there is a /proc
> > filesystem entry (/proc/sys/kernel/random/entropy_avail) that indicates
> > much entropy is available in the pool.
> > Shabsi
> > On Mon, Feb 14, 2011 at 2:30 PM, Glenn Maynard <glenn at zewt.org> wrote:
> >> On Mon, Feb 14, 2011 at 5:08 PM, Adam Barth <w3c at adambarth.com> wrote:
> >>> On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich <brendan at mozilla.org>
> >>> wrote:
> >>> > On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
> >>> > > Ok. I'll write up a spec later today.
> >>> >
> >>> > Thanks.
> >>> Done: http://wiki.whatwg.org/wiki/Crypto
> >>> Feedback appreciated.
> >> > If insufficient cryptographically random values are available,
> >> > getRandomValues does not alter array and throws a NOT_SUPPORTED_ERR
> >> I'm not sure if this means "if you're using /dev/random and it would
> >> block, throw", or "if the amount of entropy in the PRNG's entropy pool
> >> low, throw", but they both seem hard to deal with from scripts. There's
> >> way to know when to try again, and most applications wanting secure
> >> don't need this. Even ssh-keygen seems to simply use /dev/urandom
> >> worrying about it returning low-entropy randomness.
> >> I think it makes more sense to imply /dev/urandom's behavior: always
> >> return data, even if the entropy pool is low. If there's a need for
> >> randomness with that stronger guarantee of entropy, that seems like it
> >> want an asynchronous API in order to wait for entropy (akin to
> >> --
> >> Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss