[Discuss] encryption and rsync

[Edward Ned Harvey]

> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Tom Metro
> 
> According to:
> http://en.wikipedia.org/wiki/Encfs
> 
>   Two directories are involved in mounting an EncFS filesystem: the
>   source directory, and the mountpoint. Each file in the mountpoint has
>   a specific file in the source directory that corresponds to it. The
>   file in the mountpoint provides the unencrypted view of the one in the
>   source directory. Filenames are encrypted in the source directory.
> 
> So you're syncing the encrypted files in the source directory. That
> makes a lot more sense than using an encryption technology that just
> creates an opaque image file.

I use whole-disk, and file containers, and encfs, all for different
purposes.  Each one of them makes sense in certain situations.

Encfs works well, to encrypt the contents of your dropbox and share with
other people.  Via fuse, you mount some directory un-encrypted, where you
will be opening, editing, renaming your files.  Meanwhile, fuse & encfs are
translating all those operations into encrypted operations that it's
performing in some other directory.  If the backend encrypted directory
happens to be in dropbox (or whatever) it's a pretty slick solution.


> But I'm assuming that EncFS isn't doing anything to assist the syncing
> of partial files, so your minimum transfer is a full file.

Correct.


> I've heard EncFS works well with services like DropBox. (I've also heard
> of people using TrueCrypt with DropBox, which doesn't make much sense to
> me.)

Agreed.


> One of the ways this can be addressed is to locally store an index of
> file checksums, and only when you have a checksum mismatch, you process
> the file. (With some effort this could be carried to finer granularity.)

I suggested that to the rsync folks some years ago, and they said they
didn't like the idea.  Do you know anything or anyone else that actually
does this?