Filenames in ~/.Private are not encrypted

[ehcpdeveloper]

As Per https://wiki.ubuntu.com/EncryptedPrivateDirectory I created a private directory.
Ii mounted it, then put some files in it.
Then unmounted the Private dir.
~/Private contains only "THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA -- Run mount.ecryptfs_private to mount again"

~/.Private still contains all the private files, albeit the contents are indeed encrypted...

I had expected that the filesystem of ~/Private would also be encrypted so that a potential data thief would not even know what files I have on my system.

[Jean-Baptiste Lallement (jibel)]

Thanks for your report. Affecting to ecryptfs-utils and confirmed in Intrepid.

j-lallement@black:/tmp$ lsb_release -rd; apt-cache policy ecryptfs-utils
Description: Ubuntu intrepid (development branch)
Release: 8.10
ecryptfs-utils:
  Installed: 53-1ubuntu8
  Candidate: 53-1ubuntu8
  Version table:
 *** 53-1ubuntu8 0

[Jean-Baptiste Lallement (jibel)]

btw the contents of the file in .Private are encrypted but not the filename itself.

[Dereck Wonnacott (dereck)]

I would also prefer that the filesystem of ~/.Private were encrypted in such a way that it would be impossible to identify what files exist in the directory when encrypted.

Maybe the users should be warned when they set up their ~/Private directory, the file names are not encrypted.

[Dustin Kirkland  (kirkland)]

Please see the upstream eCryptfs FAQ:
 * http://ecryptfs.sourceforge.net/ecryptfs-faq.html#filename-enc

In brief, there are some complex problems with filename encryption,
however, it is a known feature-request, and a the upstream authors
plan to implement it at some point.

Quoting here:
  Q. What about filename encryption?

  The namespace problem arises when we consider the case
  where two files have the same unencrypted name. This can
  be a problem when the user does not have the key for every
  file in any given directory. Imagine, for instance, that Alice
  creates a file named ``meeting_notes.txt'' in a shared directory
  on an NFS server. The filename is encrypted with a key known
  only to Alice and Carol. Bob then creates a file in the same
  shared NFS directory and also names it ``meeting_notes.txt'',
  encrypting the filename with another key only known to Bob
  and Carol. Bob's eCryptfs client cannot detect the unencrypted
  filename conflict in the namespace because Bob does not have
  Alice's key.

  So two different files that have the same unencrypted name and
  different encrypted names appear in the same directory. When
  Carol, who has both Alice's key and Bob's key, lists the contents
  of the directory, he winds up seeing two different files with the same
  filename in the same directory, which is a POSIX violation.

  The solution we may implement is to use a separate key just for
  filename encryption, requiring all filenames encrypted under any
  given directory to be encrypted with that key. Filename encryption
  is a planned feature, but there is currently no set date for when it
  will be completed.

:-Dustin

[Dustin Kirkland  (kirkland)]

The upstream feature request tracker URL is:
 * http://sourceforge.net/tracker/index.php?func=detail&aid=1618003&group_id=133988&atid=728802

:-Dustin

[ehcpdeveloper (ehcpdeveloper)]

one suggestion for developers of this:

you may simply gzip files, encrypt gzip,
then unzip upon mount...

[Thomas Novin (thomasn80)]

Yikes, just noticed this. I think Ubuntu should warn the user about this behaviour and maybe explain it in release notes and also on https://wiki.ubuntu.com/EncryptedPrivateDirectory

[Dustin Kirkland  (kirkland)]

I have added a note to this effect in the wiki spec in the Outstanding
Issues section.
 * https://wiki.ubuntu.com/EncryptedPrivateDirectory#For a Future Release

:-Dustin

[Chris Roddy (cmr)]

I understand that there are challenges to implementing encryption of the file names, but as it stands now I would describe these tools as unreleasable. I encourage the maintainers to withdraw this package from the distribution until this glaring design defect can be corrected.

An encrypted directory that leaks the names, directory structure, and file sizes in plain text is almost completely useless, and is in many ways worse than simply trying to hide them with dotfiles and misdirection -- at least in that case, I'm not waving a gigantic red flag that says "hey! here's all my secret shit! here's how i keep it organized, what i call it, and how big each file is!"

