There's a massive distinction between in-browser cryptography and native javascript cryptography. The article you linked points out why native crypto in javasri

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/