Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

The new Mega site, sucessor of Megaupload, claims that all information is encrypted with a symetric key that only the user has access.

The general terms are listed here:

All files stored on MEGA are encrypted. All data transfers from and to MEGA are encrypted. And while most cloud storage providers can and do claim the same, MEGA is different – unlike the industry norm where the cloud storage provider holds the decryption key, with MEGA, you control the encryption, you hold the keys, and you decide who you grant or deny access to your files, without requiring any risky software installs. It’s all happening in your web browser!

In the developers page there are some details about AES 128bits, 64 random bits as some initial value, and so on, but I can't find details on how the end-user will have that protection.

Does someone how their encryption / security really works? Is it really secure?

share|improve this question
2  
I certainly heard bad things about their implementation. From XSS, over bad entropy PRNGs to the fundamental problem of javascript crypto(you typically don't notice if the server sends evil code, perhaps only for you) –  CodesInChaos Jan 21 '13 at 15:39
1  
I don't like their use of MACs. This means that anybody who can read a file, can generate valid MACs. That seems dubious to me. I'd rather use a hashtree and sign the root. –  CodesInChaos Jan 21 '13 at 15:48
1  
I don't know if it's secure, but for the life of I can't get it to work at all. Sometimes the environment won't load, sometimes it will load but I won't be able to do anything and everything in between. It's a crapshoot. –  Null Jan 28 '13 at 20:33

3 Answers 3

up vote 6 down vote accepted

The details are relatively scarce, but section 5 of ht developers' page you link to describes the kind of encryption they apply. Bottom-line: they don't say it explicitly, but it is basically CCM mode, albeit with some simplifications in IV management. They don't talk about padding and length encoding, and this might be an issue.

Also, the file is split into chunks, each chunk having its own MAC, so that you may "process" chunks individually. However, it seems that there is no sequence number in the MAC thing; as far as the text says, the IV for the MAC of the second chunk is the CBC-MAC of the first chunk, which is bad because it could be altered by a malicious individual. In practice, this means that the per-chunk MAC is useful only if you stream the data from the beginning, in due order; random access would be susceptible to attacks.

The main concept of using a per-file key is sound, but it requires some careful handling of the keys and there is not enough detail on the page to decide whether things were done properly or not. The whole thing reeks of a homemade construction and it is known that homemade constructions are fertile ground for vulnerabilities.

share|improve this answer
    
Their MACing is dubious in many ways. I think using a MAC in the first place was a bad idea. –  CodesInChaos Jan 21 '13 at 16:17
3  
Using an authenticated encryption mode is a good idea; and that's what they do: it is CCM. But they modified it a bit, which is enough to raise warning flags. –  Thomas Pornin Jan 21 '13 at 16:18
    
I think MACs(or authenticated modes like CCM) don't fit the situation in the first place. Since they only have a single to sign and verify since it allows anybody who can read the file to fake MACs. It's also non trivial to create chunked MACs (they didn't do so well in that department, as you already noted). TahoeLAFS uses a signed tree hash for this, which is far superior IMO. That way you can have separate read&write keys, and no mixing attacks are possible. –  CodesInChaos Jan 21 '13 at 16:24
    
@ThomasPornin What do you consider "careful handling of the keys" as stated in your 3rd paragraph? How do you properly handle the keys? For example, if there is a database table with fileID and fileKey columns, and we encrypt the symmetric key prior to saving into fileKey. We encrypt/decrypt it by sending the row for processing over API (SOA) to a CryptoBox (poor man's HSM), which contains the master cryptographic key. Encryption/decryption happens there. Is this considered secure? Should we also use HMAC on fileKey? –  Matrix Jan 23 '13 at 21:49
    
@Matrix: key management is a very large subject... Here, the per-file keys must be generated with a strong enough PRNG, and stored in a master key file (which is password-encrypted), with all due MAC to prevent an attacker from altering a key, or swapping keys around. This has ramifications in how they make the link between files and keys, and that does not seem to be completely specified. The currently published Web pages give some idea about what they do, but are nowhere near anything which I would call "a decent specification". –  Thomas Pornin Jan 23 '13 at 22:03

it looks like there is press today outlining security flaws with the security approach taken by Mega, see this article that makes comment on the research by Alan Woodward.

Summary of the main flaws:

  1. key length for the SSL key
  2. Trust in the Mega admins that keys couldn't be captured by a server change in the javascript
  3. predictable random number generation
  4. lost password = lost data
share|improve this answer
2  
I don't agree with lost password = lost data. That's just the nature of the beast, you can't avoid this when using encryption. –  Null Jan 28 '13 at 20:37
    
Mega themselves recognise the "lost passwd = lost data" issue and are coming up with a system to allow users to recover data using a key export feature. Check out: gizmodo.com/5978164/… –  Callum Wilson Jan 29 '13 at 13:13

Encryption alone will not secure your information no matter what MEGA or anyone else says. I would imagine MEGA is using the same encryption as everyone else. Likely Full Disk Encryption (FDE / AES) for data at rest in the MEGA cloud combined with Internet Protocol Security (IPsec) that secures the communication between the PC / MEGA cloud storage. Both forms of encryption utilize 128bit or 256bit keys.

The sad news is 128bit or 256bit encryption have both been hacked. In fact, recently some Israel hackers broke the GSM 128bit key in 2 hours. So brute force hacking is one challenge (that's running sequential numbers until you get a match) or by breaking into the key store located in the destination box. FDE works by using a key-store that is embedded in memory. Break into the memory you get the key used for unlocking. So there are a couple ways good hackers can break encryption. The good news is most encrypted data keeps out about 90% of the population. However, it's the 10% that you have to worry about. :)

share|improve this answer

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.