The pass-through filesystem design is not new for encrypted filesystems. EncFS is modeled after CFS - the original Cryptographic Filesystem by Matt Blaze, published in 1993. Over the years, other filesystems have extended the basic ideas behind CFS in different ways (such as TCFS in 1996). As part of this family of filesystems, EncFS shares the same basic strengths and weaknesses compared to block encryption devices:
- Size: an empty EncFS filesystem consists of a couple dozen bytes and can grow to any size without needing to be reformatted. With a loopback encrypted filesystem, you allocate a filesystem ahead of time with the size you want. Depending on the filesystem, there may be ways of resizing it later, but that requires user intervention.
- Automated Backups: An EncFS filesystem can be backed-up on a file-by-file basis. A backup program can detect which files have changed, even though it won’t be able to decipher the files. This way backups can be made without needing to mount the encrypted filesystem.
- Layering / Separation of Trust: EncFS can be layered on top of other filesystems in order to add encryption to unencrypted filesystems. This also allows you to store data on filesystems you trust for storage but not for security. For example, EncFS could be used on top of a CD, or a remote NFS filesystem, Samba share, or perhaps even GMail storage using GMailFS.
- Meta-data: Meta-data remains visible to anyone with access to your encrypted files. This means that Encfs does not encrypt or otherwise hide the following information:
- The number of files you have encrypted
- The permissions on the files (readable, writable, executable)
- The size of each file
- The approximate size of each filename (to within 16 bytes using AES, or 8 bytes using Blowfish)
You should choose which type of encrypted filesystem to use based on whether the advantages list outweighs the disadvantages for your needs. I have seen one anonymous comparison site discount all file based encryption methods because they do not encrypt swap space. This is poor reasoning: using an encrypted block device does not automatically give you any security on your swap disk. Setting up a swap space encryption is completely separate from setting up a filesystem encryption, so the appropriate tool should be chosen for each task.
There are other encrypted filesystem options available under Linux. The reason I wrote my own was partially because I didn’t like any of the available options, and part because I thought it would be fun on rainy days. Here is a quick (and of course a little biased) comparison to some other options available at the time:
|System Requirements||Linux 2.4-2.6 w/ FUSE module||Linux 2.0 - 2.6?|| ||Linux 2.0 - 2.2 patch|
|Needs kernel patch||NO||NO||NO||YES|
|Implementation||Userspace, FUSE||Kernel||NFS server||NFS client|
|Bonnie test||Pass - 17mb/sec||?||FAIL - crash||?|
|> 2GB files||YES||?||?||?|
Nobody should need to warn you that you should keep backups of important data. Storing data in an encrypted filesystem makes it even more important that you keep backups because it complicates the possibility of data recovery! I can’t remember the last time I had to dig out my backups, and I use encfs everyday. But bugs have been found in the past, so I try and remember to make backups periodically even though I don’t expect to ever use them (at least not until my hard drive fails).
Note about backups: In order to decrypt a file, two things are required (besides the encrypted file data): the password, and the “.encfs5” control file at the top level of the raw encfs filesystem. You should check your backups periodically, otherwise you don't know if they are any good.
The control file contains the filesystem parameters, in addition to encrypted key data which is different for every filesystem.. You need both the password and this control file in order to access the data. If you loose either one, there isn’t anything I can do to help. Your password should be considered important data. If you’re not sure you can remember it, then back it up (in a secure manner – either in a password keychain program, or in a secure location).
$ mkdir /tmp/crypt-raw
$ mkdir /tmp/crypt
$ encfs /tmp/crypt-raw /tmp/crypt
Volume key not found, creating new encrypted volume.
Password: [password entered here]
Verify: [password entered here]
$ cd /tmp/crypt
$ echo "hello foo" > foo
$ echo "hello bar" > bar
$ ln -s foo foo2
$ ls -l
-rw-r--r-- 1 vgough users 10 2003-11-03 21:44 bar
-rw-r--r-- 1 vgough users 6 2003-11-03 21:44 foo
lrwxrwxrwx 1 vgough users 7 2003-11-03 21:44 foo2 -> foo
$ cd /tmp/crypt-raw
$ ls -l
-rw-r--r-- 1 vgough users 6 2003-11-03 21:44 eEM4YfA
-rw-r--r-- 1 vgough users 10 2003-11-03 21:44 gKP4xn8
lrwxrwxrwx 1 vgough users 7 2003-11-03 21:44 i7t9-m,I -> eEM4YfA
$ fusermount -u /tmp/crypt
- Download latest version of EncFS (links above) along with signature
- check signature of distribution
- If you don’t have my public key, get it from my website here: my key (2eaf4d80) , or from a gpg key server.
- check signature: gpg –verify encfs-xxx.tgz.asc
- if using rpm, check the rpm: rpm –checksig encfs-xxx.rpm
- build (also see INSTALL file for instructions), essentially run configure and make.
- Install encfs and encfsctl in system or user directories (or run ‘make install’ to install everything into system directories)
- sudo make install
- creating a new encrypted filesystem:
encfs ~/.crypt-raw ~/crypt
- put something in the filesystem, eg:
echo "this is stored in an encrypted file" > foo