Dropbox Encryption with TrueCrypt

In combination with some (really simple) bash scripts for mount- and unmounting, this is imho a good way to encrypyt files inside your Dropbox.

http://news.ycombinator.com/item?id=895660

Dropbox supposedly encrypts server side. If you want to encrypt client-side, use SpiderOak or TarSnap. These hacks on top of Dropbox don't mesh with the semantics of Dropbox properly and will cause problems days, weeks, or months down the line unless managed extremely carefully.

EncFS is somewhat better in terms of sync, because it encrypts each file separately.

Here's a nice tutorial: http://pragmattica.wordpress.com/2009/05/10/encrypting-your-...

I have ~2.5GB of encrypted files in my Dropbox, and as long as I don't try to edit the same file in two places at the same time, it works like a charm. (Conflicts can be nasty, as another comment says. But it's not as bad as TrueCrypt, because EncFS works per-file.) Editing different files at the same time, on the other hand, is kosher.

There are, however, a few other problems with EncFS.

First of all, you can't mount an EncFS directory tree from Windows. There's an actively developed Windows port of EncFS out there (which uses Dokan), but I've never been able to get it to work properly.

Also, Windows has a maximum path length limit of 260 chars. Since EncFS pads file names with unique IVs and base64 encodes them after encrypting them, you can reach this limit after only 3-4 levels of subdirectories. Paths which are too long for Windows will simply be omitted from the Windows copy of your Dropbox folder. So if you ever treat the Windows copy as an authoritative backup, you're in for a nasty surprise. Linux is OK up to 4096 chars. I'm not sure how OSX does it.

Lastly, Dropbox in Linux tends to choke when you add a large number of files with encrypted filenames. It's not uncommon for Dropbox to declare a "case conflict" in that situation when there actually isn't any case conflict. This can seriously damage your EncFS directory tree, because Dropbox adds the phrase "(Case Conflict 1)" to random files and folders. An easily solution is to stop Dropbox, add the files, and restart Dropbox again. But this can get annoying after a while.

I use Dropbox more like a thumbdrive for temporary transfers and I like to have the warm and fuzzies that my data at rest is protected with strong encryption.

This article resembles the recent posts about using git on Dropbox - I wonder if people actually tried this for a longer period, because it just doesn't work, unless you mount the volume only one machine simultaneously and always sync after unmounting (easy to forget after mobile use).

I program out of my TrueCrypt volume while in Windows, unmount it, and let it sync. It's a super-easy backup, and DropBox is the only one I've used that handles a 1GB file correctly, and it does it without a hitch.

Worst-case-scenario is you do cause a collision, and you just mount both volumes at once and copy stuff to the one you want to keep.

At this point I have been playing around with 700mb file volumes. When I make an addition to the volume, it takes about 2 minutes to sync. I have not tested deletions yet.

Of course, that's infeasible for file system encryption and isn't how TrueCrypt works. An idea is to use a one-to-one mapping between TrueCrypt blocks and DropBox files. Write a file system watcher script that picks up changes to files in the DropBox folder and mirrors the changes to the corresponding blocks in a TrueCrypt volume that lives outside the DropBox folder. The other way around, too.

Do you see anything obviously wrong-headed with this approach? I admittedly don't know the details of TrueCrypt's crypto. If it already does file-level rather than block-level encryption, these tricks wouldn't be necessary. But file-level encryption would seem to leak way too much information to satisfy the truly paranoid.