I am working on a cross platform (JS/iOS/Android) list manager application that persists data through a REST API and I want to ensure that any textual data is properly encrypted on the client side so that there's no way to decrypt the data on server side and in the unfortunate case that the database be stolen it does not worth spending any effort on trying to decrypt it.
Many months of research and trial and error has led me to decide that AES encryption in CBC mode of operation is the best choice for the purpose due to its strength and wide adoption on all platforms. I decided to do key derivation based on OpenSSL's similar algorithm so that I have a reliable command-line tool for testing against the accuracy of my implementation.
The only thing that's left is to somehow ensure the validity of the user-supplied encryption passphrase which will never make it to the server side directly. The best idea that has occurred to me so far is to decrypt several list items after login to test if they can be decrypted properly by applying HMAC hashing on the ciphertext, which in turn requires the storage of the HMAC hash on the server side.
I have a couple of questions:
- is there any other way to securely ensure the validity of the passphrase provided after a successful login?
- is it safe to re-use the same passphrase in AES CBC encryption as a secret key in HMAC hashing of the same encrypted data?
I've seen this TLS thread but I do not need the encryption between a typical client/server setup. In my case the client encrypts the data, stores in the cloud and next time either the same client or another client will decrypt it. Thus, handshakes and such in TLS make not much sense to me.
Note 1: I intentionally call it a "passphrase" above to emphasize it is different from the user password which is validated at log in and is stored as a hash within the user account.
Note 2: On the top of all that, requests will travel through HTTPS. The point of the above is not to ensure transport security but that to restrict data readability to the client side for numerous security benefits.
I appreciate any feedback. Thanks!