If Dropbox were designed to handle sequentially-numbered blobs of encrypted data, changing one file would require your other devices to download only that file (an encrypted blob of roughly the same size).
With a TrueCrypt volume or other encrypted file solution on top of Dropbox, you have to resync the entire multi-GB volume any time a single file in there changes, since to Dropbox it's just one big file. (Another option is to use something like an OS X sparsebundle -- encrypted data banded across many files -- but God help you if you have two computers reading/writing from that sparsebundle at once.)
I've started using SpiderOak and it is quite efficient even though the data is encrypted such that the server admins couldn't see your data even if they wanted too. https://spideroak.com/engineering_matters SpiderOak also offers two-factor auth. (The SpiderOak UI, however, is fairly atrocious.)
If Dropbox were designed to handle sequentially-numbered blobs of encrypted data, changing one file would require your other devices to download only that file (an encrypted blob of roughly the same size).
But they do: store files and name them sequentially ;)
I think Encfs is the best solution, since it encrypts each file separately. Just mount the encrypted end over the Dropbox directory and the plaintext end somewhere else, and use it transparently.
Only part of a truecrypt volume changes when you make a change to the data within. Since Dropbox intelligently syncs files in parts, only part of a truecrypt volume has to be re-uploaded when something changes -- not the entire multi-GB file. I know because I do exactly this with a 1GB file. It takes about 2 minutes to sync when I unmount the file. Dropbox is not re-uploading all 1GB.
However, like the other commenter, I still recommend encfs for most uses.
If you only have Macs, using an encrypted sparse bundle disk image is pretty simple, and changed files result in a small delta for dropbox to sync. It's built in and you'll be up and running in a couple minutes: http://matthew.mceachen.us/blog/free-easy-encrypted-storage-...
it is only simple if you always manage not to open such a sparse bundle on another Mac before it has been fully synced after being used on another Mac. Otherwise, you will mess up your sparse bundle sooner or later.
A service for syncing and sharing with built-in encryption might therefore me more convenient for most users. Spideroak and Wuala are two examples.
The downside, of course, is no differential sync'ing. So, if you make a change to your volume, you must re-upload the entire volume.
Worth doing for some files, yes, but still a pain. Per-file encryption would be ideal, but a monstrous pain to implement with TrueCrypt.
Dropbox is probably not crazy about widespread encryption because it would eliminate their ability to perform deduplication. Perhaps they could get around this if you had a special encrypted quota. For example, you have 5GB of space and 100MB of encrypted space.
You would also lose easy access to file histories, correct? This is one reason why I'm a fan of SpiderOak -- the index remains encrypted, but file histories are still stored (efficiently).
What do you know, you're right. I am impressed; I was under the impression that because of the encryption, Dropbox couldn't reliably determine what pieces changed.
Truecrypt is designed to work on a block-by-block basis or else it would be horribly slow at everything. So dropbox's job isn't harder than any arbitrary binary file with a few KB changing. Easier, really, since nothing changes size and shifts the data after it.
Kinda defeats the purpose of DropBox. If you're going to use volume encryption, might as well use Tarsnap or something else to just backup the one large file.
Consider what your goals are with respect to encryption -- allowing the deltas generated by modifying your TrueCrypt volume will almost certainly make it easier for an adversary to break into your encrypted volume.
Are the algorithms used weak to that? I know that deltas will reveal the locations of changes and also let you detect whenever the same sector has the same bytes written to it. What else might be revealed?
