(Go straight to the HOWTOs. Do not pass GO.)

2 June 2007: Updated with comments for 7.04 / Feisty Fawn.

I mentioned recently that I planned to keep using TrueCrypt in GNU/Linux since I had used it profitably in Windows, and that I also intended to keep using the container approach where you create a single file of a certain size and then mount it to get your virtual file system.

I’m reevaluating my plan. I still like TrueCrypt and will likely keep using it, maybe by alternating DVD backups between it and my new intended: the EncFS Encrypted Filesystem. (And of course GPG is always good for many crypto jobs, and will also be part of my security framework.)

The drawback with my TrueCrypt method is having to create files of fixed sizes. You either have a lot of empty space tied up or you’re bursting at the seams and can’t expand a volume. And you’re dealing with some large files; perhaps with additional risk of an entire volume being more easily corrupted? I had managed this ok in the past, but I always agonized over the size of volumes to create for backups, since it’s hard to predict future requirements there. I know TrueCrypt has ways of encrypting entire devices, but I’ve been hesitant to go down that road.

After adding another 200GB drive to the slug the other day, I didn’t want to make more decisions about container sizes. I started thinking about alternatives. Maybe it was time to figure out how to encrypt the entire drive with a non-container method, and I wanted to look away from TrueCrypt since I’m interested in crypto diversity.

Summary of my vague crypto knowledge

Let me be clear that I’m no expert at this stuff. I’m just a dabbler. It is challenging to write about it because I know I don’t understand things well enough to explain as well as I’d like. At the same time, I think I have something to offer that may be helpful to others, so I’m pressing ahead anyway. That, and it helps my own understanding to try explaining things. Those, and maybe you’ll help correct my misunderstandings.

I have some experience using public key encryption in my day job, and know a little bit about using file encryption whether on single files or with a single file virtual drive system as in TrueCrypt.

Here are a few of the options I’m aware of for file system encryption, along with my dim understanding of them. For those readers who know their stuff, this may help clarify how utterly ignorant I am, and for those further down the clue ladder like myself… I hope I’m not just spreading misinformation.

  • Individual File Encryption: For example, using GPG to encrypt individual or tarred or zipped files. This has its uses, but would be cumbersome for managing sets of files you want to keep encrypted. It’s a pain to encrypt and decrypt the files every time you want to work with them, and a very slow and crude method for files you routinely work on. Much better is to have some system that lets you enter your password and then work with the files normally.

  • Virtual File System: One example would be using TrueCrypt with the single file method, where you can mount the file and have it behave as a filesystem. Another is how EncFS does it, encrypting files separately. These methods will cause a performance hit, with all the crypto operations being handled on the fly by the CPU, but it’s barely noticeable in my usage.

  • Block Methods?: Other encryption methods that I haven’t gotten in to very far seem to involve encrypting whole partitions or blocks of disk. There’s also talk of loopbacks and things that I’m currently resisting learning more about. Similar to the large container file method in TrueCrypt, I think you have to commit to a certain size volume. From my brief readings, I gather that these are usually lower level techniques, tightly integrated with certain kernel features. Probably still some overhead and performance considerations, but I think these would be faster than other methods.

There’s this whole realm of security considerations out there. I know in addition to securing your files, you also want to encrypt your swap space, /tmp directory, and probably many other things.

For me, I just have some financial and personal files I want to protect in case a computer or backup disc is stolen, so my security goals are pretty simple. (Although I also think about if I want to encrypt family pictures and videos. The thought of someone stealing your data and having all that is kind of creepy.)

For now, I just want to get certain files and backup files encrypted. Later I’ll worry about swap and so on.

What to do?

I’ve been seeing a lot of references to dm-crypt/cryptsetup/LUKS out there, but it’s more than I want to wade in to at the moment. I think the numerous ingredients need to cook for a while longer, and probably be made in to a bland microwaveable package that I can handle preparing.

Also, I read a rant against a lower-level method of encryption that made me consider how much I wanted to trust more sophisticated techniques. With kernel upgrades and the way things are still emerging that could cause compatibility problems and make it hard to retrieve my old encrypted backups, I wanted something that was fairly simple, even if not the most advanced or highest performing technique in the world. I like the idea of using something that is more insulated from the coal-fired engines below deck.

The EncFS Encrypted Filesystem

My search brought me to EncFS, which I think will work really well for me. It uses the regular file system and grows or shrinks as needed. From what I can tell, it is reasonably secure and robust. It also is licensed under the GPL, which is a big plus for me. Thanks to Valient Gough for creating, maintaining, and sharing this great work of free software.

Rather than recapping even more things from the hazy outland borders of my comprehension, I’ll point to a few pages that were helpful to me:

