[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.

[bdhe]

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.

Definitely. There are a few problems that can "de-anonymize" users. I don't claim that the outline presented would be very robust.

Maybe. It depends what you are guarding against.

I agree, that requires more qualification. I think in the context of subpoenas or trawling, there are some definite advantages.