3 ms·
Wouldn't this allow MEGA to also get a copy of the key so they can decrypt your data?
by cryptox 14y ago
Wouldn't this allow MEGA to also get a copy of the key so they can decrypt your data?
- cynicalkane 14y agoMega would be storing copies of the key that can only be decrypted with a password.
- A1kmm 14y agoBut 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.
- jiggy2011 14y agoOnly if they had a copy of the original plaintext file.
- gjulianm 14y agoWhich in theory they don't have, as they encrypt it on your browser.
- Sami_Lehtinen 14y agoWell, 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.
- Sami_Lehtinen 14y agoWell, 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 https://en.wikipedia.org/wiki/OFFSystem These are more or less "funny" work-a-rounds to the actual problem.