Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I understand how Mega's encryption works. For a quick summary of all those in the future looking for an answer on this... here is how it works:

Upon first signing up for an account you make a username and password. It also generates a symmetric key which is used to encrypt your files and a RSA key pair to share secrets securely when files are sent to other peoples "inboxes". Once the client has both these, the symmetric key is encrypted with your password and uploaded to the server. This way only someone with your password can decrypt your symmetrical key and then decrypt your files. I'll leave it at this for now as thats all that is relevant to my question.

If my symmetric key is encrypted with my password, no matter how secure my key is would it not still be as weak as the hashing function they use to store my password on their server? This ties into my second question, do they even store a hash of my password? I'm thinking along the lines of no, as it would weaken the encryption hugely, but Mega still needs to be able to determine if your login details are correct. How can they do this without compromising their encryption?

This may be the wrong place for asking this, so please move it if appropriate.

share|improve this question
up vote 2 down vote accepted

I don't know what Mega is doing. They haven't published a design document that describes how their system addresses these threats. That's irresponsible on their part, and it doesn't invite trust. Cryptographers have already criticized Mega for sloppy engineering, and researchers have found a bunch of security problems, vulnerabilities, and design issues. Consequently, I wouldn't use Mega for anything super-sensitive at this point in time.

While I don't know for certain what they are doing, my guess/hope is that they are using a slow hash function or slow KDF to derive a key from your password. In other words, they might derive the key $K$ from your password $P$, via $K=H(P)$, where $H$ is some hash algorithm that is fairly slow -- it might take 1 millisecond to compute, for example. Then, Mega might encrypt your data using this derived key $K$. Or, they might encrypt a session key using $K$ and encrypt your data under the session key, and store the encrypted data and encrypted session key.

Assuming this is what they do, the result is: brute-force attacks on your password remain possible.

For example, if the slow hash takes 1 millisecond to hash your password, then brute-force attacks will need to spend about 1 millisecond per guess at your password. (Probably less, because the attacker may be using a faster computer or a better-optimized implementation of the hash.) Thus, use of a slow hash increases the cost of brute-force attacks but does not eliminate the threat entirely. If your password is long enough and strong enough, brute-force attacks might be impossible. But for many people who choose mediocre passwords or passwords, brute-force attacks will likely still be a serious threat.

For a bit more detail, see this advice: Try to avoid using passwords as encryption keys.

share|improve this answer
Be reasonable. Nobody is asking anyone to reverse-engineer anything. If participants in this forum (especially new ones) can't ask questions such as: "How can they (mega) do this without compromising their encryption?" without being told to go away and ask someone else, then what is the point of the forum? – hunter Apr 5 '13 at 2:31
@hunter, OK, I revised my answer in response to your suggestion. Thanks for the helpful comments! Keep 'em coming! – D.W. Apr 5 '13 at 4:28
@D.W. Although I appreciate the work done to find all the links, the information posted is obsolete and actually wrong. MEGA has a public repository - - feel free to check the code and report any issues you find (they also have a bounty for any security threats reported) – tagyro Apr 1 '15 at 9:20
@tagyro, thank you for the pointer. Unfortunately, a source code repository is not a substitute for a design document that describes how the architecture addresses these threats. (That said, from xemacs' answer, it sounds like they did exactly what I speculated in my answer.) I think the links to vulnerabilities in early versions of the system are relevant to understanding the history of the system. If there are public documents that respond to that analysis and explain why they're wrong or how they've been fixed, with technical details, I'd gladly update my answer with that information. – D.W. Apr 1 '15 at 16:59

Here are some hints on how it's done on Mega:

The password provided is passed through a KDF to derive a key, that is used to en-/decrypt the master key (later provided by the server through an API call).

To bring it down to the crucial bits: The KDF applies $2^{16}$ rounds of AES-128 with it. The details can be found in the function prepare_key() of the web client in file crypto.js.

The user supplied password itself is never sent over the wire. And the master key is only decrypted client side using this password-derived 128 bit AES key.

To log in against the Mega servers, which gives one a valid session that allows one to access the (encrypted) master key, a token is computed. This token is computed using the derived key (see above) by running it through an additional series of $2^{14}$ rounds of AES-128 (see the stringhash function in crypto.js) after "joining" the user's email address with the above mentioned derived key.

D.W. is right, that the procedures in place are unfortunately not properly documented, yet. This is a severe shortcoming that needs to be rectified over time. Having said that, newer cryptographic work by Mega is paired with documentation in the form of a white paper as it is implemented to allow for peer review. These white papers are currently not openly published, yet, but interested parties have received these easily as needed or as requested, as they're still somewhat in flux.

If anybody is interested in further information, please feel free to email for this to get first hand answers. However, that should still hold nobody back from discussing here or elsewhere, though it seems not easy to get explicit answers from the Mega developers here without letting them know of a question raised here.


There's an independent study that has been conducted by a researcher team in Spain: English PDF. They have dug into the available JavaScript code and reasoned on it. Except for minor flaws, the information is pretty much correct.

share|improve this answer
That's interesting. Do you work on Mega? If not, where do you get your information from? – Gilles Mar 31 '15 at 9:41
I do ... :) but the JS code can be looked at, too. – xemacs Mar 31 '15 at 9:57
Thanks for the answer @xemacs I appreciate it, even after all these years! – jduncanator Apr 1 '15 at 11:36
You're welcome. Yes ... I've only just stumbled upon this in the last week. And as I said, if a question should arise, the email address above should help to point the guys with the right kind of background knowledge to give solid answers. – xemacs Apr 1 '15 at 20:55

Here's a possible scenario:

1) Your password is put through a slow KDF such as Scrypt. The output of Scrypt can be configured to take a long time to calculate, and as such, can mitigate the risk of brute-forcing passwords. See here.

2) The output length of Scrypt is also configurable. So assume that half of the output becomes the encryption key for your symmetric key, and the other half is stored to identify you when you log-in.

share|improve this answer
I'm assuming that the symmetric key being encrypted is a string of 16 or 32 pseudo-random bytes, so there's no way for an attacker to verify that they've decrypted the key successfully without actually attempting to decrypt your data with it In my opinion is wrong. Lets say they use MD5 as a hasing algo (I know, its not secure but meh). All I would need to do is bruteforce that MD5 and I would have the password used to encrypt my symmetric key. – jduncanator Apr 4 '13 at 3:21
Also, what do you mean by the password-hash and the symmetric password hash? Are they not the same thing? – jduncanator Apr 4 '13 at 3:23
@jduncanator "All I would need to do is bruteforce that MD5 and I would have the password used to encrypt my symmetric key". But how would the attacker know when the brute-force attack has been successful if they don't know what they're looking for? Regardless, if they're using MD5 as their hash algorithm, then they're not taking security seriously. Assuming they use an industry standard like SHA512 and a proper salt, then brute-forcing isn't viable (most people think sha256 is sufficient, and sha512 is overkill). – hunter Apr 4 '13 at 3:39
Regarding "the password-hash and the symmetric password hash - Are they not the same thing?", assuming they are salted with unique values (as demonstrated above), then no, the resulting hash values are very different. – hunter Apr 4 '13 at 3:42
Actually, bruteforcing an (even salted) SHA-256 hash of a password is quite possible. It takes a bit longer than MD5 (on the same hardware) proportionally to the hashing taking longer, but not exponentially longer – just hash each possible (probable) password once and compare the results. You need a slow hash to prevent this. – Paŭlo Ebermann Apr 4 '13 at 19:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.