How does eCryptfs compare with other Linux disk encryption solutions?

Asked by Dustin Kirkland 

eCryptfs is an actual filesystem. Some other popular disk encryption technologies are not filesystems; they are block device encryption layers (they provide what appears to be a physical block device to some actual filesystem). There is no filesystem logic in these layers. A few of the more well-known block device encryption layers include dm-crypt, Truecrypt, and Loop-AES. Perhaps the best thing about block device-layer encryption is that it is an order of magnitude simpler to implement than filesystem-layer encryption. Another advantage of block device-layer encryption is that it will encrypt the entire filesystem, including all of the filesystem metadata. However, for many use cases, this can turn out to be more of a disadvantage than an advantage.

While eCryptfs uses a powerful and flexible approach to protecting filesystem content, block device-layer encryption technology is still required to protect swap space and certain databases that use their own block device partition. The table below provides a compare-and-constrast of the two technologies. I anticipate that block device encryption will be the best solution for some people, while stacked filesystem encryption will be the best solution for others. Sometimes it even makes sense to use them both together, to combine the comprehensive full-disk encryption of a block device layer encryption technology with the transparent per-file encryption provided by eCryptfs (this will result in double-encryption of the file contents).

EncFS is another popular cryptographic filesystem that behaves much like a stacked filesystem. EncFS is a userspace filesystem, and so individual page reads and writes require additional context switches between kernel and userspace. One advantage a userspace cryptographic filesystem is that it is possible to use symmetric ciphers implemented in userspace libraries, but the frequent context switching impacts performance. In addition, EncFS uses FUSE, which suffers from the fact that shared writable memory mappings must be entirely disabled in order to avoid deadlock on some page swap events.

Question information

Language:
English Edit question
Status:
Solved
For:
eCryptfs Edit question
Assignee:
No assignee Edit question
Solved by:
Dustin Kirkland 
Solved:
Last query:
Last reply:
Revision history for this message
Dustin Kirkland  (kirkland) said :
#1

From the FAQ.

Revision history for this message
Fernando Miguel (fernandomiguel) said :
#2

Where is the attached table?

Revision history for this message
Dustin Kirkland  (kirkland) said :
#3

For now, you can see it here:
 * http://ecryptfs.sourceforge.net/ecryptfs-faq.html#compare

Unfortunately, I haven't been able to get fancy formatting out of Launchpad yet.

:-Dustin

Revision history for this message
Callum Macdonald (chmac) said :
#4

Any idea if that table or the FAQ are still online somewhere? It was a handy comparison of block level versus file encryption.

Revision history for this message
Tyler Hicks (tyhicks) said :
#5

The FAQ has been removed from the old sourceforge project page. A more up-to-date version of the FAQ is kept in the ecryptfs-utils source tree at doc/ecryptfs-faq.html