The disadvantages listed in those pages are not a problem for me. As long as the data is secure, I don’t care if meta data is available. For my current purposes, it doesn’t matter if someone can see how big the file is, permissions, or when it was last modified. I also doubt that performance will be an issue. (Again, not for me, anyway.)

On the other hand, the advantages are nice. There is the flexibility already mentioned in not having to specify the size of the encrypted space. It just dynamically grows and plays nicely with other non-encrypted files on the disk. You can backup the encrypted files using something like rsync, without having to decrypt them first. It works for a regular user and there is no need for SUID as in TrueCrypt, with resulting risks. The clear files are only accessible by your user account while mounted.

Lighting the FUSE

EncFS is enabled by FUSE: “Filesystem in Userspace.” It’s a kernel module that allows creation of virtual file systems without needing to write kernel code. We’ll see below that it’s readily available for Ubuntu and Fedora.

I’m interested in learning about a couple of other cool FUSE projects: SSHFS, which allows access to remote file systems through SSH, and GmailFS, which stores data in Gmail. You can use EncFS on top of GmailFS for secure storage. That means almost 3GB worth of free (as in free beer), secure, offsite backup storage, if I can convince myself it’s safe to use that way.

The HOWTO from Ubuntu Forums explains things very well, but I’ll recap/copy it below for my own records, consolidate some of the responses, and add some of my own commentary. (And also show what to do in Fedora.)

HOWTO: EncFS for Ubuntu 6.10 (Edgy Eft) / 7.04 (Feisty Fawn)

Credit where credit is due. Remmelt’s HOWTO: Encrypted directory with EncFS:

http://www.ubuntuforums.org/showthread.php?t=148600

1. Install the software

6.10

sudo apt-get install encfs fuse-utils
sudo modprobe fuse

Says to add “fuse” to /etc/modules so that you don’t have to run modprobe every time you reboot, but when I looked it was already there. If not, use sudo or gksudo and your preferred editor to modify modules. “fuse” goes on a line of its own.

7.04

Comes with fuse-utils already installed, so just:

sudo apt-get install encfs

I’m not sure if sudo modprobe fuse is necessary. I don’t think it is, although I ended up running it when I had problems described below. (It looks like modprobe creates the necessary entry in the device directory /dev. I didn’t think to check for /dev/fuse before running modprobe fuse, but I suspect it was there.)

I’m guessing this stuff comes from the “universe,” so you’ll need to have that repository enabled. If that doesn’t mean anything to you, it may or may not help to read about my own initial bafflement at the world of Ubuntu software repositories.

2. Add yourself to the fuse group.

The installer creates a fuse group and to use fusermount (for mounting/unmounting FUSE filesystems) you need to be in this group.

sudo adduser your_username fuse

In 7.04, I tried this from the Fedora instructions below:

sudo usermod -a -G fuse username

And that worked just as well.

You can also use the GUI to do this. One commenter pointed out that you need to reboot to be recognized as a member of the fuse group. I first tried just logging out and back in, but that didn’t do the job. Rebooting took care of it.

Another commenter suggested: “After adduser you can say newgrp - fuse to join the newly-made group in your current session (saves having to log out).”

This works just fine. It also causes the fuse group to become the default group for that session, so that new directories and files will be created with fuse as the group instead of the default group for that user. I haven’t found a way to stay in the fuse group and get my default group back without rebooting.

If you run encfs without being in the fuse group, you’ll probably see something like this:

fuse: failed to exec fusermount: Permission denied
fuse failed.  Common problems:
 - fuse kernel module not installed (modprobe fuse)
 - invalid options -- see usage message

In 7.04, I got that error even though I was in the fuse group. I noticed that /dev/fuse had root for the owner and the group. I changed it to have fuse for the group and that took care of it. (sudo chown root:fuse /dev/fuse)

3. Create a directory where your encrypted files and directories will be stored

(Can be in the home dir as below, or anywhere.)

mkdir ~/.crypt-raw

4. Create a mount point

The directory where you will mount the encrypted dir and be able to access the decrypted files.

mkdir ~/crypt

5. Create the encrypted system and mount it

The first time you mount the directory, encfs will create the encrypted filesystem.

encfs folder_to_mount mount_point

e.g.

encfs ~/.crypt-raw ~/crypt

Encfs requires absolute paths, either starting from / or using the ~ to represent your home dir. I didn’t do that the first time and was rebuffed with a note on proper usage.

What does it mean to create the encrypted filesystem? Essentially it means the creation of a .encfs5 control file in the encrypted folder. You interactively pick the options you want and they go in that file. The way I understand it is that a random key is picked to encrypt the files and that is also encrypted with your password in that file, so that if you later change the password (using encfsctl), nothing needs to change other than in .encfs5.

