ecryptfs-users team mailing list archive

[John Magolske <listmail@xxxxxxx>]

* Serge E. Hallyn <serge.hallyn@xxxxxxxxxxxxx> [110214 14:22]:
> Quoting Dustin Kirkland (kirkland@xxxxxxxxxx):
> > On Mon, Feb 14, 2011 at 12:43 PM, John Magolske <listmail@xxxxxxx> wrote:
> > > Would filename encryption impact the rsync process in any way? Another
> > > issue related to filename encryption would be retrieving files. If all
> > > file & directory names are encrypted, it seems that to retrieve any
> > > particular file would involve retrieving the entire ***GB chunk and
> > > decrypting it locally. This is why I'm hoping the sshfs scenario might
> > > work. I'll give it a try when I get a remote set up, just curious if
> > > anyone has experience decrypting a remote directory locally via sshfs,
> > > and if there might be any security issues related to that approach.
> > 
> > I personally don't know how well eCryptfs is going to work on top of
> > sshfs.  eCryptfs is known to be broken when stacked on top of NFS and
> > Samba.  In general, I'm wary of stacking eCryptfs on top of anything
> > other than a normal Linux filesystem (ie, ext3, ext4, xfs, etc).
> > 
> > As for filenames, they stay the same, even if the content changes, so
> > rsync will deal with them just fine.  So that's cool.

Great!

> > It is a little harder to find the particular file that you need, when
> > the filename is encrypted.  That kinda stinks.  We've been talking for
> > years about writing a little C program, ecryptfs-decrypt-filename and
> > ecryptfs-encrypt-filename, that takes a filename as an argument, and
> > spits out the encrypted or decrypted value.  This would certainly help
> > in finding files and paths.  It doesn't exist yet.  Sorry.
> 
> But I'm not sure John's requirements are well understood.  John, you
> are talking as though sshfs is a substitute for filename encryption.
> sshfs will only cause the data to be encrypted over the link, not
> at rest.  If that is all you need, then you can use ssh transport in
> regular rsync (which is the default).

I had a couple of requirements in mind for different use-cases,
one of which would be to have the file-names encrypted at rest so
as to present maximum opacity to anyone with access to the remote
server. The idea of using sshfs here would be to mount the fully
encrypted remote filesystem locally and decrypt it locally, allowing
the filenames & directories to be easily browsed. As Dustin points
out, that may not work so well. I'll experiment further with this
at some point...reading through some related issues here:

  Bug #376580 in eCryptfs: “support "reverse" mode”
  https://bugs.launchpad.net/ecryptfs/+bug/376580

Regards,

John

-- 
John Magolske
http://B79.net/contact