[whatwg] Cryptographically strong random numbers
Mark S. Miller
erights at google.com
Wed Feb 16 11:46:05 PST 2011
On Wed, Feb 16, 2011 at 11:36 AM, Oliver Hunt <oliver at apple.com> wrote:
> I agree with this sentiment, the specification should simply state "the
> returned values are guaranteed to be cryptographically secure", that's all
> that needs to be said. There is no need to describe how this is
> implemented, if an implementation provides predictable values then that
> implementation is broken. If your prng has low entropy it is not
> cryptographically secure, and therefore broken. How you get to
> cryptographically secure isn't really relevant as long as you can get
> This is of course entirely ignoring timing attacks, and other such side
> * If a platform can't provide cryptographically secure random i'd be
> concerned about that implementation being web facing as i would be dubious
> of the theoretical security of its SSL implementation, etc.
Hi Oliver, not disagreeing with anything you said. But in light of this
footnote, I want to remind everyone that JS is not necessarily web facing.
Normative EcmaScript standards impose an obligation on any implementation
wishing to claim standards conformance. That said, I support adding this
normative obligation on all conformant EcmaScript implementations.
> On Feb 16, 2011, at 10:40 AM, David Wagner wrote:
> > [re-sending to es-discuss]
> > Shabsi Walfish wrote:
> >> 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
> >> encryption) then you could get away with weaker entropy. You will get
> >> most mileage out of this feature if it can be used to generate
> >> keys, or long-lived signing keys.
> > Personally, I think discussion about the "quality" of the PRNG is a
> > distraction. The PRNG should produce crypto-quality random numbers.
> > Period. That's all that need be said. That's good enough. It's good
> > enough for short-lived authenticators, good enough for encryption keys,
> > It's just plain good enough.
> > There's no need for an interface to request or query or specify the
> > quality or entropy of the random numbers. Callers should be able to
> > rely upon it to be crypto-quality. Browsers can deliver on that.
> > My advice is: Keep the API as simple as it possibly can be. Don't get
> > distracted with twirly knobs and added complications. A simple API will
> > be plenty to get the job done. Stay on target.
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss