In keeping with the spirit of this blog (i.e., gut feeling versus rational decision-making), I would like to carry over a technical and philosophical discussion on the Dropbox Votebox forums concerning the desire many users have for client-side encryption offered by the sync client and explain why the idea, while seemingly useful, is basically flawed on two levels.
For those of your unfamiliar with Dropbox
Essentially, Dropbox is an online cloud-based data sotrage system that allows you to connect many computers and mobile devices together to store, back up and syncronize files just like you would on your hard disk. Go here and watch the video. I love the service.
The argument
The argument follows like this:
- We, the users, store data locally and can enforce local security policies to protect our data (such as file-system permissions, full-disk encryption, user logins, encrypted partitions, etc.).
- While Dropbox does employ a number of security measures (see Amazon S3 and Amazon Web Services: Overview of Security Processes), we're still concerned because we lose all of these local security measures once files are released to Dropbox.
- We want the ability to store semi-sensitive or mission-critical data in our Dropbox but don't want it stored in the clear: we want it encrypted.
- Please develop a client-side encryption mechanism which would encrypt data before it's sent to the Dropbox servers and let us generate our own key for obvious security reasons.
This may seem, at first, to have all the ingredients of a good security policy. It also shows that users are more concerned about having their personal and private data out on the internet and this is a very good thing.
The two basic flaws
The argument, however, suffers from two basic flaws which render its implementation cryptographically meaningless at best.
First, let's imagine that you are able to generate a local encryption key of whatever length and type you want. If you rely on the Dropbox application to manage your encryption for you, which is the suggestion, you must provide the key to the local application. As soon as you do that, you have effectively lost any security that encrypting the data might give you. You must trust that the Dropbox client app doesn't store your key in some central repository.
Since one of the basic tenets supporting the argument for client-side encryption is that the service is an untrusted third party, relinquishing the encryption key to that same service defeats any security gained from encrypting the data in the first place.
Second, and this problem is as old as cryptography itself, how do you move the key from one machine to another? Most people will instinctively suggest employing some sort of public key infrastructure, the holy grail of modern cryptography. Well, you can't employ a typical public key infrastructure precisely because you need the private key available at many locations to decrypt that data locally.
The next obvious suggestion, encrypting data to a set of public keys for each machine (as we do for a cc: series of encrypted emails to multiple recipients) carries with it two problems. First is simply massive data replication because the system would have to create and store one encrypted copy for each linked machine, and each copy would be different. So your 50 GB Dropbox account has just ballooned to 50 x (number of linked computers) GB. Second, time and bandwidth to sync even small changes would expand exponentially and who wants that?
Asymmetric keys, then, would seem to fail the usefulness test, and we might as well use symmetric keys. Let's be honest: Alice is never going put that key on a thumb drive and bring it to Bob in person, she's probably going to let Dropbox move the key for her for the sake of convenience.
And then, what do you do with the case of shared folders? Do you encrypt them with your key and the other users' key(s), or with a second key specifically generated for that share? Again, how do you distribute the key to the followers and how do you deal with data replication mentioned above?
Then there are the inevitable problems with inexperienced and technologically-disinclined users who have to reformat their computer, lose their key, and call tech support to retrieve their doctoral dissertation (which should be impossible).
One should keep these two channels separate: cloud storage and data encryption. If you really need data security, make a TrueCrypt volume (with clients available for Windows, Mac and Linux) and store the container in your Dropbox.
A big drawback to the TrueCrypt solution
It's fine for me to spout about storing a TypeCrypt volume container and to sync that, but there is one rather glaring unfortunate side-effect of the way both Dropbox and encryption work.
At present, Dropbox doesn't calculate bit-level changes in files to synchronize: it recognizes, uploads and downloads entire files that it sees have changed (probably by calculating and comparing hashes of local and system-stored files). If you have a 1 GB container file and change even the file modification time of a 2 kb text file within it, it's going to have to upload the entire 1 GB container and synchronize it across all your linked machines.
That is, undoubtedly, an inconvenient solution.
