[whatwg] Cryptographically strong random numbers

[Mark S. Miller]

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