Deduplication, encryption, security and... Dropbox

[Armando]

Dropbox sacrifices user privacy for cost savings ?

That's what this article is trying to demonstrate.
Interesting read and, while I'm no security expert, it seems to me that the implications go beyond this :

As Ashkan Soltani was able to test in just a few minutes, it is possible to determine if any given file is already stored by one or more Dropbox users, simply by observing the amount of data transferred between your own computer and Dropbox's servers. If the file isn't already stored by Dropbox, the entire file will be uploaded. If Dropbox has the file already, just a few kb of communication will occur.

[f0dder]

On a related note:

Why SpiderOak doesn't de-duplicate data across users (and why it should worry you if we did)

One of the features of SpiderOak is that if you backup the same file twice, on the same computer or different computers within your account, the 2nd copy doesn't take up any additional space. This also applies if you have several versions of a file as it evolves over time -- we only need to save the new data blocks.

Some storage companies take this de-duplication to a second level, and do a similar form of de-duplication across all the data from all their customers. It's a great deal for the company. They can sell the bytes of storage to every user at full price while incurring zero additional cost. In some ways its helpful to the user too -- uploads are certainly faster when you don't have to transfer the data!

...there's more in the blog article the quote is from.

[Armando]

Thanks f0dder. SpiderOak implements it the right way it seems.
I saw that you were already aware of that when I checked that post in that SpiderOak thread.  

[f0dder]

Yup, thought it was worth mentioning here as well

[tomos]

another one = amazon cloud:

Food for thought... No privacy on Amazon's cloud drive.

Less so than other cloud storage?

I'll just throw this out there:
Does it really bother you though ?


[edit] on rereading the article, and thinking about it a bit, you dont have to answer that question ;-) I guess I'm sort of relaxed about it myself, cause the important stuff I have on Dropbox is encrypted (locally) [/edit]

[phitsc]

[edit] on rereading the article, and thinking about it a bit, you dont have to answer that question ;-) I guess I'm sort of relaxed about it myself, cause the important stuff I have on Dropbox is encrypted (locally) [/edit]

Mine is not (locally encrypted). I totally relied on Dropbox's claims of total security (which as it seems might be naive). So yes, it does bother me.

[Armando]

I actually bothers me too, even though I don't have too much sensitive info... Because that's not really the point : what bothers me are the false claims. It's almost impossible that "they" didn't know about the actual storage security/encryption flaws. So they most probably... lied.

I'm going to try to find an alternative, if possible.

[nudone]

How is Dropbox detecting duplicate files - not by name, surely? By some hash? It must be unique - how does it know it's safe to duplicate otherwise.

Which, to me, means I don't quite get the security concerns. If you've got a file that you don't want duplicating because of sensitive content, isn't that going to be a file you've created yourself, therefore with a unique hash. So, it won't be duplicated.

The only things duplicated are common files. Ones that won't have been edited from their original source.

(I use Dropbox so I may just be kidding myself and not seeing the bigger picture.)

[Armando]

If it can hash the files, then it can also read them before it's encrypted or after, by using the encryption key (which they shouldn't have access to in the first place)... So it means that they have access to content. (If you encrypt files before sending, that doesn't apply of course).

[phitsc]

This is what's making me nervous:

Dropbox is likely calculating hashes of users' files before they are transmitted to the company's servers. While it is not clear if the company is using a single encryption key for all of the files users' have stored with the service, or multiple encryption keys, it doesn't really matter (from a privacy and security standpoint), because Dropbox knows the keys. If the company didn't have access to the encryption keys, it wouldn't be able to detect duplicate files.

I see that it's only speculation. But if it is true, then that is a very serious problem.

[phitsc]

To be honest, I assumed that my files were somehow encrypted with my login credentials. Now that I think of it, that wouldn't make sense though. Every time I'd change my password the files would probably have to be re-encrypted.

[Cloq]

More on Dropbox security.

[Armando]

Thanks Cloq. More stuff to consider... 

[wraith808]

I'll just throw this out there:
Does it really bother you though ?


[edit] on rereading the article, and thinking about it a bit, you dont have to answer that question ;-) I guess I'm sort of relaxed about it myself, cause the important stuff I have on Dropbox is encrypted (locally) [/edit]

Encrypted how?  I just saw this comment on that Dropbox Security link...

A warning about using TrueCrypt with dropbox — because of way drop-box works, only syncing the bits of a TC container that have changed, a person may be able to guess your TC secret key by capturing this changed data several times.

I guess I'm not really too upset about it because I don't really have any sensitive stuff to sync.

[f0dder]

I don't see how they can handle cross-user deduplication if they aren't able to decrypt (if encrypted at all!) files at a whim. If you upload a file that's applicable for deduplication, upload is instant.

As for the dedupe not being a problem because only "unique" files are sensitive? Well, what about something like the weaked likipedia cables? I'm also concerned about it at a general honesty level, though. Oh, and the fact that dropbox is generally holed like a sieve

[Stoic Joker]

Just add periodic blocks of completely random machine code to you sensative documents. That way even if somebody does manage to successfully decrypt it, they'll still be left scratching their heads trying to figure out what they missed.


