End-to-end encryption for cloud storage in 2020

The release of the new version of Ubuntu with long-term support, Ubuntu 20.04 LTS, and in particular the KDE variant (Kubuntu), prompted me to reconsider the issue of file encryption on cloud storage services. In particular, the methods built into the KDE desktop (Plasma) for creating so-called ‘vaults’ using EncFS or CryFS surprised me somewhat, and I’ll say right away that both proved unsuitable for me. In this article, I present gocryptfs as a better alternative in 2020.

Why should I encrypt my data in the cloud at all?

Please do not even consider whether you have something to hide or not. The mass evaluation of data can harm you in ways you cannot even imagine today. In a constitutional state, you should not have to weigh up whether you are only a good citizen if you disclose all your private data. Here are just a few aspects that I would like to mention briefly, but which you are welcome to research and weigh up for yourself:

  • Do not trust cloud providers’ advertising promises that your data is secure and encrypted. As a rule, they reserve the right to access your data, thereby putting it at risk, as access cannot be securely protected against third parties.
    • Your cloud provider’s data centre may be located abroad, where it is subject to a legal obligation to disclose a data interface upon request. Here, too, the protection of such an interface against unauthorised access and hacker attacks is nowhere sufficiently guaranteed and is impossible to achieve.
  • Data loss is a megatrend. Every week, almost every day, the trade press reports on massive losses of customer data. If it were only your securely encrypted data that you had lost, you could sit back and relax.
  • Do you run a business and store company or customer data in the cloud? In this case, you may have a legal obligation to protect your data from unauthorised access. You can only comply with this obligation by using strong encryption.
  • Do you work from home or on the road? For many, this is normal in 2020. In this case, too, you may have a professional obligation to protect your data.

Why CryFS and EncFS are unsuitable for this purpose

I was surprised by the choice of these two encryption methods for creating so-called plasma vaults. EncFS has been known for years to have a security vulnerability and a theoretical possibility of decryption as soon as multiple copies of an encrypted file are available. This is always the case in the cloud, where versions of modified files are often stored for months. Although its successor, ecryptfs, is still used in Ubuntu to encrypt the home directory and is even part of the Linux kernel, the method is not suitable if there can be multiple accesses to a file. This can be the case if a directory is mounted and, at the same time, something is changed in the directory structure by a sync client (i.e. without user interaction), to describe the problem in very brief terms.

CryFS, on the other hand, is a very new method that has excellent security features and attempts to address the weaknesses of EncFS and ecryptfs. Files are not only encrypted in terms of content and name, but also divided into several smaller blocks, so that even the file size cannot be used to draw conclusions about the type of files. Based on the size, it would be possible to guess whether the files are videos, text documents or similar.

Testing CryFS

To do this, I used the graphical option offered in the KDE desktop to create a Plasma vault with CryFS. I placed the encrypted directory in a directory that is synchronised by a Nextcloud client.

Screenshot Plasma Vaults
Creating a vault in KDE Plasma

Creating and then integrating the directory is self-explanatory via the graphical user interface. I then fill the so-called vault with some test data and a directory containing music files, approximately 800MB in size.

In my encrypted directory, this looks like this: from the 800MB and a few documents, CryFS creates several hundred subdirectories with almost 400,000 files! When I run the synchronisation client on it, it takes just under an hour on a well-equipped desktop PC to search through the files and synchronise them, without uploading. Mind you, this is hardly a large collection of media files, but less than a GB of data. It’s unimaginable how long this would take if you had 10, 50 or even over 100GB of data. It would take more than a whole day to complete the synchronisation!

Surprised by this result, I continued my research online. This can hardly have been the inventor’s intention. At first, I doubted the performance of the Nextlcloud client used, but I found several references online reporting very similar behaviour with other cloud storage services.

On the developer’s Github, there is an entry that confirms my belief that CryFS – as amazing as it may be in theory – is actually completely unsuitable for any practical use case.

despite its enormous potential, cryfs is an incredibly beautiful project, however, it is only theoretical. the way it does with files, makes its use in virtually all scenarios unfeasible. in practically all possible circumstances, the amount of files and the new volume generated, makes its use practically useless.

https://github.com/cryfs/cryfs/issues/70#issuecomment-678711745

The discussion that culminates in the above article began in 2016, and the main problems have not been resolved in CryFS since then. The slow progress of the Github project unfortunately leads to the conclusion that a fix cannot be expected very soon.

Encryption using gocryptfs

In short, this is also a newer project. The goal is to create a worthy successor to the long-serving EncFS, which is unsuitable for the cloud. A security audit in 2017 seems to confirm that this has largely been achieved. Sirikali is an easy-to-use front end, but the command line tool is so simple that I am happy to do without a front end.

The installation is, as far as Ubuntu or Debian derivatives are concerned:

sudo apt-get install gocryptfs

Creation of an encrypted directory

Let’s assume we want to create a subdirectory in Nextcloud where our backed-up data is stored. Nextcloud can be replaced with a directory or storage service of your choice.

mkdir /home/Benutzername/Nextcloud/encrypted

Another directory is required in which the encrypted data is stored in plain text. To stick with the default settings in Ubuntu, I simply continue to use a subdirectory called ‘Vaults’ in the user’s home directory and name it Nextcloud_enc.

mkdir /home/Benutzername/Vaults/Nextcloud_enc

Encryption will now be initiated.

gocryptfs -init /home/Benutzername/Nextcloud/encrypted/

When creating the directory, you will be asked for a password, which you will need to enter each time you access it. It is also possible to use a key file. For the time being, however, we will stick with the password. It goes without saying that this must be secure.

Accessing the encrypted directory

gocryptfs /home/Benutzername/Nextcloud/encrypted/ /home/Benutzername/Vaults/Nextcloud_enc/

The password is requested when connecting. The process is so simple that a front end is not really necessary. It is also possible to automate the mounting process at system startup. More on this in a later article.

Disadvantages

  • The only encryption algorithm available with gocryptfs is AES-256. Personally, I would prefer an algorithm with an excellent security rating, especially for cloud storage. Something like Twofish or Serpent, or a comprehensive selection like the one offered by Veracrypt. At least gocryptfs is not lagging behind other providers such as Boxcryptor, which use the same algorithm.
  • Some security features of CryFS are missing here. If I want to upload an encrypted video, someone could guess that it is a video based on the file size. However, I find that this is a compromise I can make with a clear conscience.

Leave a comment