"E2E" scheme design recommendation about end_to_end_encryption

[GAS85]

I think Signal did not solve issue when you create E2E encrypted share (or chat for signal) and add some participations later - they will not be able to see previous messages also because keys were not add before.

I mean in group shares added some users later should leads to re-encrypt all files in folder with a new keys, otherwise new users will not be able to see content of the files saved before time they were added as participations.

If Server can sign and validate users keys, could give NC opportunity to do key management - server can refuse access with "invalid" keys (e.g. if it was revoked from e.g. the user, or server side). But server key must not be used to do encryption/decryption of the files - so it should not solve issue from above.

[tobiasKaminsky]

Thank you for your detailled and good enhancement idea.
We will consider this and need to figure out how big the technical impact of this is.
First there are some other enhancements, like sharing, needed to be implement.

@schiessle @rullzer

[ardevd]

You're most welcome! Keep up the great work!

[marinofaggiana]

Hi @ardevd, thanks for you consideration ... for now let's try to improve the current protocol :-)

[schiessle]

I think this has various problems which makes the "Signal protocol" unusable. For example if you set up a new device you want to be able to access your already stored files but this is not possible if the key wasn't known when the file where encrypted. Also sharing would rise many additional questions.

Also you could argue that it makes it less secure (or to complicated for many users):

Right now if a attacker set up a new device they need your username, login password and the password of your private key to access your files. In the future we might even provide a "paranoid mode" where the private key is not stored on the server so they would even need the private key.

With the "Signal approach" either every new device could connect to your encrypted files (if you solve the backward compatibility problem, which you would have to solve somehow) as soon as the attacker manage to hack the user name and password or you would need extra steps to verify new devices. Which would be for many users to complicated and would come with it's extra set of question (e.g. verifying new devices in the web interface wouldn't work because the attacker knows your login credentials at this point in time, another already connected device could lead to data lost if you have to replace your broken mobile phone for example, etc)

So I think a more "GPG like" approach with per user keys makes much more sense here.