Native JS Encryption

Shabsi Walfish shabsi at
Fri Mar 18 18:44:49 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.

I'm not convinced that you need native speed even for this (and its a bit
specialized, since it lives in the browser chrome). It sounds like you are
talking about a few MB of data, at most. Native code could probably do that
in something like 10 or 20 ms, and even if you are slower by an order of
magnitude you can do it in 200 ms in JavaScript (and the performance gap
appears to be steadily decreasing at that). Either way, the sync time is
probably dominated by network performance. I expect that approximately the
same would hold true for mobile.

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

Hence you can allow for versioning and backwards compatibility, like most
protocol APIs do.


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list