LinuxDevCenter.com

oreilly.comSafari Books Online.Conferences.
Sign In/My Account | View Cart   

We've expanded our Linux news coverage and improved our search! Search for all things Linux across O'Reilly!

Search
Search Tips

advertisement


Listen Print Discuss Subscribe to Linux Subscribe to Newsletters

Userspace Filesystem Encryption with EncFS

by KIVILCIM Hindistan
04/14/2005

For a long time now, computer-related theft has been a real problem. The most likely victims of these thefts are laptops and USB sticks, which are obviously very easy to lift (and leave with). Desktop computers and backup media are stolen less frequently. In all of these cases, much of the time, the data stored in the media is more valuable than both the computer and the media. An important question is how to protect valuable data in our computer's storage areas.

Woes of Encryption

A solution may be to use gpg or similar PKI-based file encryption, but that is still far from transparent and key maintenance is still not very practical. When you consider that you may have to work with several files at a time, this solution becomes even less practical.

The immediate solution is to use an encrypted filesystem, which will encrypt all of the data written into the filesystem and decrypt it on the fly when you need to access it. Though this may solve most of the problems, it has performance/privacy trade-offs; the encryption of your latest work may be good, but the encryption of your favorite text editor or your browser's cache files may be unnecessary.

There's another partial solution related to partitioning on Linux: having all of the system files on an unencrypted partition and the data files on an encrypted partition. As a best-of-two-worlds solution, this seems to solve both the performance and privacy problems, in theory. However, in real life, having such a partitioning may not be easy; you may not have the rights to repartition a multi-user system, or your hard disk layout may make it very difficult to repartition.

The problem is bigger with USB sticks, for you may want to use those sticks to store your private data as well as to exchange some other data with others, probably Windows users. Having a filesystem-wide encryption scheme would subvert that goal. Many projects have tried this classical approach. The most famous are Loopback, CFS, and TCFS.

EncFS

Related Reading

Linux Server Security

Linux Server Security
By Michael D. Bauer

Table of Contents
Index
Sample Chapter

Read Online--Safari Search this book on Safari:
 

Code Fragments only

A new and different approach to this problem is EncFS. EncFS runs in userspace, meaning that you do not have to compile kernel modules or have administrative rights. Its most important feature is being able to encrypt not the whole filesystem or partitions, but separate directories. For its simple usage and implementation, on a modern CPU the performance loss is almost negligible, because even a 1.5GHz CPU waits often for RAM or hard disk I/O and has enough power to perform encryption and decryption on the fly.

Valient Gough's EncFS page has detailed benefits and comparisons of EncFS.

To install EncFS, you must first install Fuse and rlog. You can find SuSE 9.2 binary packages from Valient's home page. Debian users should use the alien package converter tool to turn these into Debian-aware .deb files with alien -d xxxx.rpm.

After installing these two packages, you can compile and install EncFS. At the time of this writing, the current version is 1.2. When you have finished installing all three packages, you can start making encrypted directories.

Using EncFS

Using encrypted directories is more like mounting any filesystem under Linux. Create a real directory with all of your files, perhaps /home/user/raw-crypt. You'll also have a mount point, perhaps /home/user/crypt. When referring to the directories, however, be sure to use absolute directory names (not just /usr/bin/crypt).

Make the encryption with the command:

> encfs /home/user/crypt-raw /home/user/crypt
Volume key not found, creating new encrypted volume.
Password: 
Verify: 

Then your encrypted directory is ready. To access it, refer to files in the crypt directory as normal. When you've finished, use:

fusermount -u /home/user/crypt

This unmounts the crypt directory, leaving the encrypted directory crypt-raw on disk. Fortunately, it's pure rubbish to anyone but Tank from the Matrix, with the exception of the file rights and sizes, which are identical to the unencrypted ones. Apart from that, even the filenames have changed.

One good thing about EncFS is that for making backups you do not have to mount the crypt-raw directory. Instead, you can take a snapshot of the encrypted directory and later decrypt it. For the file-by-file-basis encryption, automated backup programs will even recognize the updated files and will archive them.

There is also the matter of passwords. When you create an EncFS directory, EncFS chooses a random password (one which is far more complex than any password entered via the keyboard), encrypts the directory in question, and finally encrypts the random password with your own chosen password. Because of this, any time you change the access password, it only changes the password used to encrypt the random one, making it unnecessary to re-encrypt all the files.

As a whole, EncFS is a very good encryption alternative, with all of the speed and well-thought-out practical solutions to otherwise big problems. EncFS practically secures your data on laptops or USB sticks. You may even use it on your desktop for securing important data.

KIVILCIM Hindistan works as a full time computer security consultant with a CISSP, using Linux and Free Software as weapons of choice.


Return to the Linux DevCenter.


