Megabad: A quick look at the state of Mega’s encryption

> [...] the implication is that a uniquely identifiable thing can be derived from any given piece of data. This returns some burden to Mega—rather than throw up its hands and say that it has no idea what Mega users Alice or Bob have in their Mega accounts, there apparently is a way of telling whether or not Bob and Alice have the same file or files. If the MPAA gets wind that Bob is hosting a copy of The Hobbit: An Unexpectedly Long Movie in his Mega folder, and Alice also happens to have the same file in her Mega folder, it's trivial to prove that Alice has the same file—in fact, the nature of deduplication means there's some record of every deduplicated block, and therefore every other infringing user.

This actually doesn't follow at all. What files a given user has in their account doesn't have to be known to the server, though it's generally not difficult to correlate gets/puts/deletes to accounts. If the hierarchy is handled on the client side and encrypted like everything else, then all the server knows is: we store blobs identified by keys, and when those keys are overlapping, we don't need to store a second copy.

This does make keeping track of storage usage impossible.

The first part of the article is of unusually low quality for Ars Technica. It seems like the author is trying to bash Mega for being reportedly lazy in their implementation. This really is a shame because the parts regarding entropy, deduplication, and the conclusion, are very relevant!

> Files and folders, therefore, are encrypted with symmetric encryption. Symmetric encryption means the same key is used to encrypt and decrypt your data; this is less secure than asymmetric encryption (where one key encrypts and a different key decrypts), but it's faster and easier to implement.

Asymmetric encryption is not appropriate for encryption of large amounts of data (or would require incredibly large keys to work). Symmetric encryption is always used to encrypt large chunks of data, and asymmetric encryption can be used to encrypt a symmetric key. The article seems to hint that Mega was lazy in its implementation, that's not really true.

> For the data stored in Mega, the encryption key used is generated for you at the time of sign-up and is itself hashed—or scrambled—using your account's password.

The key can't be hashed, or it couldn't be recovered. A hash is meant to be un-reversible. Unless the article means that the key itself is a derivation (a hash?) of the password. This would indeed be a major issue! If the key is encrypted using the password (hopefully after running it trough a PBKDF), it is fine.

The absence of a password change option is indeed worrying, but the absence of a password recovery option is reassuring. If you lose your password, then you lose the ability to decrypt your key. If you lose your ability to decrypt your key, you lose your data.

It indeed is problematic that you can't back up the key though!

They advertise themselves as "THE PRIVACY COMPANY". Any problems with that image should be exposed and shamed.

That's not how it works, though. Rough steps for how a system like this can work (bearing in mind that Mega might be doing it entirely differently):

1) Alice takes file P and hashes it to produce key K

2) Alice encrypts file P with key K to produce file C

3) Alice encrypts key K with key U (her user key) to produce key X

4) Alice sends key X and file C to Mega for storage

When Bob does the same steps on a matching file, the only things that differ are key U and key X -- these are his user key, and his user key for the data. That means that Mega can deduplicate file C freely, because they're identical.

Note that Mega never knows the hash of the original file -- key K -- or it'd be able to decrypt the files.

Rather than "megabad", Mega's crypto scheme actually seems pretty reasonable given their desire to do it all in-browser.