Start working on #177 - Support for encryption at rest

[Gestas]

I've got some time to work on #177. I'm proposing the below for my initial pull request, feedback encouraged.

MVP would include -

• Encryption enabled per directory. Encryption can only be enabled on empty directories. Encryption is always recursive.

• Encryption keys will be automatically generated as a 12 word mnemonic from the BIP-0039 English word list.

• Keys will be stored in the key-chain as specified in the Maestral config file.

• Sharing of encrypted directories will be enabled by allowing a user to add a second key to a directory.

  • When a user shares a directory with a recipient they would send them the second key out-of-band (email, etc).
  • We would need to find a way to enable the recipient to decrypt the files. In the short term I'll put together a simple CLI tool for this.

• Support for disabling encryption globally or per-directory.

• File and sub-directory names will be encrypted.

MVP would not include -

• GUI support.

• Adding encryption in-situ. Users could encrypt existing data by enabling encryption on a new folder then copying existing data into it.

• Rotating the default key.

There would be two new Maestral CLI options, encryption, and encrypt-dir -

encryption - used to setup encryption the first time and check encryption status.

maestral encryption [OPTIONS]

Options

-s, --setup                 Setup encryption the first time. Returns the default encryption key.
-e, --enable KEY            Adds the default key to the client. Used when encryption was setup on another client. 
-d, --disable               Disable encryption. Decrypts all files. 
-l, --list                  List directories with encryption enabled.
-k, --show-key              Display the default encryption key
-c, --config-name CONFIG    Run command with the given configuration.
--help                      Show help for this command and exit.

encrypt-dir - used for directory specific encryption configuration

maestral encrypt-dir [OPTIONS] [PATH]

Options
-e, --enable                Enable encryption for the specified directory. The directory must be empty. 
-d, --disable               Disable encryption for the specified directory. Recursive.
-a, --add-key               Add a new key to the specified directory. Recursive.
-r, --remove-key KEY        Remove the key from the specified directory. Recursive. The default key cannot be removed, use --disable. 
-l, --list-keys             List keys for the specified directory. 
-c, --config-name CONFIG    Run command with the given configuration.
--help                      Show help for this command and exit.

To setup encryption a user would -

1. Setup encryption using maestral encryption --setup. This would return a 12 word mnemonic -

$ maestral encryption --setup
Encryption enabled for account [email protected] (Business)
YOU MUST STORE THIS KEY CAREFULLY. IF YOU LOSE IT YOU WILL LOSE ACCESS TO ANYTHING ENCRYPTED WITH IT!

front-list-yard-spatial-chef-hello-math-fatal-witness-seven-wine-smart

YOU MUST STORE THIS KEY CAREFULLY. IF YOU LOSE IT YOU WILL LOSE ACCESS TO ANYTHING ENCRYPTED WITH IT!

To encrypt a directory -

$ maestral encrypt-dir --enable "~/Dropbox/my-encrypted-dir"
Encryption enabled for directory "~/Dropbox/my-encrypted-dir" in account [email protected] (Business)

# If the directory is not empty - 
$ maestral encrypt-dir --enable "~/Dropbox/my-encrypted-dir"
Directory "~/Dropbox/my-encrypted-dir" in account [email protected] (Business) is not empty. Encryption can only be enabled on empty directories. 

[samschott]

@Gestas, it is good to hear that you willing to take this on! Be aware though that this is quite a project. Recent changes in the internal architecture should however make it easier to implement.

In particular, PR #617 started decoupling Maestral's module for keyring access from the oauth flow, therefore making it easier to store items in the keyring, regardless of their purpose.

PR #637, currently WIP, moves all code specific to the Dropbox API to the client module, making it easier to swap out the Dropbox client with another implementation with the same API. Note however that this may still have some rough edges.

Comments on what you have proposed:

Encryption enabled per directory. Encryption can only be enabled on empty directories. Encryption is always recursive.

This makes sense to me as an initial limitation. Limiting encryption to initially empty directories reduces the risk of accidentally encrypting shared files. Allowing encryption only by top level directory should cover most use cases.

Encryption keys will be automatically generated as a 12 word mnemonic from the BIP-0039 English word list.

Why not allow users to pick their own keys?

Sharing of encrypted directories will be enabled by allowing a user to add a second key to a directory.

I don't know enough about cryptography to understand how this would work practically. Do you propose asymmetric encryption to share data with different recipients, therefore requiring a separate copy for each recipient's public key? Or symmetric encryption just with a different key for each folder (which may be shared with a different set of people?).

I'm not completely convinced about the CLI / public API that you propose, the distinction between global encryption vs single encryption seems somewhat artificial to me in the CLI. What does the encryption command group provide what the encrypt-dir command group cannot?

Questions which you have not addressed

There are a couple of things about designing this functionality which I'd like to sort out before writing any code.

1. Do you propose using a particular library for encryption?
2. Is it possible to perform streaming encryption, i.e., without loading full files into memory?
3. Would a local file be uploaded as a single encrypted file to Dropbox servers? Or as multiple equal-sized chunks, therefore abstracting over the server's file system? In the former case, we would still give away information about file sizes and other metadata.
4. How do you mark directories as encrypted for other Maestral clients?
5. How do you deal with clients that are not aware of the encryption, such as the official client? What happens if other clients add unencrypted files to an encrypted folder?