On Mon, 2013-10-07 at 16:02 -0300, Bruno Oliveira wrote:
Gist: https://gist.github.com/abstractj/f1229ae075f8e6688c75
+1 for having something coming from the server (entropy) on the alternative scenario

Since the Web Crypto API [1] has not stabilized yet and we will probably face browser compatibility issues when using the window.crypto.getRandomValues [2], having something coming from the server seems to be the best approach.



- Asymmetric encryption support (ECC)

        var hex = sjcl.codec.hex,
            keyPair = new AeroGear.crypto.KeyPair(),
            cipherText, plainText,
            options = {
                IV: superRandomInitializationVector,
                AAD: "whateverAuthenticatedData",
                key: keyPair.publicKey,
                data: ""My bonnie lies over the ocean"
            };
        cipherText = AeroGear.crypto.encrypt( options );
        options.key = keyPair.privateKey;
        options.data = cipherText;
        plainText = AeroGear.crypto.decrypt( options );
Where will the private key be stored (local storage, other options)? Not sure if local storage should be considered an option since it creates a tightly coupled connection between a specific browser and the data stored.

## Android

### Dependencies

- [Spongy Castle](http://rtyley.github.io/spongycastle/) with wrappers
for basic functionalities like: encrypt, decrypt, password salting and
key pair generation.


### Implementation details

- The bouncycastle "provided" in Android doesn't have ECDH that's the
reason why Spongy Castle was chosen.
   
+1 for Spongy Castle

[1]: http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130625/#dfn-RandomSource
[2]: https://developer.mozilla.org/en-US/docs/Web/API/window.crypto.getRandomValues