I'm surprised Jon Callas hadn't realized Dropbox is able to decrypt your files. It always seemed obvious to me given several of Dropbox's advertised features necessitate it (in particular accessing your files over the web interface, and probably their sharing features). Most users wouldn't understand this, but the founder and CTO of PGP Corp should.
That said, this article is incorrect on at least one point: de-duplication does not require Dropbox be able to decrypt your files. tzs came up with this clever scheme in a previous comment: http://news.ycombinator.com/item?id=2461713
Of course even if Dropbox didn't have the keys to decrypt your files you're still trusting them (or SpiderOak or Wuala or most of Dropbox's competitors) by running their proprietary software. But I suppose people are more concerned about subpoenas and compromised servers than malicious actions by Dropbox themselves.
> Of course even if Dropbox didn't have the keys to decrypt your files you're still trusting them (or SpiderOak or Wuala or most of Dropbox's competitors) by running their proprietary software.
You don't have to trust tarsnap. Block encryption happens client side using open source software.
I wish tarsnap was in the same game as Dropbox, I'd pay for it. But as it stands Dropbox is an extremely convenient, general-purpose "network folder". And tarsnap is a backup-tool for unix admins.
I guess this wasn't meant as a feature comparison between both tools but as proof that it is possible to create fully transparent tools for sharing encrypted data across the internet.
I'm not sure why this gets brought up with Dropbox.
Of course it's possible to provide a service which only receives and stores encrypted data. At that point Dropbox would cease to exist. Half the posts about dropbox are lauding it for doing one simple thing well. Your Dropbox/ folder is shared with no fuss.
The other half of posts about dropbox are ribbing on it for not being secure enough.
Here's a clue: If I had to carry an private key with me to decrypt data stored in dropbox i might as well just carry the data.
The scheme tzs came up with provides questionable security, which was also pointed out by other commenters. It offers no protection against hiding the fact that you are in posession of a known file.
For instance, say you are a whistleblower and you have a stash of documents nobody should know you have. Your opponent, having a copy of those documents, can produce an identical encrypted file. What's more, Dropbox obviously already has a mechanism to look up digests so checking wheter the document is stored with Dropbox or not is probably a matter of milliseconds.
Also, as someone pointed out, deriving the key from the cleartext is probably a very Bad Idea.
The only workable approach I can think of is to encrypt and decrypt data on the client. Any scenario where encryption takes place on the server is suspect.
My personal workaround for this is to use Dropbox to store encrypted filesystem images that I can mount on my machine. This severely limits the usefulness and performance of the service, but has turned out to work reasonably well.
Precisely this. Encfs is particularly good for this if you're on a unix-y environment. Otherwise, TrueCrypt might fit the bill (though concurrent access from several machines can be an issue)
True, but I don't think that's a concern for most people.
What are the practical implications? The only one I can think of is if someone were trying to prove in court that you had a particular file.
A related question I've been wondering about is whether a hash or key+ciphertext are considered proof of possession of the original file. In theory an infinite number of files have the same hash, and the ciphertext could have been produced using a different key (or it could just be random data). In practice it's extremely unlikely (for sufficiently secure hash and encryption functions). What are the laws'/courts' views on cryptography?
Doesn't the theory of infinite collisions existing, require that you are nit restricting the file size? The combination of "the hashes match" and the file sizes are roughly the same would seem to go beyond a reasonable doubt.
Not really. Let's use for example a 256 bit hash and a 1KB file. That means you have about 2 ^ (1024 * 8 - 256) collisions that are the exact right size. Close enough to infinite for any file that's at least a hundred bytes. The more pressing concern is how hard it is to fake a particular hash.
>True, but I don't think that's a concern for most people.
But that is the kind of thinking that lead to the whole issue with Dropbox in the first place. Its deceptively "secure" to any user who can't analyze the implementation implications themselves.
Well, yes, that's the point of the deduplication. If you already have the same exact file, in its entirety, you can check if it's in the system or not.
Regarding tzs's system - it fails in two particular aspects: Web-based upload of files and adding a new hash/key to the database encrypted with your password.
Well, fails in that the current operation of Dropbox was a clue that they were not employing anything like tzs's system.
Web-based upload would have required three time/CPU intensive steps: Hashing the contents of the file to create the related encryption key, encrypting the file with said key, then re-hashing the file to get the new "fingerprint" of the encrypted version.
The reason this would all be required is that Dropbox is not only worried about deduplication for storage - they're worried about it for bandwidth saving. When you upload a file to Dropbox that they've "seen", they give you instant upload credit for it and skip the entire process (which users enjoy for the speed and they enjoy for the pocketbook in bandwidth savings).
With an appropriate hash and a block ciper choice, yes, they could do this without creating a client-side duplicate/encrypted file. They could do it as they go (hash the entire file, start encrypting it into a short buffer, then start hashing the buffer) - but if they're not storing a duplicate/encrypted copy locally, they're going to have to re-encrypt it as they go (again) during the upload phase.
So that's: One hash for the key, one encrypt + rehash for the fingerprint, then one more re-encrypt for the upload.
... and then you would run into the other problem I mentioned - where you also have to download the remote database, decrypt it locally, add your new entry to it, then re-upload the encrypted version. All from the web client.
Considering how quickly the upload starts - it's pretty obvious they're doing nothing even remotely like this.
(I understand that we know for a fact Dropbox has access to the files on their servers - I just wanted to expand on the proof that, based on how they were operating, that they couldn't possibly not have access. But then, I've been saying this all along.)
That said, this article is incorrect on at least one point: de-duplication does not require Dropbox be able to decrypt your files. tzs came up with this clever scheme in a previous comment: http://news.ycombinator.com/item?id=2461713
Of course even if Dropbox didn't have the keys to decrypt your files you're still trusting them (or SpiderOak or Wuala or most of Dropbox's competitors) by running their proprietary software. But I suppose people are more concerned about subpoenas and compromised servers than malicious actions by Dropbox themselves.