[jodrellblank]

Because then they can't store only one copy of each duplicate file, skip uploading duplicate files, work with file hashes knowing that the same file will have the same hash, and less pleasantly, they can't do analytics, advertising and recommendations on the types and quantities of stored files.

[bdhe]

That's not true. As is, in a lot of crypto problems, there are powerful workarounds that require a lot of work. See here for one idea: http://news.ycombinator.com/item?id=2461713

Unfortunately, this starts to become a cat-and-mouse game.

[jodrellblank]

I won't pretend I can follow all the implications of that scheme, but it looks like all files are encrypted with an unchangeable hash of the file as the key?

So that all the RIAA has to do is provide a sample mp3 and then DropBox can see who has AES(F, H(F)) stored. Only the files with user generated unknown content can remain mysterious to DropBox, widely used files cannot.

And since you use aes(f, h(f)) you can't change the encryption key on any particular file.

And since the client software needs to use the local DB and since they have the list of files you uploaded, they have most of the plaintext known if they want to try to decrypt the DB maliciously.

But if they do want to, they can leak the password you type in to themselves anyway.

Also, how would this scheme interact with DropBox's differential upload and revision tracking feature?

ZFS does encryption and deduor too, so yes it is possible, but secure trustable ecrypted DropBox where they also do the encryption part?

[bdhe]

So that all the RIAA has to do is provide a sample mp3 and then DropBox can see who has AES(F, H(F)) stored. Only the files with user generated unknown content can remain mysterious to DropBox, widely used files cannot.

No, Dropbox does not know who has what hash. The list of files you have is encrypted by your own key. I realize the scheme is not fixed and there are ideas, since no one exactly published a paper on this.

Also, how would this scheme interact with DropBox's differential upload and revision tracking feature?

Yes, unfortunately there is always a trade-off between security and usability. Things like encrypted volumes are not very friendly and intuitive but provide security. Similarly, lots of neat tricks that Dropbox uses might become void. But at least dedup that was one of their strong features still works.

[jodrellblank]

No, Dropbox does not know who has what hash.

They don't need to - you upload AES(F, H(F)), so if the RIAA give DropBox a sample "Beyonce: Pop Song #7.mp3" file, DropBox can do H(F), then do AES(F, H(F)), then say "do we have this? Yes. Who uploaded it? Accounts adambloggs1, beatricebloggs2, carltonbloggs3, delaneybloggs4".

They couldn't trawl for the RIAA by filename only, or by file hash only, but they could trawl from an example file.

The safe stuff would be your accounts - since there is nobody to provide an example file for them to hash/encrypt. (Except it wouldn't be totally safe since they could weaken the local database encryption or pass themselves the key to it, and you'd never know).

We can agree that they might be able to do it and keep DeDupe, though.

[bdhe]

They don't need to - you upload AES(F, H(F)), so if the RIAA give DropBox a sample "Beyonce: Pop Song #7.mp3" file, DropBox can do H(F), then do AES(F, H(F)), then say "do we have this? Yes. Who uploaded it? Accounts adambloggs1, beatricebloggs2, carltonbloggs3, delaneybloggs4".

I've worked it out and if I'm not incorrect the table that adambloggs1 that has (hash2(file1), hash2(file2), ..., hash2(file10)) which are adambloggs1 10 files can be stored remotely encrypted by the client's key (derived from his password in a secure way that Dropbox cannot). What this means is that whenever the client has to send across hashes to dropbox to sync across files, he gets his encrypted database from dropbox, decrypts it remotely and proceeds to give dropbox relevant hash information.

There are 2 problems definitely that can compromise the system:

1. Dropbox decides to store your requests because of a subpoena (effectively they're logging you---which is not required for functionality). Then the encryption is useless.

2. If dropbox does not log you, then can collude and catch you in the act (i.e., an online attack)

So the solution is ugly, and reasonable, but has some weaknesses. Yet, it is better than nothing.

This system makes sure that RIAA cannot trawl by filename or hash only unless dropbox stores logs or some activity is done online.

[jodrellblank]

I was assuming dropbox would do reference counting so they could delete data that nobody is using, and account tracking so they can put storage limits on your account and charge you for using more space.

But they could make a system which didn't do those things and then they would be able to do as you discuss.

Now the limit to what they could do for the RIAA is identify if they have a file stored and delete it or block it from being stored, but only with an example whole file - not by filename or hash.

So the solution is ugly, and reasonable, but has some weaknesses. Yet, it is better than nothing.

Maybe. It depends what you are guarding against. If you fundamentally do not trust dropbox, then it is no better than nothing. If you do want to keep copied music files then it is pretty much no better than nothing. If you want convenience and features it is worse than nothing. If you want a basic security that stops dropbox easily trawling your most personal files, it is better than nothing.