This may interest you if you haven't seen it already (NaCL compiled into 
ASM.js):

http://blog.opal.io/crypto-in-the-browser.html

- Paul



On Nov 21, 2013, at 10:45 AM, Daniel Roesler wrote:

>> This is the exact problem that TLS (HTTPS, WebSockets over TLS, etc.) solves.
> 
> Sometimes you want to encrypt some data locally, so if your phone gets
> stolen, you don't expose that data.
> 
> SJCL is probably the best AES javascript library right now, but it
> doesn't include other things like RSA[1], blowfish, bcrypt[2], or
> scrypt[3].
> 
> I'm itching to try compiling parts of openssl into asm.js to see how
> it compares in performance. Has anyone tried this?
> 
> [1] - http://www-cs-students.stanford.edu/~tjw/jsbn/
> [2] - http://code.google.com/p/javascript-bcrypt/
> [3] - https://github.com/tonyg/js-scrypt
> 
> Daniel
> 
> On Wed, Nov 20, 2013 at 3:23 PM, Brian Smith <[email protected]> wrote:
>> On Wed, Nov 20, 2013 at 3:12 PM, jose llopis <[email protected]> wrote:
>>> i was wondering how to safe cipher my data on the client for sending it to a
>>> server, getting a response and doing something with the returned (also
>>> ciphered) data ??
>> 
>> This is the exact problem that TLS (HTTPS, WebSockets over TLS, etc.) solves.
>> 
>> Note that when you send the encrypted data to the server, the server
>> has to know what encryption key to use to decrypt the data from the
>> client and the key to use to encrypt the data it sends back to the
>> client. This is what public key cryptography (RSA, ECDSA, ECDH, etc.)
>> is for. And, in order to be useful, encryption has to be
>> authenticated. This is what certificates are for.
>> 
>> TLS puts all of these things together into an easy to use package that
>> can be used for most things.
>> 
>> If you need something specialized that won't allow you to use TLS and
>> you really need AES, then there are some JS crypto APIs you can use,
>> such as [1]. I've never used them but others at Mozilla have. Still, I
>> recommend avoiding this type of approach if possible, as there are
>> limitations regarding how secure these implementations can be. For
>> example, they are prone to timing attacks.
>> 
>> At some point, we may have some built-in APIs for crypto primitives in
>> Gecko, but now we don't.
>> 
>> [1] http://crypto.stanford.edu/sjcl/
>> 
>> Cheers,
>> Brian
>> --
>> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
>> _______________________________________________
>> dev-b2g mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-b2g
> _______________________________________________
> dev-b2g mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-b2g

_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to