3 ms·

Google's end-to-end email encryption

3 points by cdvonstinkpot 12y ago

SwellJoe 12y ago
This is something I've been interested in for a while, but have been somewhat dissuaded by articles like http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ But, it seems reasonable that a browser extension would not be subject to those issues. Since I don't have the cryptography chops to tackle this myself, I'm glad Google is on it. I'd want to see it in Firefox, too, before building products for it...but, one step at a time.
- bostik 12y ago
  There's a massive distinction between in-browser cryptography and native javascript cryptography. The article you linked points out why native crypto in javasript is such a bad idea. One extra point which the page doesn't exactly press on, and which may or may not be entirely theoretical... * Constant-time operations are exremely tricky. The JIT engines are improving/changing from version to version, and you just cannot be sure that some versions do not sneakily optimise some operations based on the data they operate on. An improvement in JIT engine can become a regression for native javascript crypto, and your constant-time compare suddenly becomes a timing oracle under some versions. As for in-browser cryptography, have a look at [0] instead. At least with that the idea is to expose cryptographic operations from the OS libraries to the browser, to be used via javasript. However, the CryptoAPI is not something you'd ever want a developer to use directly. The thing is literally exporting non-abstracted cryptographic operations, and using this API is an invitation to making all the mistakes in applied cryptography you can think of. (And an even greater number of mistakes you could not think of!) So, until we have a universal standard for properly abstracted and secure-by-design (like NaCl [1]) developer friendly operations, in-browser crypto remains a dangerous minefield. You don't want to go there, and you certainly don't want to take anyone else on it either. 0: http://www.w3.org/TR/WebCryptoAPI/ http://www.w3.org/TR/WebCryptoAPI/ 1: http://nacl.cr.yp.to/ http://nacl.cr.yp.to/

3 points by cdvonstinkpot 12y ago

This is something I've been interested in for a while, but have been somewhat dissuaded by articles like http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ But, it seems reasonable that a browser extension would not be subject to those issues. Since I don't have the cryptography chops to tackle this myself, I'm glad Google is on it. I'd want to see it in Firefox, too, before building products for it...but, one step at a time.

bostik 12y ago
There's a massive distinction between in-browser cryptography and native javascript cryptography. The article you linked points out why native crypto in javasript is such a bad idea. One extra point which the page doesn't exactly press on, and which may or may not be entirely theoretical... * Constant-time operations are exremely tricky. The JIT engines are improving/changing from version to version, and you just cannot be sure that some versions do not sneakily optimise some operations based on the data they operate on. An improvement in JIT engine can become a regression for native javascript crypto, and your constant-time compare suddenly becomes a timing oracle under some versions. As for in-browser cryptography, have a look at [0] instead. At least with that the idea is to expose cryptographic operations from the OS libraries to the browser, to be used via javasript. However, the CryptoAPI is not something you'd ever want a developer to use directly. The thing is literally exporting non-abstracted cryptographic operations, and using this API is an invitation to making all the mistakes in applied cryptography you can think of. (And an even greater number of mistakes you could not think of!) So, until we have a universal standard for properly abstracted and secure-by-design (like NaCl [1]) developer friendly operations, in-browser crypto remains a dangerous minefield. You don't want to go there, and you certainly don't want to take anyone else on it either. 0: http://www.w3.org/TR/WebCryptoAPI/ http://www.w3.org/TR/WebCryptoAPI/ 1: http://nacl.cr.yp.to/ http://nacl.cr.yp.to/