Coming soon: eCryptfs

eCryptfs developer Michael Halcrow recently announced that he will shortly be putting eCryptfs up for inclusion into the -mm tree. This filesystem aims to make "enterprise level" (it comes from IBM, after all) file encryption capabilities available in a secure and easy to use manner. Those who are interested in trying it out early can download it from SourceForge.

The eCryptfs developers took the stacking approach, meaning that, rather than implement its own platter-level format, eCryptfs sits on top of another filesystem. It is, essentially, a sort of translation layer which makes encrypted file capabilities available. The system administrator can thus create encrypted filesystems on top of whatever filesystem is in use locally, or even over a network-mounted filesystem.

The design of eCryptfs envisions providing a great deal of flexibility in the use of the filesystem. Rather than encrypt the filesystem as a whole, eCryptfs deals with each file individually. Different files can be encrypted in different ways. The use of this sort of mechanism implies that eCryptfs must maintain metadata on how each file is to be handled. This metadata is placed in the first block of the file itself, meaning that the file can be backed up, copied, and even moved to another system without losing the metadata needed to decrypt it in the future.

Plans for eCryptfs include a wide range of features. There will be dynamic, public-key encryption with each user's GPG keyring. On systems equipped with "trusted platform" (TPM) modules, the TPM will be used for its encryption capabilities and the ability to lock files to a specific system. Key escrow systems can be worked in for companies which need that feature. For the upcoming 0.1 release, however, eCryptfs will only support a single passphrase mode. The rest can be added once the initial problems have been shaken out and some policy support work has been done.

Many of the advanced features have been implemented, however, and can be tried out by sufficiently motivated testers. The developers are interested in feedback from people who can give eCryptfs a try or look over the source. Having seen the difficulties experienced by some filesystem implementers as they tried to get their work merged, the eCryptfs hackers would, doubtless, like to get any potential issues resolved sooner rather than later.

Index entries for this article
Kernel	Filesystems

---

to post comments

Current status

Posted Oct 28, 2005 1:00 UTC (Fri) by mhalcrow (guest, #17371) [Link]

Mike Halcrow here. Over the last month, we have squashed several bugs and trimmed down the source to something that is more easily analyzable for inclusion into the Linux kernel. We have run FSX tests for 1 million iterations, can copy the entire Linux kernel, and have run the Basic Functional Connectathon tests on eCryptfs as of today. I just wrote up a patch today to provide derived initialization vectors rather than interspersed initialization vectors. Derived IV's significantly reduce the read/write overhead incurred and slightly reduce storage requirements, but the tradeoffs are (a) possibly less security if an attacker happens to have access to each intermediate iteration of the encrypted file and (b) no sparse regions in the encrypted files (which is not necessarily a bad thing) -- unless I change the file format again to provide sparse region scatterlists, but that sort of things will have to wait for a future release. As soon as I get the changes reviewed by my team, I will commit them, and eCryptfs will handle both formats. Policy will select which one is used in later versions.

We have one reproducible error at the moment with certain gcc jobs that involve ecryptfs_lookup() -- there seems to be some in-kernel memory corruption. We're in the process of tracking that one down, and then (hopefully with no more bugs) we should be set for a release as an experimental filesystem in the kernel. Any FS guru's out there who are willing to jump in and help at this point are certainly welcome:

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ecryptfs login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ecryptfs co -P -r v0_1 ecryptfs

Thanks,
Mike

Coming soon: eCryptfs

Posted Oct 28, 2005 2:16 UTC (Fri) by Webexcess (guest, #197) [Link]

I attended the eCryptfs OLS talk this year and I am very interested to see this filesystem in the linus kernel.

Heaps of respect to the eCryptfs hackers for such an elegant solution to a thorny problem.

dm-crypt?

Posted Oct 28, 2005 2:25 UTC (Fri) by liamh (guest, #4872) [Link] (2 responses)

So what does this offer that is different from the established dm-crypt which can be used with any filesystem?

dm-crypt?

Posted Oct 28, 2005 9:07 UTC (Fri) by Trou.fr (subscriber, #26289) [Link] (1 responses)

this is completely different, with dm-crypt you create the filesystem over the encryption layer. So if you backup your files to a non-secure FS, you will lose encryption.
This one handles encryption over the filesystem, file by file, so this is much more flexible.

Raphaël

and maybe not as secure

Posted Nov 3, 2005 19:59 UTC (Thu) by niner (guest, #26151) [Link]

Depending on the application it's possible, that even the cleartext filenames and sizes give away too much information.

For things like passwordmanager files, diaries and such it's obviously ok.

EncFS

Posted Nov 4, 2005 20:14 UTC (Fri) by gdamjan (subscriber, #33634) [Link] (1 responses)

I've been using EncFS some time now, and it's been great.

EncFS is a user-space application (works via FUSE), uses OpenSSL for the encryption so it supports all the ciphers and digest in openssl, and since Fuse is in vanilla 2.6.14 it's even easier.

How is this better?

EncFS

Posted Nov 10, 2006 23:38 UTC (Fri) by felipe_alfaro (guest, #10677) [Link]

First of all, it's a kernel service, which will make it faster than using FUSE modules. Second, it will probably allow using different cipher algorithms/key lengths for different files. For example, it might make sense to use AES/256 for my keyring file, but AES/128 for a long confidential document.