Implementation-agnostic crypto module

[garrettr]

Since this extension is written in Javascript, it should be possible to reuse the vast majority of the code for different targets: for example, you could build a Chrome extension, a Firefox add-on, and a Firefox OS app all from the same code base, with only minor modifications for each target. The modifications you would need to make would be to support variation in the UX and variation in available crypto implementations.

I recommend that we define a uniform crypto interface (js/crypto.js) that is agnostic wrt the underlying implementation.

At the moment, it appears that you are using pure-JS impls. of all your crypto functions except for Curve25519, which is running in Native Client. It would be easy to support a cross-platform, pure-JS version of Curve25519 by running an Emscripten-compiled version of curve25519 in a Worker.

Additionally, from a quick scan of the protocol design doc, it appears the following primitives are used:

1. Curve25519
2. HMAC-SHA256
3. HMAC-SHA1
4. AES-CBC
5. AES-CTR
6. PBKDF2
7. HKDF

With the exception of Curve25519, all of these primitives are part of the current Web Crypto spec. If we define a clean, implementation-agnostic crypto module from the beginning, then it would be trivial to take advantage of Web Crypto when it becomes available. Given the current state of efforts for Web Crypto, it seems reasonable to expect it to be available by the end of the year.

As you mention in the README, "I'd be glad to accept a pull that abstracts out the NaCL-specific stuff to optionally use a JS implementation for FF". I'm suggesting we go even slightly more abstract in this issue, to allow a mix-and-match of pure JS, Native Client, Emscripten, and eventually Web Crypto.

[TheBlueMatt]

There is an option to switch between native and some untrusted random implementation of Curve25519 that I found lying around. (it currently is set to default to JS). Also, the libraries that are currently in use have horrendously different APIs and I really want to drop them for Web Crypto (next version of Chromium and soon in FF, I think). Still if you want to pull out the (already reasonably abstracted) low-level crypto code into a separate file, I'd love to merge it :)

[liliakai]

: +1: I was thinking of tackling the abstraction of the curve25519 implementation as my next refactor. Targeting web crypto for everything else sounds like the next logical step. I'm happy to take this on if you're busy, @GarretR.

[garrettr]

@liliakai Go for it! 👍

[TheBlueMatt]

After #16, this should be pretty much done. So I'm just gonna close this.