Home > FOSS, KDE, ownCloud > ownCloud and CryFS

ownCloud and CryFS

It is a great idea to encrypt files on client side before uploading them to an ownCloud server if that one is not running in controlled environment, or if one just wants to act defensive and minimize risk.

Some people think it is a great idea to include the functionality in the sync client.

I don’t agree because it combines two very complex topics into one code base and makes the code difficult to maintain. The risk is high to end up with a kind of code base which nobody is able to maintain properly any more. So let’s better avoid that for ownCloud and look for alternatives.

A good way is to use a so called encrypted overlay filesystem and let ownCloud sync the encrypted files. The downside is that you can not use the encrypted files in the web interface because it can not decrypt the files easily. To me, that is not overly important because I want to sync files between different clients, which probably is the most common usecase.

Encrypted overlay filesystems put the encrypted data in one directory called the cipher directory. A decrypted representation of the data is mounted to a different directory, in which the user works.

That is easy to setup and use, and also in principle good to use with file sync software like ownCloud because it does not store the files in one huge container file that needs to be synced if one bit changes as other solutions do.

To use it, the cypher directory must be configured as local sync dir of the client. If a file is changed in the mounted dir, the overlay file system changes the crypto files in the cypher dir. These are synced by the ownCloud client.

One of the solutions I tried is CryFS. It works nicely in general, but is unfortunately very slow together with ownCloud sync.

The reason for that is that CryFS is chunking all files in the cypher dir into 16 kB blocks, which are spread over a set of directories. It is very beneficial because file names and sizes are not reconstructable in the cypher dir, but it hits on one of the weak sides of the ownCloud sync. ownCloud is traditionally a bit slow with many small files spread over many directories. That shows dramatically in a test with CryFS: Adding eleven new files with a overall size of around 45 MB to a CryFS filesystem directory makes the ownCloud client upload for 6:30 minutes.

Adding another four files with a total size of a bit over 1MB results in an upload of 130 files and directories, with an overall size of 1.1 MB.

A typical change use case like changing an existing office text document locally is not that bad. CryFS splits a 8,2 kB big LibreOffice text doc into three 16 kB files in three directories here. When one word gets inserted, CryFS needs to create three new dirs in the cypher dir and uploads four new 16 kB blocks.

My personal conclusion: CryFS is an interesting project. It has a nice integration in the KDE desktop with Plasma Vault. Splitting files into equal sized blocks is good because it does not allow to guess data based on names and sizes. However, for syncing with ownCloud, it is not the best partner.

If there is a way how to improve the situation, I would be eager to learn. Maybe the size of the blocks can be expanded, or the number of directories limited?
Also the upcoming ownCloud sync client version 2.6.0 again has optimizations in the discovery and propagation of changes, I am sure that improves the situation.

Let’s see what other alternatives can be found.

Categories: FOSS, KDE, ownCloud Tags: , , ,
  1. PrivacyParanoid
    August 18, 2019 at 09:14

    Hi Dragotin, i had the same problem some time ago with my NextCloud instance. My CryFS container would take days to sync so i decided to search for some alternative and i settled with Syncthing, which is a peer to peer selfhosted FOSS service that allows you to sync folder across devices. I have an instance on every device on which i want the cryfs container to be synced to and a docker instance on my homeserver that way i don’t have to have two devices online in order to sync my container (the homeserver doesn’t count since it’s always online).

    The sync process with Syncthing is very fast, and you can get data from each and every peer in your network, that way you can further speed up the sync.

    The only problem is that i cannot use Plasma Vault to mount the cryfs container because it doesn’t allow integrity violations and those happen all the time while synchronizing the container across multiple devices.

    Therefore i have to use the following command: cryfs –allow-integrity-violations Encrypted/ Decrypted/

    This could be solved by adding a checkbox to Plasma Vault that enables the previous flag.

  2. Schlaefer
    August 18, 2019 at 14:54

    Check the cryfs man page for –blocksize.

    PS: While I appreciate the additional privacy which comes from the equal block size and would like to have the native Plasma integration, CryFS was to slow for me. I went with gocryptfs and SiriKali.

  3. April 17, 2020 at 17:18

    An outstanding share! I’ve just forwarded this onto
    a co-worker who was doing a little research on this.
    And he in fact bought me dinner because I stumbled
    upon it for him… lol. So allow me to reword this….
    Thanks for the meal!! But yeah, thanks for spending some time to discuss this topic here on your web page.

  4. July 23, 2020 at 20:44

    I chose CryFS for testing with the goal of determining compatibility with the ownCloud service. According to its developers, the tool works together with every service that synchronizes data with a local client.

  1. August 18, 2019 at 02:01
  2. August 18, 2019 at 09:07

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: