> Right now the EncryptedSQLStore can be opened with any passphrase and it only throws an InvalidKeyException when readAll is called. I see two major issues in this behavior.

Hi Tadeas Kriz, maybe we have some workflow issue here, not sure, must be checked. The correct workflow to our initial release was supposed to be:

1 - User inputs the passphrase
2- Add a ton of data and the application encrypts that data
3- Next the passpharase is inserted, the application should try to decrypt that storage with the passpharase provided.
4. If InvalidKeyException raises, forbbid the that login

I guess this is mostly what passos did for our demo. The reason why we don't validate passwords, is because they can't be stored on devices, otherwise it could be leaked.

> 1) It's confusing for developers and requires them do one more step. The store should not get opened if the passphrase is wrong.

What would you recommend? Is necessary to open the storage and try to decrypt it, I can be wrong.

> It also leads to a problem I've discovered:
> Open datastore with one passphrase. Insert some data into it. Close the datastore. Open it with another passphrase. Insert some data into it. That way you can no longer call readAll, as it won't work for any of the two passphrases. This means that the write method doesn't depend on the passphrase being right or wrong. It just writes the data with the current one.

It might be some issue with the workflow, what we planned was:

1 - Open that storage with passpharse: "abracadabra"
2- Encrypt the about of data inserted by that user
3- Closes the application
4- Open the application again and try to decrypt that data with the same passhparse, otherwise throw thousand of errors at the screen

As far as I know we don't have any feature atm for passpharse change.

> 2) Performance bottleneck. Having to read all the entities from the database is expensive. Also if they're just thrown away right after the reading, GC kicks in and halts the code execution for a while.

We are aware of it, our major goal was to lay down the groundwork for encryption first and take care of queries on data storage later, be patient my friend. Two things are completely trick for mobile devices: queries for data storage and worse, querying encrypt data, so one step at time.

>Possible implementation:
> When the store is created, save some metadata entity at the first row. It might probably be completely random data, as we'll be only interested in reading it and deciding if the passphrase was right (similar to what readAll does). If it's not right, throw an InvalidKeyException right when the store is being opened. That way, developers will be sure that if the store has been opened, it's safe to read and write to it.

I wouldn't add some trash to the local storage of mobile phones only because we need a workaround to skip one step. If yo u look at libraries like SQLCipher, you need to open the storage to decrypt that data, there's no simple answer for it.