Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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

2 Answers 2

up vote 0 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

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
1  
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
1  
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

 
discard

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.