MEGA's First Week - A Retrospective - Future Is Open Source

January 26th 2013

It's been seven busy days for us since MEGA went live. As millions of users were hitting 50,000 freshly written and barely tested lines of code and dozens of newly installed servers, teething troubles were inevitable - it took us almost 72 hours to resolve the major bottlenecks, and we would like to apologize to all users who were affected.

As expected, the public debate about MEGA revolves primarily around our cryptographic security model and can be classified into five categories:

• Actual bugs. Two (an XSS hole and the invalid use of CBC-MAC as a secure hash) were reported by the community so far and fixed swiftly. To all the bright minds going through our amorphous code: Thank you for your efforts! We will make our JavaScript more readable and launch a bug bounty program shortly.
•  
• Design flaws exacerbating the potential impact of weak user passwords. We acknowledge that our current approach is based on the assumption that all of our users choose strong passwords, which is probably a bit naive. We are going to improve the sign-up interface (better user education and rejection of overly weak passwords). We'll also reduce the offline password cracking risk for users who do use weak passwords and fall victim to someone intercepting their e-mail or obtaining their user record from our central database.
•  
• Weak random number generation: We have added WebKit's crypto.getRandomValues() into the mix and will collect mouse/keyboard timing entropy explicitly before generating the RSA key pair rather than informing the user that we are doing so only after the generation has already started.
•  
• Deduplication - clause 8 of our Terms of Service has caused some confusion and concern. The reality is quite harmless: We deduplicate based on the full encrypted file. That's it.
•  
• Polemic in the "if you can break SSL, you can break MEGA" category. No comment.

Source: https://mega.co.nz/#blog_4

Mega Winner: The cloud storage market is dominated by players that do not take advantage of cryptography beyond HTTPS and server-side encryption.

A word on cryptography

January 22nd 2013The cloud storage market is dominated by players that do not take advantage of cryptography beyond HTTPS and server-side encryption. Since we set out to improve this rather dissatisfying situation three days ago, some news outlets have made attempts to dismantle our crypto architecture. Frankly, we were not too impressed with the results and would like to address the points that were raised:
ars technica: "Megabad: A quick look at the state of Mega's encryption"

"The key used to encrypt your Mega files and folders is stored on Mega's servers, rather than on your local computer."

This is correct - the only key that MEGA requires to be stored on the user side is the login password, in the user's brain. This password unlocks the master key, which in turn unlocks the file/folder/share/private keys.

"It is telling that there appears to be no password recovery mechanism anywhere in the Mega or log-on screens, nor any method of changing your password in the user control panel." Because the master AES-128 key is encrypted using your password, remembering the password is vital. Losing it means you don't just lose the ability to log on to the service - you lose the ability to decrypt your files, period.

This is correct (and comes as no surprise) - however, this will change in the near future:

• A password change feature will re-encrypt the master key with your new password and update it on our servers
• A password reset mechanism will allow you to log back into your account, with all files being unreadable. Now, if you have any pre-exported file keys, you can import them to regain access to those files. On top of that, you could ask your share peers to send you the share-specific keys, but that's it - the remainder of your data appears as binary garbage until you remember your password.

"Without adding entropy, the "random" primes generated by math.random for use as RSA keys are really only pseudo-random and can be guessed."
This is correct - and quite a strange statement to make after conceding that mouse and keyboard entropy are indeed used to enhance Math.random(). We will, however, add a feature that allows the user to add as much entropy manually as he sees fit before proceeding to the key generation.

[On deduplication] "Whatever the underlying method, the fact that block deduplication exists is a blow against the "see no evil" approach taken by Mega."

Fact #1: Once this feature is activated, chunk MACs will indeed be stored on the server side, but they will of course be encrypted (and we will not use ECB!). Fact #2: MEGA indeed uses deduplication, but it does so based on the entire file post-encryption rather than on blocks pre-encryption. If the same file is uploaded twice, encrypted with the same random 128-bit key, only one copy is stored on the server. Or, if (and this is much more likely!) a file is copied between folders or user accounts through the file manager or the API, all copies point to the same physical file.

Forbes: Researchers Warn: Mega's New Encrypted Cloud Doesn't Keep Its Megasecurity Promises
"So Mega, or anyone else who gains control of the Mega server sending the crypto algorithms, can turn off that encryption or steal the user's private key, which would allow decryption of all past and future uploads."

Correct. Fact #1: Our FAQ states exactly that and warns people that do not trust us to refrain from logging into the site (but they could, in theory, still safely use MEGA through client apps from vendors they trust). Fact #2: Any software maker offering online application updates is able to plant Trojan code into specific targets' computers, with much more far-reaching consequences.

"If you can break SSL, you can break MEGA."

Yes. But if you can break SSL, you can break a lot of things that are even more interesting than MEGA.

"To make matters worse, Mega's SSL server seems to use weak 1024-bit encryption, rather than the 2048-bit encryption considered the minimum standard by many cryptographers for a decade. (This 2004 study, for instance, that declared 1024-bit keys would only be secure until 2006.)"

Fact #1: https://mega.co.nz/ uses 2048-bit encryption. Fact #2: https://*.static.co.nz/ uses 1024-bit encryption. Fact #3: All active content loaded from these "insecure" static servers is integrity-checked by JavaScript code loaded from the "secure" static server, rendering manipulation of the static content or man-in-the-middle attacks ineffective. The only reason why HTTPS is supported/used at all is that most browsers don't like making HTTP connections from HTTPS pages. And, using more than 1024 bit would just waste a lot of extra CPU time on those static servers. Fact #4: This has been covered in our FAQ from the beginning.

John Hopkins cryptographer professor Matthew Green says that Mega's claims of a Javascript verification system "make no sense." ... "If the Javascript is verifying itself, it's like trying to pick yourself up by our bootstraps, which doesn't work," says Green. "You need something trusted on the user's machine to check the Javascript, and they don't have that."

Please do not rely on hearsay, even if you are a cryptographer professor. Instead, go to the actual site and look at the actual code. Fact #1: The JavaScript is not verifying itself. Fact #2: A piece of JavaScript coming from a trusted, 2048-bit HTTPS server is verifying additional pieces of JavaScript coming from untrusted, HTTP/1024-bit HTTPS servers. This basically enables us to host the extremely integrity-sensitive static content on a large number of geographically diverse servers without worrying about security.
MegaCracker An excellent reminder not to use guessable/dictionary passwords, specifically not if your password also serves as the master encryption key to all files that you store on MEGA.

Source: https://mega.co.nz/#blog_3