Can the following be classified as end to end encryption?

Viewed 177

I am working on a personal project where I plan to store user information on a server in an encrypted form. This is roughly the architecture of my app.

Writing data:

User Data -> [Encryption in browser via "Secret Key"] -> Encrypted data -> Server

Reading data:

Server -> Encrypted Data -> [Decryption in browser via "Secret Key"] -> User Data

I have two ways of performing the encryption:

Method 1:

  • Encrypt using the "Secret Key" provided by the user and send it to the server for storage.

Note: This method would make changing the "Secret Key" cumbersome. All data should be imported to the client, decrypted with existing "Secret Key" and encrypted with the "New Secret Key".

Method 2:

  • Generate a "Random Key" on the client side which will be used for encrypting the data.

  • Store this "Random Key" encrypted using the "Secret Key" provided by the user on the server - "Encrypted Random Key". - For decryption, decrypt using the "Secret Key" to obtain the "Random Key", use this for decrypting further encrypted messages.

Note: Changing password is much easier with this, I will have to decrypt "Encrypted Random Key" to get "Random Key" and I can now encrypt it again with the "New Secret Key".

I have two questions here:

  1. While method 1 can be clearly classified as End to End encryption. I wanted to know if I can classify method 2 as End to End encryption as well?

  2. Would you as a user be comfortable using an app which uses method 2 for storing your personal information.

Thanks in advance.

1 Answers

The term "end to end encryption" is generally used to mean a data transfer between two users, not between user and server (that's what SSL is for). However, conceptionally it's quite the same thing if you send the information back to the same user. The important part is that the server has no way of decyphering the data.

Generally, both of your methods will work. But for practical purposes, you'd probably go for method 2, just because it allows changing passwords. If you use an asymmetric encryption algorithm (RSA or similar), you'd do that anyway, because these are only used to restore the symmetric key that is used to encrypt the actual data. Your "Random key" will therefore likely be a symmetric key, while the "Secret key" is asymmetric.

You are probably aware of the fact that in this setup, when the user looses his key, there's no way to restore the data. Things like "send me a password reset link" won't work.

Related