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 <[email protected]> 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 > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Cheers, > --MarkM > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