[Dustin Kirkland  (kirkland)]

Your concerns are noted, and the upstream ecryptfs kernel developers
are working on it. They have working prototypes, and are submitting
to -mm as soon as possible. We absolutely understand, respect, and
desire the additional security that will bring.

I disagree with your points that this should be disabled or removed,
and that the feature is useless.

When you use gpg to encrypt a single file, does it encrypt the file
name as well? No, it does not.

We're not forcing anyone to use this feature. And we're not dictating
what data goes into ~/Private.

This entirely an opt-in program.

I'm attaching the private half of an ssh key, pulled from the
encrypted .Private directory. If you or anyone else is able to crack
it, we would like to hear about it.

:-Dustin

[Sebastian Abate (sebastianabate)]

What about an option to use an encrypted filesystem image, instead of a directory? Then the image could be loop mounted on the ./Private directory, just like TrueCript does. I know this is only practical for a private directory, and not in a shared one, but the option could help mitigate this situation.

[Dustin Kirkland  (kirkland)]

On Thu, Oct 30, 2008 at 10:22 AM, Sebastian Abate
<email address hidden> wrote:
> What about an option to use an encrypted filesystem image, instead of a
> directory? Then the image could be loop mounted on the ./Private
> directory, just like TrueCript does. I know this is only practical for a
> private directory, and not in a shared one, but the option could help
> mitigate this situation.

A loop-mounted encrypted image would disallow incremental (rsync)
backups of the encrypted data, which is one of the key design points
of our Encrypted ~/Private Directory.

TrueCrypt has some serious licensing issues:
 * http://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt

Encrypted filenames are coming to eCryptfs. Give us a little more time.

:-Dustin

[Guillermo Pérez (bisho)]

For network-shared drives I understand the need of maintaining clean filenames (or at least use the same key for encrypt them) to avoid collisions.

But for user directories, there will be only one key, the key of the user, so that one can be used for encrypt filenames. encfs does this.

It could be an option like "one-user crypted directory". Implementing this will be a sort path to the real implementation the people from eCryptfs are working on, and it will be faster to offer to the public.

[Chris Cowan (macil)]

Would a solution to this (I'd assume an implementation of a "one-user crypted directory" like mentioned above) also encrypt directory names, and directory structures? The organization and names of folders could be stored inside a single encrypted file (that could even look no different than other files in the ~/.Private directory).

[Dustin Kirkland  (kirkland)]

The kernel patches required to solve this problem were accepted by
Andrew Morton into the Linux -mm experimental tree. They're going to
bake there for a little while and hopefully be merged by Linus into a
stable Linux kernel release soon. At which point, we will ask the
Ubuntu kernel team to bump kernel versions for Jaunty.

Please sit tight a little longer ;-)

And if you're really brave, go compile your own -mm kernel on a test
machine and try it out ;-)

:-Dustin

[cariboo (cariboo)]

Added a screenshot of .Private and Private not mounted.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 69-0ubuntu1

---------------
ecryptfs-utils (69-0ubuntu1) jaunty; urgency=low

  * New upstream release, dropped all patches (included upstream)
  * This release includes support for filename encryption (LP: #264977)
  * This release promotes keyutils from a 'recommends' to a 'depends,
    for access to the keyctl command, which is used by the helper scripts
    to clear the keyring on unmount (LP: #313812)

 -- Dustin Kirkland <email address hidden> Mon, 26 Jan 2009 13:51:21 -0500

[Removed by request (removed3425744)]

The faq http://ecryptfs.sourceforge.net/ecryptfs-faq.html#filename-enc still says that there is no filename encryption. Since this feature is already implemented somebody should update the faq to avoid confusing.

[Tyler Hicks (tyhicks)]

On 2012-12-22 21:26:28, Sworddragon wrote:
> The faq http://ecryptfs.sourceforge.net/ecryptfs-faq.html#filename-enc
> still says that there is no filename encryption. Since this feature is
> already implemented somebody should update the faq to avoid confusing.

Fixed - thanks!