Support for encryption at rest

[thefonseca]

I wonder if there is a way to have the remote location to be encrypted, in a similar way that rclone's crypt does.

Would it be possible to implement a hook to preprocess the file contents (GPG encrypt/decrypt, for example) just before saving in the local disk or sending to the remote?

Any pointers would appreciated. Thanks!

[samschott]

This should be possible in principle. The client module handles the actual uploads and downloads and it would be easiest to implement a hook here, though it could possibly be done in the sync layer as well.

A potential complication are content hashes which are sometimes used to resolve conflicts: at the moment, such content hashes are calculated on demand for local files and not cached but the infrastructure to cache them is already implemented in the dev branch. If files are encrypted or otherwise pre-processed before upload (chunked, etc), the corresponding hashes of the processed file should be stored and tagged with the ctime to avoid unnecessary overhead.

I just had a look at rsync and the use cases are a bit different. Rsync looks more like a backup solution with one-way sync where encryption is a more common use case. For two-way syncing as provided by Dropbox, this is less common. But I can imagine a case where multiple clients can decrypt the files when syncing while Dropbox servers only ever see the encrypted versions.

This is not really at the top of my todo list but its worth considering if there is is demand.

[techman83]

That'd be neat, though I have used EncFS in the past for this purpose.

[thefonseca]

@SamSchott, thanks for your comments. I will examine the client module to get a better understanding.

I just had a look at rsync and the use cases are a bit different. Rsync looks more like a backup solution with one-way sync where encryption is a more common use case. For two-way syncing as provided by Dropbox, this is less common. But I can imagine a case where multiple clients can decrypt the files when syncing while Dropbox servers only ever see the encrypted versions.

You're right. rclone is more suited for backups, although there is some ongoing work on bidirectional sync. Let's see if more people are interested in this feature.

@techman83 EncFS (and also Cryptomator, gocrypfs, CryFS) is a great option but it has a downside: you can only keep encrypted version of the files in the real filesystem, which makes automated local backups of the unencrypted files (such as Time Machine) more difficult. If you lose the key... it is all gone.

[samschott]

I have been thinking about this a bit more and can see multiple difficulties, especially when keeping files on Dropbox encrypted:

1. One potential disadvantage with encrypting files on Dropbox is that metadata such as file size, change history, folder structure, etc, all remain visible (file names of course can be encrypted as well). The Dropbox API is designed to deal with individual files and unless one deliberately circumvents this design there is still a lot of information to be gained from individually encrypted files. I am not sure how rclone handles this.

2. Maestral’s user experience is centred around syncing your entire Dropbox (exceptions can be defined in selective sync settings or a “mignore” file) and the Dropbox user experience involves sharing files and folders with others to collaborate. Both of this means that it would be preferable to enable encryption on a per-folder basis and not for the entire Dropbox. This complicates the implementation and will require a careful design of the user interface.

Regarding support for locally encrypted files, I can imagine separating all interactions with the file system into a separate module which abstracts different backends and allows for encrypted storage. But I am less sure about the benefit vs just using an encrypted home directory or partition.

@thefonseca, can you maybe elaborate on the use cases and patterns which you expect for either local or remote encryption?

[thefonseca]

@thefonseca, can you maybe elaborate on the use cases and patterns which you expect for either local or remote encryption?

Sure. The use case is simple: add zero-knowledge encryption to Dropbox, as an open source alternative to sync.com.

I understand that maybe this feature requires so much effort that would be unfeasible or require a separate project. But I think Maestral could be an excellent starting point for that, as the heavy lifting of syncing is already solved.

Regarding support for locally encrypted files, I can imagine separating all interactions with the file system into a separate module which abstracts different backends and allows for encrypted storage. But I am less sure about the benefit vs just using an encrypted home directory or partition.

The existing open source solutions (EncFS, Cryptomator and others) force you to have your local files encrypted. This means you have to mount an unencrypted view (FUSE, WebDav) to access your files. I do not need to protect access locally (as I have other tools to do that, such as disk encryption, Time Machine encrypted backups, etc) but only from third parties like Dropbox itself and governments.

This is exactly what sync.com offers, but with closed source clients. Please refer to their white paper for a high-level description of the security design.

1. One potential disadvantage with encrypting files on Dropbox is that metadata such as file size, change history, folder structure, etc, all remain visible (file names of course can be encrypted as well). The Dropbox API is designed to deal with individual files and unless one deliberately circumvents this design there is still a lot of information to be gained from individually encrypted files. I am not sure how rclone handles this.

You are right. You need to accept a lower level of protection to make the solution compatible with cloud providers. But I think file name and content encryption would be already a decent security target.

2. Maestral’s user experience is centred around syncing your entire Dropbox (exceptions can be defined in selective sync settings or a “mignore” file) and the Dropbox user experience involves sharing files and folders with others to collaborate. Both of this means that it would be preferable to enable encryption on a per-folder basis and not for the entire Dropbox. This complicates the implementation and will require a careful design of the user interface.

Yes, per-folder configuration would be highly desirable but I would say only at Dropbox root folder level. You would not be allowed to encrypt an arbitrary folder in the hierarchy. It seems that encrypted sharing is possible (it is supported by sync.com), but this could be added later, if needed. If you need to share a folder/file, just copy it to a non-encrypted space in your Dropbox.

[samschott]

You have me convinced, this is certainly worth looking into.

[Gestas]

NextCloud 20 implemented client-side encryption, enabled per folder. The general model may be applicable to this feature request.

• https://github.com/nextcloud/end_to_end_encryption
• https://github.com/nextcloud/end_to_end_encryption/blob/master/doc/api-usage.md
• https://github.com/nextcloud/end_to_end_encryption/blob/master/doc/api.md
• https://github.com/nextcloud/end_to_end_encryption_rfc/blob/master/RFC.md

[raffaem]

In the meantime you can use Cryptomator: https://cryptomator.org/

It's a free software that will create a virtual drive out of encrypted files that are sent to the cloud.

Works with Maestral.

EDIT: Make sure to also grab the KeePassXC integration plugin: https://github.com/purejava/keepassxc-cryptomator