ecryptfs-users team mailing list archive

["Serge E. Hallyn" <serge.hallyn@xxxxxxxxxxxxx>]

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.
> 
> 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).

So you can keep unencrypted filenames in .Private, and rsync that
over ssh, then filenames are protected in transit, and are clear
at the endpoints (for easier cherryp-picked recovery).

-serge