6 ms·

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

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.

gjulianm 14y ago
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.
- jiggy2011 14y ago
  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.
  - beala 14y ago
    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_day http://en.wikipedia.org/wiki/Known-plaintext_attack#Present_...
    - jiggy2011 14y ago
      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.
      - beala 14y ago
        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.
- g_lined 14y ago
  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.
deleted 14y ago
[deleted]
politician 14y ago
In that case wouldn't decrypt(encrypt(F, K1), K2) produce garbage?

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.

gjulianm 14y ago

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.

jiggy2011 14y ago
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.
- beala 14y ago
  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_day http://en.wikipedia.org/wiki/Known-plaintext_attack#Present_...
  - jiggy2011 14y ago
    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.
    - beala 14y ago
      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.
g_lined 14y ago
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.

deleted 14y ago

[deleted]

politician 14y ago

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