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.
Shabsi On Mon, Feb 14, 2011 at 2:40 PM, Adam Barth <[email protected]> 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. > > Adam > > > On Mon, Feb 14, 2011 at 2:37 PM, Shabsi Walfish <[email protected]> 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 > how > > much entropy is available in the pool. > > Shabsi > > > > On Mon, Feb 14, 2011 at 2:30 PM, Glenn Maynard <[email protected]> wrote: > >> > >> On Mon, Feb 14, 2011 at 5:08 PM, Adam Barth <[email protected]> wrote: > >>> > >>> On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich <[email protected]> > >>> 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 > is > >> low, throw", but they both seem hard to deal with from scripts. There's > no > >> way to know when to try again, and most applications wanting secure > PRNGs > >> don't need this. Even ssh-keygen seems to simply use /dev/urandom > without > >> 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 > would > >> want an asynchronous API in order to wait for entropy (akin to > /dev/random). > >> > >> -- > >> Glenn Maynard > > > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
