10:41 a.m.
On 11/04/2013 11:30 AM, Daniel Passos wrote:
<#>
The idea is implementing only save(add/update) and delete, using the
stores we already have today by just adding crypt / decrypt and
scheduling Query (readWithFilter) for the next release
+1, Do we have relevant JIRA's which are up to date with respect to query?
*DataManager*
|public Store encryptedStore(String storeName, String passphrase) {
// TODO Create a default passphrase-based KeyStore
KeyStore keyStore = null;
return encryptedStore(storeName, keyStore);
}
public Store encryptedStore(String storeName, KeyStore keyStore) {
StoreConfig storeConfig = new StoreConfig();
storeConfig.setType(StoreTypes.ENCRYPTED_MEMORY);
return encryptedStore(storeName, storeConfig, keyStore);
}
public Store encryptedStore(String storeName, StoreConfig config, String passphrase) {
// TODO Create a default passphrase-based KeyStore
KeyStore keyStore = null;
return encryptedStore(storeName, config, keyStore);
}
public Store encryptedStore(String storeName, StoreConfig config, KeyStore keyStore) {
config.setKeyStore(keyStore);
Store store = storeFactory.createStore(config);
stores.put(storeName, store);
return store;
}|
Maybe it bight be better to extract all of these methods into a factory?
From the user's point of view they would preform something like this
|StoreConfig config = new StoreConfig();
config.setType(ENCRYPTED_MEMORY);
config.setCryptoBox(crypto);
config.setName("encrypted")
EncryptedStore = dataManager.store(config);
|
and have the selecting which encryptedStore method left up to the
library on the back end.
My biggest concern is that having so many possible methods.
*EncryptedMemoryStore*
|public class EncryptedMemoryStore<T> implements Store<T> {
private final MemoryStorage<T> memoryStorage;
private final CryptoUtils<T> cryptoUtils;
public EncryptedMemoryStore(IdGenerator idGenerator, KeyStore keyStore) {
memoryStorage = new MemoryStorage(idGenerator);
cryptoUtils = new CryptoUtils<T>(keyStore);
}
@Override
public StoreType getType() {
return StoreTypes.ENCRYPTED_MEMORY;
}
@Override
public Collection<T> readAll() throws InvalidKeyException {
Collection<T> encryptedCollection = memoryStorage.readAll();
return cryptoUtils.decrypt(encryptedCollection);
}
@Override
public T read(Serializable id) throws InvalidKeyException {
T encryptedItem = memoryStorage.read(id);
return cryptoUtils.decrypt(encryptedItem);
}
@Override
public List<T> readWithFilter(ReadFilter filter) throws InvalidKeyException {
List<T> encryptedList = memoryStorage.readWithFilter(filter);
return cryptoUtils.decrypt(encryptedList);
}
@Override
public void save(T item) {
memoryStorage.save(cryptoUtils.encrypt(item));
}
@Override
public void reset() {
memoryStorage.reset();
}
@Override
public void remove(Serializable id) {
memoryStorage.remove(id);
}
@Override
public boolean isEmpty() {
return memoryStorage.isEmpty();
}
}|
So do we need a KeyStore with an in memory implementation? Since the
data will be wiped every time the app starts, we could just generate the
key on the fly and keep it resident while the store is around. If the
store gets GC'd then we have to fetch the data again anyway.
Alternatively, if we are NOT keeping a reference to the key, how do we
make sure it is only in memory for a little time as possible?
*CryptoUtils*
Here is where the magic happens.
|
public class CryptoUtils<T> {
private final KeyStore keyStore;
public CryptoUtils(KeyStore keyStore) {
this.keyStore = keyStore;
}
public Collection<T> decrypt(Collection<T> encryptedCollection) {
List<T> decryptedList = new ArrayList<T>();
for (T item : encryptedCollection) {
decryptedList.add(decrypt(item));
}
return decryptedList;
}
public List<T> decrypt(List<T> encryptedList) {
List<T> decryptedList = new ArrayList<T>();
for (T item : encryptedList) {
decryptedList.add(decrypt(item));
}
return decryptedList;
}
public T decrypt(T item) {
// TODO Read all fields and decrypt
return item;
}
public T encrypt(T item) {
// TODO Read all fields and encrypt
return item;
}
}|
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev