On Mon, 2013-10-07 at 16:02 -0300, Bruno Oliveira wrote:
+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.getRandomV...