RIAA Wants To Start Peeking Into Files You Store In The Cloud
techdirt.com
techdirt.com
If you're uploading anything remotely important to a third-party service, you should encrypt all of it beforehand. As we see time and time again, it can be really surprising how easy it is for an insider, a random script kiddie, or in this case, a company with a posse of anxious lawyers to grab your data. You need to encrypt that data before it ever leaves your disk for persistent storage on someone else's infrastructure. Encrypt encrypt encrypt.
The main benefit of encryption in these situations is that you have to trust your provider a whole lot less... If I get compromised through a OS hole? if you are encrypted, you are covered. If I get compromised through a physical attack, governmental or otherwise? if you are encrypted, you are covered.
If I do the encryption for you, I give away a bunch of those benefits. If I'm completely compromised, you should assume that any keys I have access to are also compromised.
I think giving up "deduplication" is completely reasonable in this regard; the competitive landscape right now is that "cloud backup" costs about 10x what I think it ought to cost for backups (In part due to the fact that many 'cloud backup' services are built to be fast enough to serve webpages; If you let me have 'backup system' level performance, I can do it a whole lot cheaper, but also in part due to the fact that s3 sets the price here, and S3 is still charging "pretty good for 2007" prices.)
A really cool application would be one that allowed you to contact your home computer from the web and use that to decrypt stuff transparently on its way to your final destination, then you could still offer web-accessible decrypted files any time the user's main computer was powered on.
yeah. That's also what I am suggesting. but you don't need the provider's help to do that. it's easy enough to encrypt a davfs mount locally on your own box; the provider just needs to support some standard (like webdav.) Then it's up to the user to figure out what client they trust to encrypt the data before it's uploaded.
My point is that if the providers control the encryption (e.g. by providing a proprietary client that has access to the key) you have a lot less protection than if you do the encryption independent of your provider.
They save a lot of costs by deduplicating copies of files, and it makes file renames/moves/shares really easy for them. Therefore, they wouldn't have the incentive to destroy that advantage: That's one of the major scale advantages they get for covering so many users.
With that said, they could offer that "by default" to premium users who already pay for the service to simplify their lives and keep their more profitable customers happy.
What are everyone's views on that, from Dropbox's perspective?
I posted this elsewhere in the thread: 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
Please also see the further discussions. Crypto gives us powerful tools to mitigate several attacks with minimal compromise on functionality. Unfortunately there are legal ways that are more powerful.
I demand the right to start looking at everyone's cloud files too.
Because, y'know, human rights and the rule of law are far less important than preserving the music industry's business model for a few more years.
Unfortunately, this starts to become a cat-and-mouse game.
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?
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.
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.
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.
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.
As for Dropbox, they need to be able to read the files to serve it to you from their website.
I hereby promise they positively do contain copyrighted materials indeed, and I thus encourage your troops to spend considerable time trying to decipher whatever it is that I've stored in these clouds of the 2010's internet.