So it looks like the .encfs5 file is the mechanism that tells the program whether to mount an already created filesystem or to generate a new one. In my testing, it was easy to copy files around and mount on other machines and on remote drives.

From the EncFS home page: “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.” So be careful! I plan on keeping my control files backed up to CDs/DVDs/USB drives. Maybe encrypt them with GPG and send them to my Gmail account.

EncFS Options

When choosing “expert configuration mode,” you’re presented with several options. A little bit of explanation is given with each by the program. The EncFS Wikipedia article provides additional information. I’ve copied from both sources and added some of my own comments below.

* * * It is also easy to pick the standard configuration on your first try or speed through the expert choices, if you want to skip this box to reach the exciting conclusion of trying out your encrypted filesystem…

  • Cipher algorithm: Lists what is available. My system offered AES with 16 byte block cipher or Blowfish with 8 byte block cipher. Both support key lengths of 128 to 256 bits and block sizes of 64 to 4096 bytes. There was also blowfish-compat which is compatible with older versions of encfs. (Standard configuration used Blowfish.)

  • Key size in bits: For AES, 128 to 256 in 64 bit increments, so three choices: 128, 192, 256. More is better, with the trade-off of slower performance for increased security. (Standard config with Blowfish used 160 bits.)

  • Block size in bytes: 64 to 4096 in 16 byte increments. According to Wikipedia, each time a single byte is read, the entire block that contains it must be decrypted, and for a write operation the block must be decrypted, altered, and re-encrypted.

    I’d like to know more about the trade-offs here and why you’d use one size over another. Wikipedia suggests the default block size of 512 bytes is sufficient for most purposes. Bigger block sizes are better for large files, but don’t mean increased security?

  • Filename encoding algorithms: Block hides file name sizes “somewhat.” Null doesn’t encrypt filenames at all. Stream keeps filenames as short as possible.

    Wikipedia says that keeping names shorter might save space on the source directory’s filesystem depending on how that filesystem manages the directory tree. I don’t imagine this being an issue. I wonder what the difference is between block and stream for obscuring the filename length and/or filename itself? I’m thinking I’ll just go with block encoding.

  • Enable filename initialization vector chaining: Makes filename encoding dependent on the complete path, rather than just encoding each path element individually. With this method, identically named files in different folders will have different encoded names.

    Default is Yes, and I have no reason to use otherwise. Wikipedia says that with IV chaining, if a directory is renamed, all files and directories within it must have their encrypted filenames re-encrypted, and that this method shouldn’t be used if heavily populated directories will be renamed often. So maybe I should say “No” here, because I don’t think it would matter to me if identical names are encoded differently.

  • Enable per-file initialization vectors: At the cost of only 8 bytes per file, you can make the filesystem more secure. Wikipedia says with this option disabled, each file is encrypted with the same initialization vector, which can make the volume key easier to break. Default is Yes.

  • Enable filename to IV header chaining: Makes filename data encoding dependent on the complete file path. If a file is renamed, it will not decode successfully unless it was renamed by encfs with the proper key. If enabled, hard links will not be supported. Default is No.

    Not sure what this is about. Is it saying if you rename or move an encrypted file and then try to decrypt it you won’t be able to? I’d like to know why you’d pick one over the other.

  • Enable block authentication code headers: Significantly affects performance but means (almost) any modifications or errors within a block will be caught and will cause an error. Default is No.

    Again, not sure what this is about. If disabled and an encrypted file is modified, wouldn’t that still cause some problem with decryption? Or might it be hard to detect in a text file (for example)? I think the default is fine for me.

  • Finally! The Password: If you’re interested in encryption, you probably realize that long passwords are better. Password strength is not emphasized or nagged about here, but I recommend using a long phrase of at least 20 characters, with 32 or more being ideal. Use upper and lowercase letters and numbers and punctuation.

    I don’t fault Mr. Gough for the approach taken here. It’s not the job of the program to lecture and teach everything. But I do like how TrueCrypt raises much more of a fuss about this. TrueCrypt and GPG also have you generating random data from the keyboard or mouse when creating encrypted volumes and keys, versus EncFS which does not, which makes me wonder if we’ve sacrificed some security here.

6. Use the encrypted file system!

Create some files and directories in your mount folder. In our example: ~/crypt. You can look in ~/.crypt-raw to see how they are created and encoded there.

For example:

Decrypted

scarpent@prometheus:~/crypt$ ls -l
total 56
-rw-r--r-- 1 scarpent scarpent 31971 2007-02-19 10:53 abc.txt
-rw-r--r-- 1 scarpent scarpent    12 2007-02-19 10:50 another_file.txt
-rw-r--r-- 1 scarpent scarpent     2 2007-02-19 10:51 b
-rw-r--r-- 1 scarpent scarpent  1725 2007-02-17 13:47 dir_list.txt
drwxr-xr-x 2 scarpent scarpent  4096 2007-02-17 16:26 test2
drwxr-xr-x 2 scarpent scarpent  4096 2007-02-17 13:48 test_dir
-rw-r--r-- 1 scarpent scarpent     5 2007-02-17 13:46 test.txt

Encrypted

scarpent@prometheus:~/.crypt-raw$ ls -l
total 56
drwxr-xr-x 2 scarpent scarpent  4096 2007-02-17 13:48 dxQXJsmGIOsMRGqrzrE5b-kN
-rw-r--r-- 1 scarpent scarpent    10 2007-02-19 10:51 lbpnkIn4nP9eKv0Eiyx46NtO
drwxr-xr-x 2 scarpent scarpent  4096 2007-02-17 16:26 Mrs-1Dukjix9fMRsEImrK33m
-rw-r--r-- 1 scarpent scarpent  1733 2007-02-17 13:47 O8qmtJ,dBqBlVeCfzem2k0zM
-rw-r--r-- 1 scarpent scarpent    20 2007-02-19 10:50 OmO5QPE-2-rDGKxi4Ife3mzM-Qds3wfCSRnuy5vbbLo,I0
-rw-r--r-- 1 scarpent scarpent    13 2007-02-17 13:46 SNhhXNn5F7-GMHS4YJOWCjfb
-rw-r--r-- 1 scarpent scarpent 31979 2007-02-19 10:53 WwounHd5LnhtSbSZR3qcXniT

7. Unmount the encrypted filesystem

fusermount -u ~/crypt

The next time you mount the filesystem with encfs, it will prompt you for your password and mount your directory.

That’s All for Ubuntu

I’d recommend playing around with this for a while with test directories and files until you feel comfortable with how it works. Make sure that you only work on files in the mounted folder, ~/crypt. Verify that after you unmount, you don’t see the plain files and directories. You also might want to see for yourself is that when you mount directories with this method, the decrypted files are only visible to your username.

Try changing your password using encfsctl passwd crypt_dir. With this command you don’t have to give a full path, so that if you’re in the home dir in our example, you could type encfsctl passwd crypt. It will change the password whether the encrypted filesystem is mounted or not.

There are things you can do with automount and fstab and etc., and I plan on learning about these real soon. For now I’m working on getting the basics down. I’m trying to confirm that the things I want to use will work, and then I’ll figure out how to make them more convenient and automated with scripts and so on.

HOWTO: EncFS for Fedora Core 5 and 6

Now, would it be as easy to get working in Fedora?

Searching for [fedora encfs] with Google brings up a good howto as the first result, “HOWTO: encrypt a filesystem with Fuse-EncFS on Fedora Core 6″:

http://www.dma.org/~tw/howtos/howto-fuse-encfs-the-web.html

Worked fine for me in Fedora Core 5 also. I think it may have been FC5 where “easy” support of this was added.

1. Log in as or become root

2. Install the software

yum install encfs

YUM is the Yellow dog Updater, Modified and apparently the counterpart of the Advanced Packaging Tool (apt-get) on Debian systems.

I’ve been very impressed with how both tools work. They’ve been like magic in my latest foray in to GNU/Linux. (I noticed that Fedora’s yum got me a more recent version of EncFS: 1.3.1. In Ubuntu, I have 1.2.5.)

3. Add username to the fuse Unix group and preserve original group memberships

/usr/sbin/usermod -a -G fuse username

(Eric suggested the -a and better wording in the comments. It seemed to work ok with just -Gfuse, but looking at the man page it appears that -a should be used so as not to wipe out other groups. I haven’t tried it this way, but trust that it will work.)

4. Start the service

Todd Warner, the author of these instructions, is unsure if this is necessary. I went ahead and ran it with the resulting message:

/sbin/service fuse start

Starting FUSE: done.

5. Log out of X and back in again

And now we can continue as in the Ubuntu HowTo.

That’s All for Fedora

Todd has some more detailed tests to try out, and also has some good suggestions for scripting and for using symbolic links in conjunction with Firefox and Thunderbird to protect your .mozilla and .thunderbird folders. (Thanks, Todd, for taking the time to put stuff like this out there.)

That’s All for Now

Please let me know if there are gross (or even just yucky) errors in my write-up or if you found this post helpful. It takes a lot of time to put these things together and your satisfaction/feedback are my only rewards. :-)

Related: TrueCrypt in Ubuntu and Fedora GNU/Linux