The key to dropbox's awesomeness is delta compression, which this is totally going to destroy. Aside from placing a greater load on their servers in terms of storage and bandwidth, it will degrade your experience. Caveat emptor.
The key to dropbox's awesomeness is delta compression, which this is totally going to destroy
Not necessarily. It looks like encfs is vulnerable to a cleaning lady attack, in which case dropbox (acting as cleaning lady) will be able to recognize and take advantage of unmodified blocks.
That said, this approach won't be able to recognize blocks which are duplicated (rather than merely unmodified) either within a file or between two different files (actually, I'm not sure if dropbox can recognize data duplicated between different files, even without encryption; but tarsnap can), and sensible generally want their encrypted filesystems to be secure -- so this really isn't a very good solution.
Actually, I've been using encfs on Dropbox, and size really isn't much of an issue. In practice, I mostly want to synchronize dot-files and other small files across computers, and broadband to Dropbox isn't terribly slow.
The real issue is conflict handling. When Dropbox detects a conflict between two versions which have become out of sync in a non-fast-forward type way, it creates two versions, the more recent version, and the old version with the host that created it and the date.
This is probably the right thing to do, but since it is doing so for the encrypted versions of the files, rather than the unencrypted versions, you end up with files like: "./j85-6kOFk3Gg0Lg1TiuqgqIz/8p2kJa8tboYSSpadfuiE9Tuq" and "./j85-6kOFk3Gg0Lg1TiuqgqIz/8p2kJa8tboYSSpadfuiE9Tuq (quiet's conflicted copy 2009-10-21)" with seemingly no way to access the conflict version through encfs.
If anyone has an idea how to fix this, I'd quite appreciate it. Otherwise, I'd really caution anyone from using encfs as a solution to encryption on Dropbox!
(TrueCrypt is a terrible solution for this as described in the posts below, due to needing to sync the whole volume every time.)
Actually, I keep my KeePass database in a 64MB TrueCrypt container in my Dropbox directory, and noticed that small changes propagate very quickly - it's definitely not syncing the entire 64MB every time the contents change slightly.
I don't know whether this attests to Dropbox's amazing delta compression, or implicates TrueCrypt's encryption.
the use case discussed in the article seems to be exactly the one for tarsnap (http://www.tarsnap.com/), that is encrypted remote backups. the only upside is this this awkward setup is free (or ~ 1 dollar a month cheaper), though at the cost of being much more adhoc.
Depends on what the daemon is doing. JungleDisk and Arq backup products for instance are daemons on my box, but LittleSnitch tells me they're only writing to S3 which is a public API, and I can verify what's in my S3 account. Not so much with Dropbox -- can't tell what's going through that SSL connection.
I'm not affiliated with them, but if you want zero-knowledge, encrypted dropbox-esque storage (and a few other benefits) you might try spideroak instead.
Ideally it should otherwise you are vulnerable to a range of differential attacks. In practice it's a compromise between performance and security.
It might very well touch a large number of blocks to stop an attacker working out where on a disk a particular file is. There are a bunch of rsync freindly crypto implementations that minimize this effect
How exactly would an attacker have enough access to your encrypted data to do a diff attack? If he has physical access to the machine you're going to be compromised regardless of the details of the encryption scheme.
