Hi, thanks for sharing, some questions I have: - I guess the CryptoConfig will be a stand-alone class which can be applied as a param to the existing ‘StoreConfig’ and ‘PipeConfig’ (later on), right?

Based on a previous email discussion [1], how this looks from the client? Is it sth like this: // crypto configuration CryptoConfig cryptoConfig = new PasswordProtectedKeystoreConfig(); cryptoConfig.setAlias("myalias"); cryptoConfig.setKeystoreFileName("app.keystore"); cryptoConfig.setPassword("somePassword"); // store configuration StoreConfig config = new StoreConfig(); config.setType(ENCRYPTED_MEMORY); config.setName("encrypted”) // apply crypto config config.setCryptoConfig(cryptoConfig); // build store EncryptedStore = dataManager.store(config); Further, I guess Pbkdf2 can be used as: cryptoConfig.setPassword(AeroGearCrypto.pbkdf2().encrypt(“passphrase-entered-by-user”));

As I understand, the passphrase is used only to unlock the keystore and _not_ for encrypt/decrypt of data. Then the private/public keys are generated and stored in the keystore which can be accessed later. A benefit for this as I see is that you don’t need to reencrypt the data if the passphrase is changed. Only decrypt keystore (old-passphrase) and update keystore (with the new passphrase). - apart from ‘PasswordKeyServices’ which unlocks the 'keystore based on a password, what other impls of KeyServices are in mind?

- apart from keys, IV is a param needed to encrypt, not shown yet but I guess this should be stored on the keystore too and be accessible from the client when does ‘encrypt’/‘decrypt’.

Thanks, Christos [1] http://lists.jboss.org/pipermail/aerogear-dev/2013-November/005213.html On Nov 5, 2013, at 10:00 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > One of the things we briefly discussed on the chat was key generation > and secret storage. > > For Android we want to combine the two in an "easy" API which follows > the Object/Factory/Config patterns of our other systems (Pipeline, > Authentication, Push). > > Here is a high level code flavored example of what I am talking about. > > https://gist.github.com/secondsun/d602d19255b1fd085ac8 > > Actual work is going forward here: > https://github.com/secondsun/aerogear-android/tree/security > > wdyt? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Ok so I updated a little bit: So KeyService is now EncryptionService. https://github.com/secondsun/aerogear-android/blob/security/src/org/jboss... Usages are here : https://gist.github.com/secondsun/c1fb32a4c49f9bb6bed2 KeyManager is in Process. Here are links to the classes for my impls of EncryptionService https://github.com/secondsun/aerogear-android/blob/security/src/org/jboss... https://github.com/secondsun/aerogear-android/blob/security/src/org/jboss... https://github.com/secondsun/aerogear-android/blob/security/src/org/jboss... On 11/05/2013 03:00 PM, Summers Pittman wrote: > One of the things we briefly discussed on the chat was key generation > and secret storage. > > For Android we want to combine the two in an "easy" API which follows > the Object/Factory/Config patterns of our other systems (Pipeline, > Authentication, Push). > > Here is a high level code flavored example of what I am talking about. > > https://gist.github.com/secondsun/d602d19255b1fd085ac8 > > Actual work is going forward here: > https://github.com/secondsun/aerogear-android/tree/security > > wdyt? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 11/06/2013 07:06 AM, Christos Vasilakis wrote: Hi, thanks for sharing, some questions I have: - I guess the CryptoConfig will be a stand-alone class which can be applied as a param to the existing ‘StoreConfig’ and ‘PipeConfig’ (later on), right? I'm not 100% sure on that, but it is something passos and I have talked about.

Based on a previous email discussion [1], how this looks from the client? Is it sth like this: // crypto configuration CryptoConfig cryptoConfig = new PasswordProtectedKeystoreConfig(); cryptoConfig.setAlias("myalias"); cryptoConfig.setKeystoreFileName("app.keystore"); cryptoConfig.setPassword("somePassword"); // store configuration StoreConfig config = new StoreConfig(); config.setType(ENCRYPTED_MEMORY); config.setName("encrypted”) // apply crypto config config.setCryptoConfig(cryptoConfig); // build store EncryptedStore = dataManager.store(config); Further, I guess Pbkdf2 can be used as: cryptoConfig .setPassword(AeroGearCrypto.pbkdf2().encrypt(“passphrase-entered-by-user”)); It will probably look more like your first block than your second block. In the second block we will probably have something similar to this: // crypto configuration CryptoConfig cryptoConfig = new Pbkdf2Config(); cryptoConfig.setSalt("myalias"); cryptoConfig.setPassword("app.keystore"); KeyServices service = manager.keyService(cryptoConfig); CryptoBox crypto = service.getCrypto(context, cryptoConfig); `service` in this case will be a Pbkdf2Service which will generate the key based on your config. As I understand, the passphrase is used only to unlock the keystore and _not_ for encrypt/decrypt of data. Then the private/public keys are generated and stored in the keystore which can be accessed later. A benefit for this as I see is that you don’t need to reencrypt the data if the passphrase is changed. Only decrypt keystore (old-passphrase) and update keystore (with the new passphrase). - apart from ‘PasswordKeyServices’ which unlocks the 'keystore based on a password, what other impls of KeyServices are in mind? See Pbkdf2Service above as an example. - apart from keys, IV is a param needed to encrypt, not shown yet but I guess this should be stored on the keystore too and be accessible from the client when does ‘encrypt’/‘decrypt’. I feel like how you handle the IV is a application specific thing not a library specific thing. For example, in the case of a EncryptedMemoryStore it will only be stored in memory with the EncryptedStore. Once the Store gets garbage collected the IV will go away as well. In the case of long running encryption, the IV will need to be stored with the encrypted message to recover it. We can provide utilities or best pratice docs for that. As an aside, the Keystore (java.security.Keystore) can not store the IV as far as I can tell. Thanks, Christos [1] http://lists.jboss.org/pipermail/aerogear-dev/2013-November/005213.html On Nov 5, 2013, at 10:00 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: One of the things we briefly discussed on the chat was key generation and secret storage. For Android we want to combine the two in an "easy" API which follows the Object/Factory/Config patterns of our other systems (Pipeline, Authentication, Push). Here is a high level code flavored example of what I am talking about. https://gist.github.com/secondsun/d602d19255b1fd085ac8 Actual work is going forward here: https://github.com/secondsun/aerogear-android/tree/security wdyt? _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev