> Encrypt with Truecrypt, share with Dropbox. Problem solved.

Not so fast. How big is the binary diff when you change a file within a Truecrypt volume? Ie, how much Dropbox bandwidth will you be using, even with a small change?

I performed the following experiment. Start with a 250M Truecrypt volume. Mount it. Create a 1M file from /dev/random. Unmount the volume.

Now, look at what blocks in the Truecrypt volume file have changed. Dropbox uses a 4M blocksize [1].

  seq 0 63 | while read i; do
    { dd bs=4M skip=$i count=0; dd bs=4M count=1; } < truecrypt.bin.before | md5sum
  done 2>/dev/null | sort > md5s.before

  seq 0 63 | while read i; do
    { dd bs=4M skip=$i count=0; dd bs=4M count=1; } < truecrypt.bin.after | md5sum
  done 2>/dev/null | sort > md5s.after

  comm -13 md5s.before md5s.after | wc -l
  8

Conclusion: in this case, Dropbox will transfer 32M (8x the normal 4M) because I added a 1M file to my Truecrypt volume. Note: I haven't tried adding bigger files, but suspect the number of blocks changed will go up linearly but steeply with the size of the added file.

It's not actually that surprising that TrueCrypt mixes file changes throughout the volume file.

Why bring this all up? Because something that does client side block encryption (tarsnap is an example) would only transfer the affected block. 4M, if that's the block size.

And you don't have to trust the cloud storage provider at all.

EDIT: My pipelines were wrong on the first go, suggesting a much larger number of differing blocks. Sorry about that.

[1] http://forums.dropbox.com/topic.php?id=17631

Except then you can't use those files on mobile devices or from the web UI, both of which are useful (my primary interest in dropbox, and the one thing I can't trivially accomplish on my own, is the iOS device support. The alternative is just to use Apple's iDisk, which has exactly the same risks as Dropbox, minus the cross-platform capabilities.)