How secure is the new Mega-site encryption?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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. :)

Answer 4

The 128 AES code is reviewed by users such that the high quality of the implementation can be guaranteed. Main project here but about Mega's cryptography here. Blog about the development here

Code transparency is being provided progressively. SDK code has been available since 2014 and we are now disclosing code for our web client and browser extensions.

Changes 2016 in cryptopp.h

• decodeintarray function
• serializekey function

Changes 2016 in cryptopp.cpp

• AsymmCipher::serializeprivkforjs much cleanup in the asymmetric cipher; static constant very easily to be guessed (0123456789abcdef);
• much cleaning and more readable codes (variable names, structure etc)

sdk/tests/paycrypt_test.cpp

• fixed length BASE64_IV, BASE65_ENCKEY, BASE64_HMACKEY, KEYS
• main test PayCrypter:hybridEncrypt

Tests

Only a single main test which only one contributor in the encryption. Code sdk/tests/paycrypt_test.cpp. Main test PayCrypter:hybridEncrypt

//Test PayCrypter:hybridEncrypt()
string finalResult;
string contentString = CONTENT;
ASSERT_TRUE(payCrypter.hybridEncrypt(&contentString, pubkdata, pubkdatalen, &finalResult, false));

which seems to be using asymmetric key scheme i.e. it may be inefficient with very long messages. Main risk (Wikipedia) is apparently in the key encapsulation and its security definition where the data encapsulation must be slightly stronger. This fact seems to be the case in the code by comparing the initialization of the keys.