[whatwg] Cryptographically strong random numbers

Oliver Hunt oliver at apple.com
Wed Feb 16 11:36:18 PST 2011


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.


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



More information about the es-discuss mailing list