End-to-end encryption with multiple recipients?

Question

As far as I understand, end-to-end encryption is used to encrypt the content on the client (sender), send it to the server and decrypt it on the client (recipient). The clients store their private keys on the device and the Server stores the public keys for the encryption.

My idea: Request the public keys from the server, encrypt the data, send it to the Server and store it in a database. The client loads the content from the database and encrypts it with the device.

In my scenario I would like to have x Android tablets which should read the content. So there are multiple recipients.

Does end-to-end encryption make sense? How should I share the private key and should it be shared? I thought about scanning a QR code from a central device. And what happens if the user installs the app and loses the private key? Will the encrypted data be lost? And is there a way to prevent this situation?

Answer 1

My idea: Request the public keys from the server, encrypt the data, send it to the Server and store it in a database. The client loads the content from the database and encrypts it with the device.

If the server simply provides the public keys of a specific client to other clients - how does the client know that this is the correct key? A malicious server might just return a key owned by the server instead of the real users key. Then receive the message, decrypt it (since it has its own key) and encrypt it again for the real recipient (since it has the recipients key too).

It is better to provide a way for users to share the public keys without trusting a potentially malicious or compromised server. This might be done by sharing keys using existing secure and trusted channels or by validating retrieved keys using trust structures like Public key infrastructure or Web of Trust.

How should I share the private key and should it be shared? I thought about scanning a QR code from a central device.

It is in general not a good idea to share a private key. But if all devices belong to you and you and only you have full control over it, then it might be ok. Note that you need to consider the case that you loose control over a device and thus the attacker might now have the private key, and has thus access to all previous messages encrypted with the matching public key. Forward secrecy helps to limit the impact of a compromised key.

And what happens if the user installs the app and loses the private key? Will the encrypted data be lost?

The encrypted data are not lost. But they cannot be decrypted anymore.

And is there a way to prevent this situation?

Make sure the private key does not get lost, like having a secure backup, i.e. well protected against unauthorized access.

Answer 2

Does end-to-end encryption make sense?

Sure

How should I share the private key and should it be shared?

How is up to you but it would need to be shared or the plain text encrypted separately for every device.

And what happens if the user installs the app and loses the private key? Will the encrypted data be lost?

Yes, it will be lost. If one cares about end to end encryption this is exactly what one should want.

And is there a way to prevent this situation?

The private portion of the key could be stored on the server encrypted and the user knows something which decrypts it. For example, using PBKDF, which turns a password into a symmetric key. It's secrets all the way down though, if they forget their password then that's it.

Answer 3

Does end-to-end encryption make sense?

It depends. It will prevent the server (and its admins) from snooping on the data from the users, and at the same time prevent them from helping decrypt data if the encryption key is lost.

End to End Encryption can be a source of headache if your service is used by "persons of interest" (aka criminals, journalists, political persons, etc). In those cases, your service may face pressure from government to either implement a backdoor or somehow expose the data from your users.

How should I share the private key and should it be shared?

It depends on how secure you want your service to appear. If your clients trust your service, you can implement a "share key" direct on the application. It would then share your public key with the intended recipient from inside the application.

If they have moderated trust, it could copy the public key to the clipboard to be pasted on IM apps or sent by email, for example. Or they could generate the key pair outside of the app, import the private key and send the public key to the recipients direct.

And what happens if the user installs the app and loses the private key? Will the encrypted data be lost? And is there a way to prevent this situation?

There must no way to decrypt the data without the key, otherwise there's no point in encrypting anything. If you built a secure system and the private key is lost, the data is impossible to decrypt.

You have little to do in this situation. If you store the private key somehow, it's not E2E. If you don't store it at all, a lost key means inaccessible user data forever.

What you can do is encourage the user to backup its key. Giving the user a file with the key is enough to restore it, but you must do so in a way that the user will not disclose this file accidentally.

If the user have two or more devices, you could make the application use the same private key on each one and have a way to transfer the key between devices. This reduces the chances of the user losing access to all his data but increases the chances for an attacker to get access to the private key.

Answer 4

It does not make sense to do it this way. Because the idea behind end to end encryption is a unique key, not a key that is shared with other recipients.

If multiple recipients get the same message it would need the same key. Somebody else could get that from middlemanning from your suggested database if somebody else with that key were using an unsecure connection. Then it isn't even end to end encryption anymore. You might look up SMTP with TLS enabled to encrypt things properly.