(jk - don't shoot me...)

[Armando]

I'm also concerned about it at a general honesty level, though.

Me too. Really, I don't see why I should trust them more than others.

Private data should be treated as such. And if "they" make it sound like nobody can access it apart from the user, it should be because it's impossible for them to do so. Not because they're nice people and we should trust them not to do so.

[phitsc]

I raised my concerns directly with Dropbox and got the following response:

That article is both misleading and alarmist.

Please read our response to this. Thanks! http://forums.dropbox.com/topic.php?id=36365#post-310198

If you would like client-side encryption you'll need to use something like True Crypt. With server-side encryption it doesn't matter if we use your key our ours. Also, if you expect the files themselves to be encrypted using your actual password as the key then we'd have to re-encrypt all of your files every time you change your password. I don't believe any service offers that feature.

Please let me know if there is anything else I can do for you.

[Armando]

I don't find that their answers explains much... unfortunately.

[phitsc]

I don't find that their answers explains much... unfortunately.

And I don't find it in the least comforting.

[wraith808]

I don't find that their answers explains much... unfortunately.

And I don't find it in the least comforting.

And I found it actually made me more concerned, rather than less.  Because it shows (1) PR backpedaling and (2) a basic lack of awareness about the competition.  I *know* that Jungle Disk does offer encryption (though I don't use it, because it slows down the sync, and I don't really store anything that I care about using the sync service) and I'm pretty sure that others do also.

Encryption (Bucket Password)

Jungle Disk makes it easy to protect your remotely stored data with encryption. Encryption ensures that no one can access your data as it is transmitted over the Internet or stored on remote servers.
Note that regardless of whether you enable encryption using a custom key, your data is always encrypted while transmitted over the Internet by using SSL (like your bank web site). Choosing a custom encryption key means that your files will be encrypted while stored on Amazon's servers as well.
Be careful when enabling encryption. If you forget the encryption key you select you will not be able to retrieve your files in the future. You should write down a copy of your key and keep it in a safe place. If you lose your key neither Jungle Disk nor Amazon can help you retrieve it.
To enable Encryption, select the “Encrypt files using a custom key” option and type an encryption key (password) into the Custom Encryption Key box.
There is also a box where you can enter a list of "Decryption Keys". This is only required if you want to change your custom encryption key from time to time. When you change your encryption key, existing files stored on Amazon.com servers are still encrypted with the original key. In order to be able to access them in the future, you need to keep your previous keys in the decryption keys list. If you want to re-encrypt your files with a new key you will need to re-upload them. If you attempt to download a file that was encrypted with a key that is not on your decryption keys list, Jungle Disk will display an error message.

Here are a few details on how Jungle Disk encrypts your files:
Jungle Disk encrypts files that are stored prior to uploading them using 256-bit AES. AES is an industry (and government) standard and is one of the most well studied and most secure encryption algorithms available. Jungle Disk uses a unique key for each file, and constructs the key using a HMAC that helps protect against certain attacks. Code that demonstrates how data is encrypted/decrypted is available for download on the software download page under the GPL license.

The Jungle Disk Desktop Edition adds a special metadata header to each file when it is uploaded. The header identifies the type of encryption used and contains a salt value and a one-way hash of the salted key. This allows Jungle Disk to determine the correct key to use to decrypt the file. Note that without the decryption keys the header is of no use, and you cannot even tell which files are encrypted with which keys unless you possess the keys.

[phitsc]

And I found it actually made me more concerned, rather than less.  Because it shows (1) PR backpedaling and (2) a basic lack of awareness about the competition.  I *know* that Jungle Disk does offer encryption (though I don't use it, because it slows down the sync, and I don't really store anything that I care about using the sync service) and I'm pretty sure that others do also.

Yep, I agree. Same for SpiderOak (which I'm not personally using (yet)). At least their FAQ about their "zero knowledge" indicates as much.

[f0dder]

For SpiderOak, they can't even intercept your data at server-side before encryption, because it's done client-side... and encryption really shouldn't slow anything down unless you've got an insane-speed internet connection

Also, if you expect the files themselves to be encrypted using your actual password as the key then we'd have to re-encrypt all of your files every time you change your password.

Doesn't really need to be "encrypted using your actual password" - generate a random encryption key, encrypt that encryption key using the password. Lets you change the passphrase without re-encrypting all the content...

After that reply of theirs, and the recent exploits against it, I don't think I'd touch dropbox with a 42 foot pole.

[wraith808]

... and encryption really shouldn't slow anything down unless you've got an insane-speed internet connection

Wouldn't the act of encryption slow things down?  i.e. step 1 encrypt, step 2 upload instead of just step 1 upload?

[phitsc]

I've asked Dropbox support if their FAQ statement that says that "Dropbox employees aren't able to access user files" were really true. Their response:

Yes. Dropbox employees can't access the file's contents. They can see the file names, move, delete or even restore files, but can't view them. The only exceptions are the executive staff who have a vested interest the company.

I have to admit that I am shocked about their slack interpretation of the word "employee". To be honest, I feel cheated by that FAQ statement. Already the fact that any employee could actually delete my files is unbelievable.

Anyone who's already a SpiderOak user wants to send me an invitation? I think they have a referral program.