[whatwg] Cryptographically strong random numbers

David Herman dherman at mozilla.com
Wed Feb 16 11:51:46 PST 2011


An almost-conformant implementation that does not support one single function in the standard API can generally claim "conformant except for X" so I'm not too worried about such non-web cases.

Dave

On Feb 16, 2011, at 11:46 AM, Mark S. Miller wrote:

> 
> 
> 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 there*.
> 
> This is of course entirely ignoring timing attacks, and other such side channels.
> 
> --Oliver
> 
> * 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 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.
> >
> > 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,
> > good enough for any signing key that's going to be used in Javascript.
> > 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
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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


More information about the es-discuss mailing list