EncFS provides an encrypted filesystem in user-space. It runs without any special permissions and uses the FUSE library and Linux kernel module to provide the filesystem interface. EncFS is open source software, licensed under the GPL.
As with most encrypted filesystems, Encfs is meant to provide security against off-line attacks; ie your notebook or backups fall into the wrong hands, etc. The way Encfs works is different from the “loopback” encrypted filesystem support built into the Linux kernel because it works on files at a time, not an entire block device. This is a big advantage in some ways, but does not come without a cost.
Pass-through filesystem vs encrypted block device
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:
Pro:
- 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.
- 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.
- Layering/Separation of Trust: EncFS can be layered on top of other filesystems in order to add encryption to unencrypted filesystems.
Cons:
Meta-data: Meta-data remains visible to anyone with access to your encrypted files. So he can know some information about them:
- 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
For more info check the Introduction on the officlal page of EncFS
Installation
These are the requisites of EncFS:
- FUSE : 2.6 or newer for the latest EncFS
- rlog : a C++ logging library
- OpenSSL – versions 0.9.6 through 0.9.8 have been tested
- boost : C++ utility library 1.34 or later
I’ve tested EncFS in Ubuntu 11.10, in this distribution the software it’s available as package so to install it i’ve used from the terminal aptitude install encfs that has also brought in all the correct dependencies:
root@xubuntu-home:~# aptitude install encfs The following NEW packages will be installed: encfs libboost-filesystem1.46.1{a} libboost-serialization1.46.1{a} libboost-system1.46.1{a} librlog5{a} 0 packages upgraded, 5 newly installed, 0 to remove and 9 not upgraded. Need to get 659 kB of archives. After unpacking 3,109 kB will be used. |
Basic Usage
1. Create a directory. In the filesystem that you want to use create a directory where your encrypted files will be stored
In this example i put mine in my home dir, but you can put it anywhere you like.
mkdir ~/encrypted |
2. Create a mountpoint
This is the directory where you will mount the encrypted directory. Through this path you can access the encrypted files.
mkdir ~/temp_encr |
3. Create the encrypted system and mount it
The first time you try to mount the directory, encfs will create the encrypted filesystem asking you the setup and a password. I’ve choose the standard option with an empty line.
It works like a regular mount:
encfs "folder to mount" "mount point" |
So for this example:
encfs /home//encrypted /home//temp_encr Creating new encrypted volume. Please choose from one of the following options: enter "x" for expert configuration mode, enter "p" for pre-configured paranoia mode, anything else, or an empty line will select standard mode. ?> Standard configuration selected. Configuration finished. The filesystem to be created has the following properties: Filesystem cipher: "ssl/aes", version 3:0:2 Filename encoding: "nameio/block", version 3:0:1 Key Size: 192 bits Block Size: 1024 bytes Each file contains 8 byte header with unique IV data. Filenames encoded using IV chaining mode. File holes passed through to ciphertext. Now you will need to enter a password for your filesystem. You will need to remember this password, as there is absolutely no recovery mechanism. However, the password can be changed later using encfsctl. New Encfs Password: Verify Encfs Password: |
Note that encfs wants absolute paths, i.e. starting with a /
4. Crypt your files. Now you can put your files in the directory ~/temp_encr and look in the ~/encrypted one: they will show up there, encrypted.
All works as usual in the directory ~/temp_encr
linuxaria@xubuntu-home:~$ echo "this is my EncFS test" > temp_encr/test.txt linuxaria@xubuntu-home:~$ ls -l ~/temp_encr/test.txt -rw-rw-r-- 1 linuxaria linuxaria 22 2011-12-14 00:08 /home/linuxaria/temp_encr/test.txt linuxaria@xubuntu-home:~$ cat ~/temp_encr/test.txt this is my EncFS test |
But if you umount the filesystem with the command:
fusermount -u /home/linuxaria/temp_encr |
You’ll have now just the directory ~/encrypted that, as expected, holds all the info encrypted, and the metadata.
linuxaria@xubuntu-home:~$ ls -la encrypted/ total 16 drwxrwxr-x 2 linuxaria linuxaria 4096 2011-12-14 00:08 . drwx------ 109 linuxaria linuxaria 4096 2011-12-13 23:55 .. -rw-rw-r-- 1 linuxaria linuxaria 1076 2011-12-13 23:56 .encfs6.xml -rw-rw-r-- 1 linuxaria linuxaria 30 2011-12-14 00:08 NOQUHJDpKw4XkS,THEb5OF,8 linuxaria@xubuntu-home:~$ cat encrypted/.encfs6.xml < ?xml version="1.0" encoding="UTF-8" standalone="yes" ?> < !DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="9"> <cfg class_id="0" tracking_level="0" version="20"> <version>20100713</version> <creator>EncFS 1.7.4</creator> <cipheralg class_id="1" tracking_level="0" version="0"> <name>ssl/aes</name> <major>3</major> <minor>0</minor> </cipheralg> <namealg> <name>nameio/block</name> <major>3</major> <minor>0</minor> </namealg> <keysize>192</keysize> <blocksize>1024</blocksize> <uniqueiv>1</uniqueiv> <chainednameiv>1</chainednameiv> <externalivchaining>0</externalivchaining> <blockmacbytes>0</blockmacbytes> <blockmacrandbytes>0</blockmacrandbytes> <allowholes>1</allowholes> <encodedkeysize>44</encodedkeysize> <encodedkeydata> qmJ1Qryid2K0X0TDptjghpoXE+tWJS2Lpq3SImu9onGr5ilNznj7SSaNMlg= </encodedkeydata> <saltlen>20</saltlen> <saltdata> FxULrGb/Zx9mqOOh/QzaEz6JNV8= </saltdata> <kdfiterations>39114</kdfiterations> <desiredkdfduration>500</desiredkdfduration> </cfg> </boost_serialization> linuxaria@xubuntu-home:~$ cat encrypted/NOQUHJDpKw4XkS,THEb5OF,8 � ͒���< ��_B|�"?��G��-./t+� |
While it’s mounted you can also see this new “filesystem” with a df command:
linuxaria@xubuntu-home:~$ df -h /home/linuxaria/temp_encr Filesystem Size Used Avail Use% Mounted on encfs 8.9G 7.8G 656M 93% /home/linuxaria/temp_encr |
Conclusions
This solution can be very handy to just encrypt one or some directory of your filesystem.
A good idea could be using this solution with “cloud” directory like Ubuntu One or Dropbox, so you’ll have your information saved on the net..but encrypted.
Popular Posts:
- None Found
I see no advantages over the standard LVM+LUKS/dm-crypt care to tell us why one would want to use EncFS under any circumstance?
To just Encrypt one directory in a filesystem ?
Encrypting one directory in a filesystem is easy with LVM+LUKS/dm-crypt+mount…
For me, EncFs works fantastically with sync programs like DropBox or even lsyncd compared to encrypted volumes; I love it in combination with “cryptkeeper”.
hmm I wonder how well dm-crypt would work with DropBox in comparison;
dd if=/dev/zero of=/media/dropbox/cryptfile bs=1024 count=2097152
losetup /dev/loopdropbox /media/dropbox/cryptfile
raw /dev/raw/rawdropbox /dev/loopdropbox
cryptsetup -c aes-xts-plain -s 512 luksFormat /dev/loopdropbox
cryptsetup luksOpen /dev/loopdropbox crypt_dropbox
mkfs.ext4 /dev/mapper/crypt_dropbox
tune2fs -m 0 /dev/mapper/crypt_dropbox
mount /dev/mapper/crypt_dropbox /media/cryptbox
maybe someone who uses DropBox will know
Whoops, meant to reply to this comment with my last post, but here ya go:
Your biggest difference is when you open the encrypted data from more than one location at the same time (mount on my laptop at home and at work)…. encfs still treats the files as separate individuals so you don’t bump into “merge conflicts” like you would on an encrypted volume because only the single files would be modified, not the entire volume (from the POV) for every change which would cause some nasty problems with Dropbox..
Basically when Dropbox detects a change from both sides on a single file, it creates a new set of duplicate files so you can handle the merge manually later, with an encrypted volume, that would SUCK 🙂 .
Your biggest difference is when you open the encrypted data from more than one location at the same time (mount on my laptop at home and at work)…. encfs still treats the files as separate individuals so you don’t bump into “merge conflicts” like you would on an encrypted volume because only the single files would be modified, not the entire volume (from the POV) for every change which would cause some nasty problems with Dropbox..
Basically when Dropbox detects a change from both sides on a single file, it creates a new set of duplicate files so you can handle the merge manually later, with an encrypted volume, that would SUCK :).
Thanks for your article. I too have been curious about the difference between this and LUKS. I’ve seen a lot of FIPS standard encryption requests coming down the pipe, not enabled on Linux by default. I’ve been enabling FIPS and using LUKS for my devices. Will this work in the same way?
e.g. when using LUKS
[root@centos64]# cryptsetup –verbose –verify-passphrase luksFormat /dev/vgtest/testlv
WARNING!
========
This will overwrite data on /dev/vgtest/testlv irrevocably.
Are you sure? (Type uppercase yes): YES <– type in "YES"
Enter LUKS passphrase:
Verify passphrase:
Running in FIPS mode.
Command successful.
[root@centos64]#
That "running in FIPS mode" will appear if I have FIPS enabled, otherwise not. It's a nice confirmation for customers that what we are doing with our encryption is following their request.
Thoughts?