5 ms·
Please be cautious: EncFS was not designed to resist an attacker having ongoing access to the volume, as they would in this scenario! In particular, an attacke
by AlyssaRowan 12y ago
Please be cautious: EncFS was not designed to resist an attacker having ongoing access to the volume, as they would in this scenario!
In particular, an attacker having access to the ciphertext at two or more different times violates EncFS's security assumptions; undetected malicious modification of files is also feasible in this scenario.
Many encrypted filesystems do not include such a property in their design criteria - for example, XTS mode as-is is not suitable for use in this scenario either, so please also try to avoid putting TrueCrypt (et al) on Dropbox!
For a broad general example of what a system would look like which tries to address this use case more naturally and effectively (although, caveat: I have not reviewed it in great detail myself), please see Tahoe-LAFS.
- StavrosK 12y agoDamn! What's the vulnerability? Do they reuse IVs or something? No wonder I got stuck when designing my own encrypted filesystem, I didn't have this assumption. On the plus side, mine was safer. I'll have to revisit it.
- namityadav 12y agoI've been using Dropbox with EncFS, and I feel foolish about not thinking of the fact that Dropbox has ongoing access to the encrypted files. Would you recommend something other than Dropbox + EncFS as the best compromise for a file-sync solution that has reasonable security, a non-buggy client, supports block-level sync, is reasonably priced and "just works"? BitTorrent Sync + EncFS?