Have a tip for using EncFS? Share it here.
You must be logged in to the O'Reilly Network to post a talkback.
Post Comment
Full Threads Oldest First

Showing messages 1 through 4 of 4.

  • EncFS is available on Debian Sid (Unstable)
    2005-04-20 03:01:18  Doegox [Reply | View]

    All is said in the title.
    If you've the unstable feed in your source.list, "apt-get encfs" does the job, with of course the usual handling of the dependancies (fuse and rlog).
  • Comparison to loop-aes?
    2005-04-15 15:55:03  jlmarin [Reply | View]

    Could anybody comment on the streghts/weaknesses of this new system compared to loop-aes? I mean crypto strength, regardless of other issues. For instance, loop-aes requires you to patch your mount utils, which is a minor annoyance, but on the other hand the crypto is bullet-proof.
    • Comparison to loop-aes?
      2005-04-16 16:58:13  moopst [Reply | View]

      I think the fact that the files are there with the same sizes means you could attack this more easily. All of my digital pictures are about 1.5-1.6 MB. Suppose you had two dozen spreadsheets, all around 25k, and they all have the same information in their header (like some sort of xml doctype declaration for example). You could make some assumptions and go after the key using that.

      I don't know about loop-aes but I would like to see everything encrypted, even the linked list for the file blocks, so that a fragmented file looks even harder to read because you can't follow its bits sequentially until you break the code.

      However I really do like the backup feature. I'm going to look into using this at work on Solaris. We have some files with encrypted passwords in them.

      • not so easy
        2005-04-17 06:57:23  vgough [Reply | View]

        Encfs will use either Blowfish or AES from the OpenSSL library, with key lengths from 128bit to 256bits.

        The kind of attack you are talking about (failes having known headers) is a type of "known-plaintext" attack. However you drastically overestimate the efficiency of such an attack. Even if your drive was so bit that it contained every byte of data in the world, and the attacker had both the plaintext and encrypted versions, there is still no published way to get the AES key given that data. So having some images and spreadsheets around isn't going to be enough by a long shot.

        You might be thinking of a known-plaintext attack against the kernel loopback system not so long ago, which I believe was really a dictionary attack. Because of the way the loopback driver had encrypted the data, it was possible pre-compute the encrypted data that would result for particular passwords. So an attacker could create a big dictionary of pre-computed encrypted data and simply test against some known bytes on the drive to see if one of those passwords was in use. Encfs does not allow this, as two different encfs filesystems will always have different encrypted data - even if the same data is stored in each, and the same password was used when the filesystem was created.

        By far the most cost effective attack would be to bug your computer or keyboard. That attack would cost less then tring to break AES, and work equally well with loop-aes or encfs.


Tagged Articles

Post to del.icio.us

This article has been tagged:

linux

Articles that share the tag linux:

Managing Disk Space with LVM (74 tags)

Use Your Digital Camera with Linux (60 tags)

mdadm: A New Tool For Linux Software RAID Management (59 tags)

Asterisk: A Bare-Bones VoIP Example (43 tags)

View All

crypto

Articles that share the tag crypto:

Secure RSS Syndication (28 tags)

Userspace Filesystem Encryption with EncFS (4 tags)

Symmetric Cryptography in Perl (3 tags)

Deploying a VPN with PKI (2 tags)

An Unencrypted Look at FileVault (2 tags)

View All

encfs

Articles that share the tag encfs:

Userspace Filesystem Encryption with EncFS (3 tags)

View All

privacy

Articles that share the tag privacy:

Secure RSS Syndication (21 tags)

Protect Yourself from WiFi Snoops (6 tags)

The Long View of Identity (4 tags)

Userspace Filesystem Encryption with EncFS (3 tags)

Anonymous, Open Source P2P with MUTE (2 tags)

View All

cryptography

Articles that share the tag cryptography:

Secure RSS Syndication (15 tags)

Asymmetric Cryptography in Perl (2 tags)

Userspace Filesystem Encryption with EncFS (2 tags)

Creating Your Own CA (2 tags)

View All

Sponsored Resources

  • Inside Lightroom
Advertisement

Sponsored by:

O'Reilly Media
© 2008, O'Reilly Media, Inc.
(707) 827-7000 / (800) 998-9938
All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.
About O'Reilly
Privacy Policy
Contacts
Customer Service
Authors
Press Room
Jobs
User Groups
Academic Solutions
Newsletters
Writing for O'Reilly
RSS Feeds
Other O'Reilly Sites
O'Reilly Radar
Ignite
Tools of Change for Publishing
Digital Media
Inside iPhone
O'Reilly FYI
makezine.com
craftzine.com
hackszine.com
perl.com
xml.com
Sponsored Sites
Inside Aperture
Inside Lightroom
Inside Port 25
InsideRIA
java.net