14

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?

3
  • 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) Jan 21, 2013 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. Jan 21, 2013 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, 2013 at 20:33

4 Answers 4

11

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.

6
  • Their MACing is dubious in many ways. I think using a MAC in the first place was a bad idea. Jan 21, 2013 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. Jan 21, 2013 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. Jan 21, 2013 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, 2013 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". Jan 23, 2013 at 22:03
1

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
2
  • 4
    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, 2013 at 20:37
  • 1
    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/… Jan 29, 2013 at 13:13
0

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

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .