[FR] : Basic e2ee vaults through client-side extension

[DodoLeDev]

Initial Checklist

• I understand this is a feature request and questions should be posted in the Community Discussions

• I searched and couldn’t find anything (or linked relevant results below)

Idea

As per this discussion, the idea of having some kind of safely encrypted garden for our precious files is something a lot of users would want!

However, having all the files end-to-end encrypted makes the server-side features (kind of) useless.

Something that gained some traction was the idea of only having specific zones of the cloud storage encrypted, just like vaults, and just like what Nextcloud actually provides with it's e2ee extension.

Well... Doing this job client-side seems to be a perfect task for an OpenCloud web-extension!

What I would suggest is an encryption protocol that is usable with other tools, like rclone.

Rclone has the crypt provider, that overlays an existing provider (eventually on a specific folder), and encrypts/decrypts on-the-fly the files it has.

Web-extensions are built in javascript and derivatives, and I have found the following node extension, that tries to replicate the rclone crypt behaviour. It has been used on an Obsidian Sync plugin (the developer is involved in both projects).

Here is my implementation idea:

Encrypted folders have some specific metadata on it. The web-extension is registered as a viewer for this kind of folder. When triggered, the extension "mounts" the associated WebDAV location and opens a folder view containing the decrypted folder tree. Other operations behaves as expected, except the fact that the node module acts as a middleware when querying files and folders in this view.

An option to create an encrypted folder is also available in the "New" menu. A password will be asked, and a salt would be deducted based on immutable properties of the folder (like its internal id?)

The main advantage of this implementation, besides the fact that it would provide real e2ee without touching the server codebase, is that the official app are not required to take advantage of these encrypted vaults: rclone is able to handle them properly, provided that you correctly mount the right providers in the right places.

What do you think?

[dragotin]

First, I like the idea, and would support it. Thank you for the writeup.

Some questions: I assume the encrypted folder would exist on the server as some kind of container format, like a tar file. Is that correct? For decryption, it would have to be downloaded to the client - and be decrypted there. Is that your idea?

The key management would only exist in the form that the user keeps the password somehow externally, plus the salt.

How would we implement sharing? How does sharing of the vault work? The encrypted vault can easily be shared "as a whole", what would be needed is that there is a second password for the share receiver. Would that work?

[DodoLeDev]

Hi! In reply to your interrogations:

I assume the encrypted folder would exist on the server as some kind of container format, like a tar file. Is that correct?

Not really, the idea is really to embrace the rclone crypt implementation, which is file based (the root of the encrypted directory is just required because rclone needs a mountpoint). The files and folders name are encrypted, as well are their metadata, but the directory structure is disclosed, which seems to be a reasonable trade-off for the convenience this method would bring.

The key management would only exist in the form that the user keeps the password somehow externally, plus the salt.

Yeah, from my experience, rclone needed a password, plus a salt to prevent having the same hash for a same password. Because having 2 passwords is just far from convenient from a user perspective (even having just one tbh), and because we still want to keep the advantages of the salt, having it generated from the directory's internal ID sounded like a good implementation.

How would we implement sharing? How does sharing of the vault work? The encrypted vault can easily be shared "as a whole", what would be needed is that there is a second password for the share receiver. Would that work?

That's out of scope for this extension, I guess (we could at least share a whole directory but the target user would need to know the original encryption password, which is not good from a security standpoint).

I have suggested a more robust solution which seems more compatible with all the sharing stuff in another discussion.

Hope I’ve answered your questions!