Native JS Encryption

Mark S. Miller erights at
Fri Mar 18 21:31:48 PDT 2011

On Fri, Mar 18, 2011 at 4:53 PM, Brendan Eich <brendan at> wrote:

> 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 ( ) 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).

"without"? I'm not sure what you mean by this, so I don't know if it's what
I intended to allude to ;).

> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list