Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] encryption and rsync



On 7/16/2012 1:59 AM, Tom Metro wrote:
> 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.

Correct, at least for my needs.  There is a 1:1 correspondence between 
native file system and EncFS file system so an attacker can easily track 
changes.  This kind of analysis is not feasible with a monolithic container.

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

Also correct in the typical case.  It's not an issue for small files 
since small files are transferred in full most of the time anyway.  It 
does lend itself to auto-sync services like DropBox since it's mostly 
just deltas being synchronized.  It's not as efficient as DropBox on a 
native file system but it's much more efficient than trying to sync a 
big container file.

rsyncrypto breaks this behavior.  You always get the same ciphertext for 
a given input set.  That's the only way that partial transmission can 
work with encrypted data on the target side.  This is the weakening of 
which they describe.

-- 
Rich P.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org