Can each encrypted file be encrypted with the same password

[dantti]

Sorry if the terms are wrong, but from what I understood each file uploaded to e2e is encrypted with a password that is stored on the JSON metadata file.

If that is correct, what is the benefit of it? Encrypting the encrypted thing doesn't seem to add any value to it.

On the other hand, I wouldn't trust my files to such system due the possibility to lose files, if the metadata gets corrupted but I have my private key I could recover my files (not the filenames).

The metadata file needs always to be at sync with the directory the locking helps preventing issues but it does not prevent:

• Lock folder
• Upload file
• lose connection and do not unlock nor upload an updated metadata, thus the new file is now useless as you can't decrypt it.

Sure in normal cases you would still have your local files..

[ho1ger]

I do not get your question(s) completely. However I still try to answer as I was pondering about (I think) similar questions as yours.

1: Do we use individual keys to encrypt the files?

• to my understanding, yes, each file is indeed encrypted with an individual key
• this key is written into the metadata file
• the key (and some other meta data) is encrypted with the latest metadata key

2: Why not just encrypt everything with my public key and get rid of this complex scheme?

• this would work if you have a single user, as sharing is important, you somehow must have a crypto scheme that allows multiple users to access the same content. A typical solution is to wrap the actual encryption key to the public keys of all intended users.

3: Why the hassle with multiple keys per file?

Assume a folder shared across users A, B, C. C happens to have file system access to the nextcloud server, e.g., because C is the server admin or so.

At a point in time, access is revoked from C and a new user D is added. So A, B and D may now access the folder via nextcloud. Note: C has still file system access to the server and a copy of alle files.

Now let us assume, that we only have ONE symmetric key X that encrypts ALL files. In the situation described above, we would need to create a new symmetric key Y that is used from now on. This, of cause, would mean downloading all old files, decrypting all old files with key X, re-encrypting all old files with key Y and uploading all files again. This is a lot of work which is not worth the hassle as C already has all (old) files.

With the real encryption scheme we just create a new file key and wrap this single key with a new metadata key. No further updates are necessary. When we update an old file (which C has in her possession), we use a new file key and use this to encrypt the new file version (which should of cause remain secret from C) before it is uploaded to the server, add this new file key and wrap it with the latest version of the metadata key.

This is at least my understanding of the design and the reasons for the chosen design...

[rullzer]

Yep.

It is because we want to do sharing in the future. So encrypting everything with the same key won't work. You'd need some way to exchange this key.

And @ho1ger is right

1. Assume a folderX shared with userA userB and userC. This folder contains a file fileY, this file in encrypted with key1
2. Now the moment userC is unshared (so no longer has access) there is no need to rotate the keys. As userC already had access once. userC could just have copied the file when syncing or whatever
3. Once a new version of fileY is written we need to use a new key. Because then even if userC gets access to the file they can't decrypt it.

I had a chat with @tobiasKaminsky and @schiessle about this some time ago. Basically keys must rotate the moment you upload a new file and a user was removed from the share.

However this adds a lot of logic. Probably it is easiest to on all file changes just rotate the key of a file.

Of course the metadatakey needs to change when a user is removed.

I hope this makes sense.

[ho1ger]

I mean this feature would even be helpful for versioning. OK, you would have to additionally keep the file encryption keys of the old versions (which might bloat the metadata file quite a bit) but in theory this would work...