Hi, during the ongoing work of adding symmetric crypto interface in iOS[1] we came up with two issues: - we noticed that in the Java impl of the ‘encrypt’ method[2] the IV is passed as a parameter. Not sure but is this done for a reason? Can’t this be passed as a parameter in the constructor and simplify the invoke of just ‘encrypt:data’ ? - the ‘validate’ method[3] in Pbkdf2 class is used from what we have seen mostly in tests, is there a reason from being part in the class signature? Thanks, Christos [1] https://github.com/aerogear/aerogear-crypto-ios/pull/1 [2] https://github.com/aerogear/aerogear-crypto-java/blob/master/src/main/jav... [3] https://github.com/aerogear/aerogear-crypto-java/blob/master/src/main/jav... _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Fri, Oct 18, 2013 at 04:56:24PM +0200, Corinne Krych wrote: > Hello All > > I've just updated the crypto iOS API documentation > https://github.com/corinnekrych/aerogear.org/blob/77ab01e16bd385c7d8a507d... > > I would like to discuss with you the actual symmetric encryption method in the API. Atm, we have: > => Java: > cryptoBox.encrypt(IV, message); > => objective-C > NSData* encryptedData = [cryptoBox encrypt:dataToEncrypt IV:encryptionSalt]; Sorry for breaking the flow, but it's really really important to distinguish an IV from a salt - they're different things for different purposes. > => JavaScript > AeroGear.encrypt( options ); > > I think JavaScript grouping everything (key, IV, data to encrypt) in > options is not the best approach but I like the encrypt method with > only one argument. I rather have options containing key/IV information > and have a separate method encrypt that takes the message to encrypt. This is a place where we respect each language's idiomatism - JS is this way, and I don't think it's a good idea to aim for a one-size-fits-all in this case. > > Something like: > > => Java: > CryptoBox cryptoBox = new CryptoBox(new PrivateKey(SOME_SECRET_KEY), IV); Like I replied to Christos, the IV has to be unique and non-predictable, so this isn't an option. I'm almost 100% sure I'll turn this into factory calls too, stay tuned. > cryptoBox.encrypt(message); It's really common to setup a session based on a key, then just go encrypting stuff with it. So reusing the `CryptoBox` instance is something that is probably a good idea. > => objective-C > cryptoBox = [[AGCryptoBox alloc] initWithKey:key salt:encryptionSalt initializationVector:vector]]; > NSData* encryptedData = [cryptoBox encrypt:dataToEncrypt]; ... > => JavaScript > var options = { > IV: superRandomInitializationVector, > AAD: "whateverAuthenticatedData", > key: generatedKey > }; > AeroGear.setOptions(options); > AeroGear.encrypt(message); That would be a global setting - just think what happens if you create a secure chat app and each user uses a different key... this fails. -- qmx_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Fri, Oct 18, 2013 at 11:52:11PM +0200, Corinne Krych wrote: > Doug, > > Thanks for your reply. > I think one the goal of AeroGear is to provide an unified API across > different platforms even if it brings some challenges… > I'm convinced we can come up with a similar API for encryption. That's exactly what I'm talking about, the APIs are similar, but they should respect the languages' idiomatisms: // JS code x.encrypt({a:'', b:''}); // Java code x.encrypt(a, b); Why should I impose Java style over JS?

-- qmx_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Fri, Oct 18, 2013 at 11:52:11PM +0200, Corinne Krych wrote: > Doug, > > Thanks for your reply. > I think one the goal of AeroGear is to provide an unified API across > different platforms even if it brings some challenges… > I'm convinced we can come up with a similar API for encryption. That's exactly what I'm talking about, the APIs are similar, but they should respect the languages' idiomatisms:

// JS code x.encrypt({a:'', b:''}); // Java code x.encrypt(a, b); Why should I impose Java style over JS? -- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev