Hacker News Reader

Comment by dexter313 | Hacker News Reader

The user's javascript that encrypted the file can also make a hash send it to mega, and then they check if they already have that.

EDIT: They never get to see your key or what is in the file.

View on HN

Ok, so I try to upload a.exe to Mega. They make a hash, detect someone has already uploaded it. They don't upload my file, and instead they place a link in my account to that "a.exe" of some other user. How can I access it then? Because it's encrypted with a key which is not mine.

The hashing is done by the client before upload. So if all clients use the same hash algo they will generate the same hash for the same file. So it is encrypted with a key that you know because you have the original file.

Deriving the key from the plaintext + the ciphertext is called a known-plaintext attack [1]. AES isn't vulnerable to this.

[1] http://en.wikipedia.org/wiki/Known-plaintext_attack#Present_...

It is if you know that the key is derived directly and deterministically from the plaintext itself.

Of course this will only give you the key to that one particular file, not any other files that you do not have yourself.

Ah I see this was in reference to your convergent encryption post above. Point taken.

Assuming that it works this way, it would allow Mega to figure out if you own a known "bad" file. Just take something like "New_Jay-Z_Album.zip," hash it, and try the hash against your encrypted files. It seems like Kim is trying to avoid this problem.

Note that they are likely to use something like 4MB chunks of the file rather than whole files. This prevents things like metadata/name differences creating a different hash for the whole file.

In that case wouldn't decrypt(encrypt(F, K1), K2) produce garbage?

Reply on news.ycombinator.com