Is automatic E2E encryption possible for chat apps with a backend DB?

Question

This question refers to automatic E2E encryption (i.e., the app creates and shares encryption keys, never the user).

Apps such as Discord and Hangouts store messages in a server-side DB thereby allowing users to delete the app without losing messages. Apps such as WhatsApp and Signal store messages on the user's device thereby limiting usage to a single installation of an app at any given time.

In an app where the users create and share encryption keys, the key would be kept constant, and if the user loses the key, previously encrypted messages would be lost. However, in an app which automatically performs E2E encryption, the keys cannot be constant because they can never be stored once per account since that'd void the point of the server not having the key. Is it possible for an app storing messages on a server-side DB to implement automatic E2E encryption?

Answer 1

It is possible, but with downsides.

As always, the security of this depends on your threat model. A possible way to implement it is to generate an asymmetric key pair upon first install of the app, then encrypt the key with a password chosen by the user (which must be different from their normal authentication password). Finally, the encrypted private key and the public key are sent to the server.

This allows users to re-install the application or install the application on multiple devices, since they have access to the private key by decrypting what they receive from the server. Furthermore, the messages sent to other users can be stored on the server in encrypted form.

What are the downsides?

If you don't trust the application developers, then generating a private key using their application or importing a self-generated private key into their application means potential key compromise. In other words, you cannot be certain that their app does not send the private key to the developers for malicious purposes. In fact, it is incredibly difficult next to impossible for developers to write an application which they can prove without a shred of a doubt to not be malicious.

If you are worried about third-parties (hackers, nation state actors, etc.) accessing the server with the encrypted messages, then this approach has downsides in comparison to "plain E2E" as described above. Namely, the attacker has access to all private keys, albeit encrypted, and can work on decrypting each of them. At least some of them are bound to have weak passwords.