Database and End-to-End Encryption

Question

I'm currently designing a mobile/desktop application to synchronize some messages or notes. I'm searching for a way to secure it and to avoid letting the server be able to read the messages.

My goal is to have a client which encrypts a message on the client side, sending it to the server which stores it to the database. Then, if another client on the same account is connected, it will receive the encrypted message, decrypt it and store it in its local cache.

I can't just use one of the standard end-to-end encryption methods because I don't want to have a different key each time I use the application. I want to be able to store the messages in the database.

Another constraint is that I don't want the user to manually manage the keys. I just want a password for the account.

So, a solution I have imagined is to use an asymmetric algorithm like RSA and a symmetric one like Blowfish or CAST. I generate an RSA key pair when the user creates an account, encrypt it with CAST and the user's password as the key, and store the result locally on the phone. Then, the messages are encrypted with the public RSA key, sent to server and stored in the database. To be able to decrypt messages on another client (like on a PC, for example), I just send the encrypted key pair from the phone to the server that sent it back to the new client. The new client can now decrypt the RSA key pair with the user password and decrypt messages stored in the database.

Since I'm pretty new to all this stuff, I don't know whether this is a good idea, or whether there is a better way to do it.

Answer 1

You seem to be inventing your own ad-hoc protocol, without authenticated encryption, and using old algorithms with known security weaknesses such as small block size.

I strongly suggest you use a high level modern library such as libsodium and use its crypto_box function for authenticated encryption, as well as Argon for password key derivation to protect the private keys. This will supply fast modern authenticated encryption (which your proposed solution would not provide). There are libsodium "wrappers" for most popular high-level programming languages.

It is much more difficult to go wrong using a known-good, high-level toolbox such as libsodium. With out using something more pre-built, you will have to decide on many security-critical details which are easy to get wrong such as: symmetric modes, authentication mechanisms for your cipher text, padding, key generation, nonce generation and re-use protection, key-wrapping, padding, side-channel resistance, and encoding.

You will still have to compose a few high-level building blocks for your application with something like libsodium, but it won't be nearly as difficult or error-prone.