![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |