Feature Request: Option to encrypt files in the cloud

[bencarlisle15]

This would add privacy from Microsoft without hindering user experience. It could be done by encrypting before uploading and decrypting after downloading. Additionally, this would be encrypted using the hash of a user's password as a symmetric key.

[abraunegg]

@bencarlisle15

Whilst I can totally understand the desire here to upload encrypted data, the platform itself (OneDrive) has significant issues in dealing with encrypted files / data / content.

In teasing out your request a little further - files that are uploaded, the content is to be encrypted. But what about the file name & or the folder name / path? If your data is so sensitive that it needs to be encrypted to avoid Microsoft 'investigating' or having access - would not the file name / folder path structure then also lead itself to privacy concerns?

So let's say that - yes - file / folder names should be encrypted as well ... OK .. adds to another level of complexity. How would this then differ to say running eCryptFS locally and syncing the encrypted filesystem to OneDrive, whilst working with the unencrypted files locally? Well for starters you run into the 400+ character limitation that OneDrive imposes for the full path to a file when stored on OneDrive .. so this kind of negates being able to follow the design principals of eCryptFS to encrypt the path / filename & data .. and just leaves us with encrypting the file / contents of the file.

This now then needs to look at the crypto to use to encrypt the file .. something I am not going to write myself as I know I will get it horribly wrong - so, leverage some of the kernel crypto functions to perform this job. How will the crypto key management be performed? The potential options here are:

• local file system (0600 file) ?
• gnome-secret / kwallet / similar ?
• use of an external service / token / device - yubikey ?

If leveraging kernel crypto routines - do we pick ones that have CPU hardware support or keep it as software based only? What about all these older platforms (eg folk that still run Ubuntu 16 on i386 CPU's ... ) they wont have the hardware CPU crypto routines ... to what about the folk running ARM .. again different ....

The next question would then be - how to obtain the key on application startup / enter the pass phrase .. what to do with --monitor and when running in a service - the pass phrase would have to be stored somewhere to be accessed .. creates other complexities to be catered for.

The last complexity that I can think of is around 'multi-system' setups, where you are using the same OneDrive account on multiple Linux systems and/or platforms (Android phones, Windows etc) ... the encrypted data will be synced to those devices - how do you access? But if the file name is not changing - how do we know that your phone / Windows device will now not 'replace' the encrypted file with its own (maybe older) copy ... which means now you are potentially in a data loss scenario.

So whilst I do totally understand your feature request and the desire to upload encrypted data - and this is not the first request for this (and probably wont be the last) - I have been thinking about how to tackle this, however this is not something that will be delivered in the short to medium term. This sort of feature needs a major step back away from code - whiteboard, design, architecture and think how to solve for all of the points above and even probably many more that I am not even seeing right now.

If you 100% absolutely require this, and cannot live without this, please:

• Consider that maybe OneDrive is not the right solution for you to store encrypted files as a 'backup' of your data ... as the whole premise of OneDrive, is to utilise Office applications online to edit, share documents - all of which is negated if the content is now encrypted and unusable as you cannot use the online Office toolset with those files, nor share them with others due to your encryption key.

  • If you really must use OneDrive, consider archiving your 'top secret data' in an archive of your choice, password protect that a nice strong password, and upload the archive file. You then can provide the file + password if required to others if required.

• Consider possibly picking up the torch and helping implement this feature - a potential starting point might be; https://github.com/LightBender/SecureD

• Consider using a different cloud storage provider for your sensitive data. The following Cloud storage providers work 'really well' with encrypted data (none of this 400 character path limitation that OneDrive has):

  • Amazon S3
  • Backblaze B2
  • Google Cloud Storage
  • Google Drive
  • ownCloud

  For example - and this is tested extensively with encrypted data + eCryptFS:

  

[seandlg]

What a great answer! Maybe, until such a feature is implemented natively in some distant future, it's worth having a look at cryptomator. It's FOSS, comes with iOS & Android support and is built for your use-case. I'm not sure if it actively gets around the path limitation issue though..

[abraunegg]

@seandlg
Thanks for the feedback.

Is it possible in the meantime for you to contribute a detailed document that outlines how to integrate utilising the tool you are suggesting - plus potentially some graphics showing results online when using that tool?

[seandlg]

Luckily, it appears that there already is a graphical setup guide to follow available online: https://docs.cryptomator.org/en/latest/desktop/getting-started/

The simple steps:

1. Set up onedrive
2. Install cryptomator (see docs above)
3. Using cryptomator, create a vault inside the onedrive sync_dir.

That's it. onedrive is responsible for syncing whatever gibberish cryptomator produces inside your vault directory. cryptomator reads this vault, and when given a password, decrypts it and mounts it as a virtual drive.

Also, it appears that cryptomator gets around the path limitation issue:

To maximize compatibility, we need to make sure the ciphertext names don’t exceed a length of 255 chars. As some cloud sync services might want to add a suffix to a file in case of conflicts, we decided to use at most 220 chars.
— Source

This is actually very cool, as it should enable you to completely get around the path limitation issue (allowing for arbitrarily deeply nested directory structures).

[731894915]

Hi, first of all, thanks for building such an amazing free OneDrive client for Linux!
I think CryFS is a good option for data encryption. CryFS encrypts the meta info of files such as file names, sizes, and so on. Basically, it chucks a file into small pieces with a pre-defined block size which is also appropriate for cloud storage synchronization(we can upload newly added or modified file blocks instead of a whole image file).
This works pretty well for me until one day I added a large file(or plenty of small files) through CryFS and it chucks all my data into about 160k files with block-size equal to 32KB. Then here comes the trouble, it looks like the onedrive client is uploading these files one by one in the main thread. The overall uploading speed of my PC is 20KB/s which is too slow. It took me two days to only upload 2GB.
I was thinking about whether it's possible for us to support multi-thread uploading, which can significantly boost the performance in such scenarios.

[abraunegg]

@731894915

I was thinking about whether it's possible for us to support multi-thread uploading, which can significantly boost the performance in such scenarios.

Please refer to #232 for details.

[adyanth]

Would love to see this implemented if possible. I currently use duplicity to take snapshots+backups and upload the resulting bundle via this client.

[abraunegg]

@adyanth
To implement encryption, please use cryptomator as per above.