Other Projects

There are several open-source file encryption solutions for Linux available. In contrast to disk-encryption software that operate on whole disks (TrueCrypt, dm-crypt etc), file encryption operates on individual files that can be backed up or synchronised easily.

This page compares:

  • gocryptfs (this project), aspiring successor of EncFS
  • EncFS, mature with known security issues
  • eCryptFS, integrated into the Linux kernel
  • Cryptomator, strong cross-platform support through Java and WebDAV
  • securefs, a new C++ project that implementes directories as user-space B+ trees
  • CryFS, result of a master thesis at the KIT University that uses chunked storage. The tested version is 0.9.5-1-g5442662.

If you spot an error or want to see a project added, please file a ticket!


gocryptfs encfs ecryptfs cryptomator securefs CryFS
First release 2015 [1] 2003 [2] 2006 [3] 2014 [4] 2015 [10] 2015
Language Go C++ C Java C++ C++
Development hotspot Austria USA UK (Canonical Ltd) Germany China Germany
Lifecycle Active Maintainance Active [9] Active Active Active
File interface FUSE FUSE in-kernel filesystem WebDAV FUSE FUSE
Platforms Linux, 3rd-party Windows port [11], OSX in progress [7] Linux, OSX, 3rd-party Windows port Linux only Linux, OSX, Windows Linux, OSX Linux
User interface CLI; 3rd-party GUI: SiriKali CLI; 3rd-party GUI Integrated in login process GUI only; CLI planned [8] CLI CLI, 3rd-party GUI
Lines of Code {1} 6,343 9,320 7,662 {2} 9,921 4,704 {3} 30,036 {4}
Reverse Mode yes (since v1.1) yes no no no no

References: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]

{1} All computed using cloc
{2} Counting only fs/ecryptfs/
{3} The securefs source/ directory contains embedded libraries. The count is produced using "cloc btree_dir.h commands.h exceptions.h file_table.h files.h logger.h operations.h streams.h utils.h xattr_compat.h btree_dir.cpp commands.cpp file_table.cpp files.cpp logger.cpp operations.cpp streams.cpp utils.cpp" and contains the files actually comprising securefs as stated by the author.
{4} cloc . --exclude-dir=vendor

General Security

gocryptfs encfs default encfs paranoia ecryptfs cryptomator securefs CryFS
Documentation available Yes [1] Yes [2] Yes [2] No [4] Yes [3] Yes [5] Yes [6]
Password hashing scrypt PBKDF2 PBKDF2 (none, implemented in external tool) scrypt PBKDF2 scrypt

References: [1] [2] [3] [5] [6]
[4] actually, there is a lot of ecryptfs documentation, but none of it seems to describe the used crypto.

File Contents

gocryptfs encfs default encfs paranoia ecryptfs cryptomator securefs CryFS
Encryption GCM CBC; last block CFB [1] CBC; last block CFB [1] CBC CTR with random IV [2] GCM GCM
Integrity GCM none HMAC none HMAC GCM GCM
File size obfuscation no no no yes (4 KB increments) no [3] no yes (chunked storage)

References: [1] [2] [3]

File Names

gocryptfs encfs default encfs paranoia ecryptfs cryptomator securefs CryFS
Encryption EME [4] CBC CBC CBC SIV GCM (B+ dir DB) GCM (dir DB)
Prefix leak no (EME) no (HMAC used as IV) no (HMAC used as IV) yes [2] no (SIV) no (GCM) no (GCM)
Identical names leak no (per-directory IV) no (path chaining) no (path chaining) yes [1] no [3] no (GCM) no (GCM)
Maximum name length [5] 255 (since v0.9) {2} 175 175 143 1025 255 1025
Directory flattening {1} no no no no yes yes yes

References: [1] [2] [3] [4] [5]

{1} Is the directory tree flattened in the encrypted storage? This obfuscates the directory structure but can cause problems when synchronising via Dropbox and similar.
{2} 255 since gocryptfs v0.9, 175 in v0.8 and earlier


All tests are run on tmpfs rule out any influence of the hard disk. The CPU is an Intel Pentium G630 with 2 x 2.7GHz that does NOT have AES instructions.

gocryptfs encfs default encfs paranoia ecryptfs cryptomator securefs {5} CryFS {6}
Streaming write 103 MiB/s 104 MiB/s 56 MiB/s 130 MiB/s 55 MiB/s 96 MiB/s 78 MiB/s
Extract linux-3.0.tar.gz 22 s 20 s 23 s 8.4 s 468 s {1} {2} 21 s 40 s
ls -lR linux-3.0 1.7 s 2.8 s 2.8 s 0.5 s 127 s {3} 5.3 s 16.8 s
Delete linux-3.0 4.3 s 3.9 s 4.1 s 0.5 s 376 s {3} 4.5 s 20.4 s

Repeating (a subset of) the tests on an Samsung 840 EVO SSD shows that ecryptfs falls behind in metadata reads because its complex file headers causes extra disk accesses {4}.

gocryptfs encfs paranoia ecryptfs
Streaming write 65 MiB/s 50 MiB/s 116 MiB/s
Extract linux-3.0.tar.gz 26 s 24 s 8.7 s
ls -lR linux-3.0 2.5 s 3.2 s 8.6 s
Delete linux-3.0 5.3 s 4.7 s 8.8 s

{1} All file acesses to cryptomator go through the WebDAV protocol, which is less performance-oriented than FUSE.
However, an optimized WebDAV client may be able to significantly speed up small-file workloads.
{2} Tested with the dave cli WebDAV client, which gave better speed than gvfs (Gnome built-in) and davfs2
{3} Tested with gvfs in the /run/user/.../gvfs/dav:... mount
{4} Caches are cleared between each test using echo 3 > /proc/sys/vm/drop_caches
{5} Tested against securefs v0.5.2
{6} Tested against CryFS v0.9.5

Disk Space Efficiency

(all file sizes in apparent bytes unless specified otherwise)

gocryptfs encfs default encfs paranoia ecryptfs cryptomator {1} securefs {2} CryFS
Empty file 0 0 0 8,192 88 112 32,768
1 byte file 51 9 17 12,288 137 161 32,768
1,000,000 bytes file 1,007,858 1,000,008 1,007,888 1,011,712 1,001,576 1,011,872 1,048,576
linux-3.0 source tree {3} 498 MiB 485 MiB 488 MiB 784 MiB 498 MiB (not tested) 1470 MiB

{1} cryptomator dropped the use of a random padding in v1.2.0 due to performance concerns.
{2} securefs stores data and crypto metadata (nonces + GHASH) in separate files. The sum of both is shown here.
{3} Measured using "du -sm" on the encrypted directory. The backing filesystem is tmpfs.

References: [1]

Filesystem Features

Note: To keep the work of maintaining this table under control, I have only tested selected projects with respect to filesystem features. Please file a pull request if you can test the other projects!

The backing filesystem is assumed to be ext4.

ext4 gocryptfs encfs default encfs paranoia ecryptfs CryFS
hard links yes yes yes no yes no
fallocate yes yes no no no no
fallocate KEEP_SIZE yes yes no no no no
fallocate PUNCH_HOLE yes no no no no no