~ecryptfs/ecryptfs/trunk

Viewing all changes in revision 272.

  • Committer: Dustin Kirkland
  • Date: 2009-01-22 00:58:21 UTC
  • Revision ID: git-v1:d0d0782ff84bd0c8deead3c695a7e13f7874b175
filename encryption userspace support

Recent changes to the ecryptfs kernel code has added support for
filename encryption.

The basic userspace support was a added a few weeks ago.  You can
specify the key in the kernel keyring to use as a mount parameter,
with:
  ecryptfs_fnek_sig=0000000000000000

This patch adds a couple of conveniences, mainly in support of using
encrypting filenames easily with the encrypted-home and
encrypted-private features of ecryptfs.

In these scenarios, the filename encryption key is dynamically
(but programmatically) generated using the mount passphrase.

The mount passphrase is salted, hashed 65536 times using sha512,
converted to hex, and truncated to 16 digits long (128 bits).  This
value is used as the filename encryption passphrase.

Should the filename encryption password be compromised, one would
have to reverse this process.  We have designed this to be
cryptographically very difficult.

The signature of the filename encryption key (often abbreviated
"fnek") should be specified in ~/.ecryptfs/Private_fnek.sig.

If this file exists and contains a valid signature, the
mount.ecryptfs_private helper will specify this key in the mount
options as described above.

The pam_ecryptfs modules will continue to insert the wrapped
passphrase into the kernel keyring.  I have modified the base
library functionality to unconditionally also insert the fnek
passphrase.  THIS SHOULD BE FIXED IN A SUBSEQUENT COMMIT.

Also, the ecryptfs-setup-private utility needs to be enhanced
to write out the Private_fnek.sig file.  This may necessitate
a new binary utility to perform this operation.

Signed-off-by: Dustin Kirkland <kirkland@canonical.com>

expand all expand all

Show diffs side-by-side

added added

removed removed

Lines of Context: