Native JS Encryption

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


On Fri, Mar 18, 2011 at 4:53 PM, Brendan Eich <brendan at mozilla.com> 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 ( 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).
>

"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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110318/04b121b6/attachment-0001.html>


More information about the es-discuss mailing list