|
|
|
|
|
by bdhe
5507 days ago
|
|
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. |
|
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.