Dropbox Can't See Your Dat– Er, Never Mind

bizwriter writes "Dropbox, the online backup and file sharing service claims to have hit 25 million users in a single year. But a change in terms, noting that Dropbox will give up data to law enforcement under a legal request, showed that the company's security claims couldn't be possible. It turns out that Dropbox claims in one place that encrypted data makes it impossible for employees to see into user files, but in another says that they're only 'prohibited' from doing so."

Comments

Re:It is not impossible

[gpuk]

I think the problem is that if you use a Truecrypt container and back that up to Dropbox, the Dropbox client is not always able to tell if any data has changed as changing the contents of the container does not always change the containers binary size on the disk. This means you can't do an incremental backup and instead have to force a full backup every time you alter what is inside the container, which isn't funny if your container is larger than a few hundred MBs.

Re:It is not impossible

[TheRaven64]

This is the point of tarsnap. Open source client, you can verify it and the encryption that it uses. It encrypts everything before uploading and can't be decrypted on the server without access to a key that's only stored in the client.

Re:It is not impossible

[LoudNoiseElitist]

That's the point. It looks for changes in the file. With encryption, the file usually *completely* changes, thus giving Dropbox no choice but to upload/download the whole thing.

Re:It is not impossible

[Anonymous Coward]

With encryption, the file usually *completely* changes, thus giving Dropbox no choice but to upload/download the whole thing.

I've never used truecrypt, but from what I know, I suspect the chances of the entire encrypted volume changing when you make any change is close to zero. It would kill performance to have to rewrite the entire volume every time. It has to only update portions. So then the possible solution to this would be to treat it like bittorrent does, where it breaks it into chunks and checksums each chunk. When only a small portion of the file changes, it then know which chunks to reupload. Whether or not dropbox can or does operate this way, I have no idea, but in general, it is feasible to implement into a service.

Re:It is not impossible

[Anonymous Coward]

Not for Truecrypt. In CBC mode it bases the initialization vector off of the hash of the file block address so only a single 4k block needs to get uploaded.

Re:This is why zero-knowledge services are better

[operator_error]

https://spideroak.com/engineering_matters#true_privacy

True Privacy

Your SpiderOak data is readable to you alone. Most online storage systems only encrypt your data during transmission, meaning anyone with physical access to the servers your data is stored on (such as the company's staff) could have access to it. Or, even if your data is encrypted during storage, your password (or set of encryption keys) is often stored along with your data, thus making its easily decoded by anyone with local access to those servers.

With SpiderOak, you create your password on your own computer -- not on a web form received by SpiderOak servers. Once created, a strong key derivation function is used to generate encryption keys using that password, and no trace of your original password is ever uploaded to SpiderOak with your stored data.

SpiderOak's encryption is comprehensive -- even with physical access to the storage servers, SpiderOak staff cannot know even the names of your files and folders. On the server side, all that SpiderOak staff can see, are sequentially numbered containers of encrypted data.

This means that you alone have responsibility for remembering your password or 'Password Hint' (which you can create to help you remember) allowing SpiderOak to create a true 'zero-knowledge environment' – keeping your data as safe and secure as it can possibly be.

Re:the love of cloud

[Weezul]

If you use dropbox on truecrypt encrypted containers, then you'll mostly lose dropbox's archival features.

Wuala has an incredibly simply but very clever algorithm for handling data deduplication on the server, along with rudimentary file versioning, while simultaneously handling on encryption on the client.

How you ask? Easy, you encrypt every file using it's own SHA as the AES key, but then you use the new encrypted file's SHA as the DHT index for retrieval. You need both SHA values to access a file of course, but who cares.

There are only three major flaws in Wuala :

- Any final object yields a unique second SHA for the DHT, enabling data deduplication and instantaneous uploads, but also enabling draconian copyright enforcement under the DMCA. Imagine torrentting a movie only for the MPAA to delete it from your private cloud drive!

- It's closed source! wtf?!? Is anyone really stupid enough to trust closed source encryption software these days? How does anyone know they don't secretly copy the original SHA / AES key?

- It's written in Java. Ack, a slow filesystem driver! (Alright, this third comment is pure trolling. I'll admit server side Java isn't that slow anymore, assuming you avoid all that double copy display idiocy.)

I've been considering writing a custom backend for libgit2 that implements this "original SHA as AES key" approach for storing git repositories in some basic DHT. It ain't a direct translation of course. You'd either need to completely forego git compatibility on the local repository by making all object ids into 2*256=512 or 2*512=1024 bit ids. Or, better yet, create some object packing layer places multiple git objects into a single encrypted object, but must provide some git object index for lookups into encrypted packed objects.

Re:the love of cloud

[1u3hr]

News Flash Dropbox will comply not break the law to protect your data.

The news flash was actually: Despite implying that its staff CAN'T decrypt your data, actually they are just TOLD not to.