On Mar 18, 2011, at 12:56 PM, Shabsi Walfish wrote: > I'm not convinced that this use case, or any other use case I could think of > for the web (with the possible exception of DRM/encryption on streaming > media), would really benefit from speed. On the whole, you would most likely > be encrypting fairly small quantities of data, and any larger quantities of > data would typically be handled in a context where the encryption/decryption > can even be done asynchronously. Even on a mobile phone, a few blocks of AES > could probably done in pure JS without noticeable delay. Have you done any > experiments with SJCL ( http://crypto.stanford.edu/sjcl/ ) for example?
In support of Robert's point, we have Firefox Sync [1], which client-side encrypts many blocks of user data (not just passwords; cookies, history, etc.) to hide it from our own (or an alternative; the server is open source) sync service. This needs native speed, which we provide via privileged-JS-only (our so-called "chrome" user-interface JS) access to our native crypto module (NSS). The volume in blocks and bytes requires it. Using pure-JS crypto lowers performance an order of magnitude or two. To your point about the API being "best, most current" crypto-standard (for a given key size, perhaps): that is usable but often in our modern era, JS clients must chat with JS server peers using precisely *this* or *that* crypto protocol. So I imagine we'll need both kinds of APIs: best-latest and exactly-this. Mark Miller alluded to a crypto API task group without Ecma TC39. I'm open to it, provided we can include some of the domain experts who have participated on this list (but who may not be employed by Ecma members). /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
