Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Option to encrypt files in the cloud #1023

Open
bencarlisle15 opened this issue Aug 17, 2020 · 8 comments
Open

Feature Request: Option to encrypt files in the cloud #1023

bencarlisle15 opened this issue Aug 17, 2020 · 8 comments
Labels
Feature Request Feature Request | Enhancement Request Workaround Available A work around for the specific issue is available

Comments

@bencarlisle15
Copy link

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.

@bencarlisle15 bencarlisle15 changed the title Option to encrypt files in the cloud Feature Request: Option to encrypt files in the cloud Aug 17, 2020
@abraunegg abraunegg added the Feature Request Feature Request | Enhancement Request label Aug 17, 2020
@abraunegg
Copy link
Owner

abraunegg commented Aug 17, 2020

@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:

    Windows 7 - MyNAS Documentation-2018-03-01-11-37-04

@seandlg
Copy link

seandlg commented Aug 27, 2020

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
Copy link
Owner

@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
Copy link

seandlg commented Aug 28, 2020

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).

@abraunegg abraunegg added the Workaround Available A work around for the specific issue is available label Aug 28, 2020
@731894915
Copy link

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
Copy link
Owner

@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
Copy link

adyanth commented Aug 16, 2021

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
Copy link
Owner

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Feature Request Feature Request | Enhancement Request Workaround Available A work around for the specific issue is available
Projects
None yet
Development

No branches or pull requests

5 participants