Blog / Cryptomator 1.7.0: What You Need to Know

This blog post was updated on 2023-02-03 to include the section on AES-GCM.

If you’re subscribed to our releases on GitHub, this is already old news for you: We have released the first beta of the upcoming Cryptomator 1.7.0! It contains a lot of internal changes and a bunch of new features, some of which are almost as old as Cryptomator itself.

We are very proud of this release, as it eliminates technical debt, delivers long-awaited features, and prepares Cryptomator Desktop for the future. But putting aside about 3,000 lines of code changes and a 4-month development iteration (not counting work in our libraries), let’s dive into this release to see what you, the user, will get out of it.

Cryptomator 1.7.0 Release

Locate Encrypted File

As already mentioned, Cryptomator 1.7.0 includes a feature that has been requested for a very long time: Locating the encrypted counterpart of a file. Sounds complex, but once you remember that Cryptomator encrypts filenames and obfuscates the directory structure (see our docs), it is easy to understand.

Prior to 1.7.0, you had to guess which encrypted file corresponds to which cleartext file based on the exact timestamps. Now, once the vault is unlocked, the encrypted counterpart of any file in the vault can be revealed by clicking on the “Locate Encrypted File” button and selecting a file in the vault. Or you can simply drag and drop the files from your vault onto this button. See for yourself in this short video:

Experimental Support for FUSE-T

On macOS, Cryptomator can use two different technologies to integrate your vault into the system: macFUSE and WebDAV. Unfortunately, the WebDAV implementation on macOS is not the most reliable one. Starting with Apple Silicon Macs, it became unusable for some users who reported system freezes. To make matters worse, macFUSE, which has been the preferred option for at least 3 years, is also on its last legs. Apple has deprecated the OS APIs used by macFUSE since macOS 12.3.

For the past year, we have been desperately searching for an alternative. Our proof of concept using Apple’s File Provider framework was not very convincing and would basically require a whole new architecture. Fortunately, you, our community, informed us about an alternative: FUSE-T.

FUSE-T is a young project that does not rely on deprecated macOS APIs and can be used as a drop-in-replacement for macFUSE. It requires a much less deep system integration than macFUSE while offering a similar performance. This makes Cryptomator ready for the medium-term future on macOS. But since FUSE-T is quite young, support for it is experimental for now. We encourage you to try it though!

Experimental Support for FUSE-T

So, while the File Provider extension is not out of our sight, we are relieved to be able to offer you a stable system integration of your Cryptomator vaults.

Volume Types Overhaul

Looking at the screenshot above, you might have noticed: The volume types have changed, too. That’s right, and that’s because we rewrote the entire volume type selection and internal wiring logic. It was a huge development effort, but it resulted in a less complex and easier to maintain architecture under the hood. It also resulted in more options for you.

More Options

The old implementation basically offered 3 (or 2) options: WebDAV, Dokany, and FUSE. Now, specialized implementations are offered for each OS. For example, on Windows you can select between WinFsp, WinFsp (Local Drive), Dokany, WebDAV (Windows Explorer) and WebDAV (Fallback).

But don’t worry, this selection is only important if you have special requirements for the virtual drive. Otherwise, Cryptomator has a new “Automatic” option and is set up to choose the best suited option for you, and you don’t need to worry about it.

We have even added an emergency option: The aforementioned “WebDAV (Fallback)”. If you can’t mount your vault at all, it makes your vault accessible via a local-only server using the web standard WebDAV. We’ll have a guide describing this in more detail soon.

WinFsp Change: Local vs. Network Drive

Windows users may notice that their vault is now mounted as a network drive by default. This has the advantage of better performance when listing large directories. The disadvantage is that it cannot be mounted into a directory. Accessing the vault as a privileged user is still possible by using the UNC path.

WinFsp Change: Local vs. Network Drive

If you really need a local drive, you can always change the volume type in the preferences.

Dokany Deprecation

With the release of Cryptomator 1.7.0, we will officially deprecate Dokany support.

Dokany, like FUSE, provides a file system interface to mount virtual drives without requiring elevated privileges. We started supporting Dokany 3 years ago with version 1.4.0. But things didn’t go as smoothly with the Dokany volume as we had hoped, so we decided to focus our development efforts on a single file system interface. All Dokany-related issues on GitHub will be closed, and our general recommendation is to use WinFSP which comes with the EXE installer of Cryptomator. You will still be able to use Dokany, but it won’t get any updates and support will eventually be removed.

It was a great time, and we wish the Dokany project all the best!

Linux AArch64 Builds

With Cryptomator 1.7.0, we’ll finally ship AArch64 builds of Cryptomator via Flatpak and PPA.

One big obstacle was the aforementioned FUSE file system API on Linux. We were using a rather old project to build the bridge between Cryptomator and FUSE. Thanks to a fantastic development effort started by our lead architect, we now use state-of-the-art technology to implement this bridge. The result is bundled in the library called jFUSE. Not only were we able to change the bridge, we were also able to update to a new major version of FUSE and pave the way to support features like extended attributes.

The AppImage is still x86_x64 only, but we plan to deliver it also in AArch64 architecture eventually.

AES-GCM: New Default for Content Encryption

Starting with Cryptomator 1.7.0, newly created vaults will use AES-GCM instead of AES-CTR+HMAC for file content encryption.

Nowadays, almost all non-embedded devices offer hardware acceleration of the Galois/Counter Mode of operation, so encryption and decryption should be significantly faster than in the old mode of operation. The support in our underlying cryptographic library cryptolib was already added in June 2021 with version 2.0.0. But instead of jumping the gun, we gave it a proper testing period and are now confident to ship this improvement to you.

Of course, our mobile apps also support AES-GCM, although vaults created in iOS or Android will continue to use AES-CTR+HMAC for the time being. The mobile apps are scheduled to switch in their next minor release.

You can continue to use your existing vaults as before. There are no vault upgrades and there is no action required on your part. Cryptomator will support both modes of operation.