discussion

Hi Martin,

imho you should take a look at ecryptfs too

http://sunoano.name/ws/public_xhtml/debian_security.html#filesystem-level_encryption

I have also been evaluating how to do backup/sync to remote machines using Unison and how to protect (encrypt that is) stuff on the remote end … turned out ecryptfs is, imo, the best tool to do it.

Hi Suno,

I briefly looked at ecryptfs, but I could not find answers to the following questions, and IRC seems dead:

can ecryptfs provide an encrypted view into a normal directory, like encfs --reverse?

can it encrypt filenames using IV chaining in that mode?

I just experimented a bit and found the option ecryptfs_encrypted_view, which does exactly what --reverse does, and it’s what I want. --reverse means that I can use /srv/backups locally as I would, and create a temporary, encrypted export of that directory for the purpose of rsync:
pulse:~# ls -l /srv/backups
total 17708312
drwxr-s--- 4 bk-albatross  bk-albatross      4096 2008-06-23 17:04 albatross
[...]

pulse:~# encfs --reverse --stdinpass /srv/backups /tmp/encfs
EncFS Password:

pulse:~# ls -l /tmp/encfs
total 17708324
drwxr-s--- 4 bk-albatross  bk-albatross      4096 2008-11-21 01:00 xxxxxxxxxxxxxxxxxxxxxxxx
[...]
and now I can use rsync to keep a remote mirror of this virtual directory.

I really prefer this over storing /srv/backups itself encrypted because the entire filesystem is already encrypted and that would just be a waste of resources.

The feature I am missing from ecryptfs is filename encryption: the encrypted files have unencrypted filenames, which can give away a lot of information. For instance, I name all my documents in a way that has date, correspondents, and subject in the filename, e.g.
2009.07.12:vSune_suggests_ecryptfs_with_link.msg
encfs can at least block-encrypt them, even though it does not do IV-chaining in that mode (yet). Combined with rsync --fake-super on a non-privileged account, this ensures that an attacker cannot easily deduce information about the files, permissions, or owners based on just the file listing.

In the end, encfs is the best solution for me, and now that the remote admin created a new filesystem with 4k blocks, I also don’t have any more problems with it.

as you have already figured, you can have a encrypted view into a normal directory
you can have filename encryption too of course; works for kernel versions >= 2.6.29, see my article
about your concerns with regards to resources … if I understand correctly, you already use some sort of full-disk encryption below the filesystem layer?! If so, then using ecryptfs (filesystem-level encryption) atop the filessytem and therefore also atop the crypt container e.g. dm-crypt does not need to condern you with regards to resources I’d say. The overhead is minimal, not even worth mentioning … only if you want to run the whole shebang on your cell or so might it make a difference :) The only question is if you need another encryption layer in addition to a full-disk encryption setup …. for the more paranoid, the answer is yes I guess ;-]

Turns out ecryptfs_encrypted_view is not what I want: It doesn’t encrypt plaintext files on read(), it simply gives merges the different ways to store the metadata for encrypted files. So, if you have the metadata stored in xattrs, it will move it to the file header on read(),