This? http://crypto.stackexchange.com/questions/729/is-convergent-... http://www.ssrc.ucsc.edu/Papers/storer-storagess08.pdf

It seems really interesting, so they can check for duplicates while keeping files secure. Thanks!

From that StackExchange link, the top-ranked answer has the following comment:

"However, one more attack: an attacker can guess plaintexts and test if you have that file."

If that's the case, pirates beware.

Yes, there's exactly the same problem as with Freenet. Because same plaintext encrypts to same ciphertext there is huge problem with that. If I really don't anyone want to know that I got this data, that's failed scenario. It makes things easier for service provider, they don't want to know what they're storing. Just like Freenet's data cache. But if I know what I'm looking for, I can confirm if my cache contains that data or not. Therefore this approach doesn't remove need for pre-encrypting sensitive data. Otherwise it's easy to bust you for having the data.

Edit: GNUet quote:"The gnunet encryption scheme is remarkable in that it allows identical files encrypted under different keys to yield the same ciphertext, modulo a small block of metadata. These files can then be split into small blocks and distributed (and replicated if need be) across hosts in a gnunet system to balance load."

http://grothoff.org/christian/esed.pdf Efficient Sharing of Encrypted Data - Krista Bennett, Christian Grothoff, Tzvetan Horozov, Ioana Patrascu

This means that if there's a commonly available plaintext version of a file, then you can encrypt it, compute the hash of the encrypted version and then serve it to Mega along with a DMCA takedown notice.

They wouldn't really want that, would they? So as clever as it is, I doubt they do it this way.

>then serve it to Mega along with a DMCA takedown notice.

The thing with copyrighted content, though, is that even if the file you're checking might be infringing on copyrights in certain cases, in other cases it might as well be completely legit. I wrote about this on some earlier MU submission[1], so I won't repeat all that here, but all in all, even if you knew that file X existed on Mega's servers, it would be pretty damn haphazard to just outright delete it, because you might be hurting many legitimate users by doing so.

Anyway, I think Mega could secure user's files simply by encrypting the locator keys they have with the user's own key, and this data only gets decrypted and parsed client-side when the user uses Mega with the user's own key. This way you could only prove that a file exists on Mega's servers, but had no way to check which user(s) it belongs to without cracking the individual user data one by one. And of course, if you don't have any exact files to check against Mega, then you wouldn't be able to even figure out whether "content X" is hosted there somewhere, and neither could Mega (since they'd naturally only store locator hashes and encrypted data itself).

[1] http://news.ycombinator.com/item?id=4824986

There'll be plenty of cases when the content is inherently infringing. Cam copies, for example. Additionally, if there's a jurisdiction where a DVD rip of Dora The Explorer is not considered a fair use, they may start pounding Mega to limit this jurisdiction's access to the file. This sort of thing.

>There'll be plenty of cases when the content is inherently infringing.

True, and it seems that Mega's copyright infringement reporting page[1] has an option for that:

Takedown Type: Remove all underlying file(s) of the supplied URL(s) - there is no user who is permitted to store this under any circumstance worldwide

[1] https://mega.co.nz/#copyrightnotice

Oh, nice. This is so tongue-in-cheek. There's no way of knowing the state of any permission worldwide.

Wouldn't this allow MEGA to also get a copy of the key so they can decrypt your data?

Mega would be storing copies of the key that can only be decrypted with a password.

But when someone uploads the same file with a different password, if they want to de-duplicate on content alone, they need to be able to put that new encrypted file hash alongside the original.

One solution to that would be to have two hashes of the file, and to use one as the key and one as the index.

Only if they had a copy of the original plaintext file.

Well, they could have. Unless you're generating original content. This is the problem if you are sharing nothing something which is not 100% original on block level.

This is just the reason, why sensitive data needs to be encrypted before deduplication.

OFF System is also one interesting approach to this problem: https://en.wikipedia.org/wiki/OFFSystem

These are more or less "funny" work-a-rounds to the actual problem.

Which in theory they don't have, as they encrypt it on your browser.

Well, you said "encrypt", what do you mean by encrypt? What's the key? In the Freenet's solution, they encryption key for the data is the data, not any random or user provided key. So the same plaintext is always turned in to same ciphertext. Which we all know, it's very bad idea, it ruins encryption. In this case, it's quite easy to spot out all of the users having the same content in their account.

This is only reasonable method when ever you can assume that every plaintext is unique, which also makes point of deduplicationg data absolutely pointess.

Convergent encryption sounds great. But if Mega is using this, do they have any way of finding out which users have a specific file?

Example: Alice and Bob both upload the same file to Mega. Alice is raided by the MAFIAA. They get a court order telling Mega to list all users having a copy of that file. Can Mega comply? Or does not even Mega know that Bob has the same file too?

Related question: Is there any way for Bob to share his uploaded file with friends?