What is MEGA doing? - a commentary on their insecure cryptography

What is MEGA doing? - a commentary on their insecure cryptography
Photo by iMattSmart / Unsplash

What comes to mind when you hear the words, "secure cloud storage"? If you're a privacy enthusiast, like me, maybe you think of MEGA. MEGA has branded itself as the "privacy company" by emphasizing their end-to-end encrypted web services, comprising of cloud storage, contacts and chat, "By properly applying end-to-end encryption, MEGA achieves actual privacy by design."

As a web developer who has created numerous privacy projects involving end-to-end encryption, I have respect for other projects, like MEGA, that focus on preserving user privacy and giving users control of their data. I also have pretty decent knowledge on how encryption should be implemented to maximize data security. As a result, after analyzing MEGA's own security architecture whitepaper, I was baffled by the developers' incompetencies when it comes to their cryptography implementations.

I originally did a small write-up on r/privacy, but decided to expand on my points and perform a more in-depth analysis on my blog, which is the article you're reading right now.



I have taken note of four categories of issues that I found in my analysis. My analysis was solely on the cryptography security aspect of the whitepaper, such as encryption keys, data encryption and key exchange.


  • MEGA's whitepaper was last updated in June 2022, so this analysis only applies to the version published at the time of writing.
  • Whitepapers are only valid if the company publishing them is transparent. This analysis assumes that MEGA has been fully transparent in their cryptography implementations through their public whitepaper.

Category 1: Lack of Integrity Verification

Integrity verification, also called "authenticated encryption", in the context of encryption means verifying that the encrypted data received is indeed authentic and not tampered with. While encrypted data cannot be directly read by unintended third-parties without the correct decryption key(s), it can be manipulated in certain ways or used in replay attacks, unless encrypted with authenticated modes (such as AES GCM and CCM) or HMACs.

Here's how authenticated encryption could look like when using an unauthenticated encryption mode, like AES-CBC.

  1. Alice wants to send a message to Bob securely.
  2. Alice encrypts her message into "ZGVleiBudXRz" using the secret password, "1234".
  3. Alice creates an EtM HMAC with both the encrypted ciphertext and the password ("ZGVleiBudXRz,1234" -> "81a711b3b56f27afc0bea1b0ffc2932f066478382bfee81ab539037436dbd1cd").
  4. Alice sends both data to Bob.
  5. Bob first verifies that the EtM HMAC aligns with both the encrypted message and the secret password.
  6. On success, Bob decrypts the message and can safely assume that the received ciphertext is authentic and has not been manipulated.

Authenticated encryption is important for messages, but it is extremely vital when encrypting data, such as master keys. Unfortunately, MEGA's cryptography designer didn't factor this in, resulting in a huge weak link.

On page 17 of MEGA's security whitepaper:

The first half (from left) of the Derived Key (128 bits) is called the Derived Encryption Key, and it encrypts the Master Key using the current method: Encrypted Master Key = AES-ECB( Derived Encryption Key , Master Key )

You might look at that and think to yourself, "Hey, that's pretty smart! Encrypting the master key means that MEGA can't decrypt my vault's contents because only I can decrypt the master key." However, there are multiple problems with this implementation. In terms of integrity verification, there is none here. As mentioned previously, AES-ECB is not an authenticated encryption algorithm by default. This means that MEGA encrypts your master key, but does not take any steps to verify that the ciphertext is authentic and has not been tampered with. This is a security risk because it means an attacker can manipulate the master key and possibly deceive the client, without the user ever knowing.

Another example of the absence of authenticated encryption would be when MEGA encrypts file metadata, such as names.

On page 23:

AES-CBC(File Key, File Attribute Data)

AES-CBC, by default, is not an authenticated encryption mode, meaning it requires an HMAC to be computed with the encrypted output to verify that the output is authentic. This is not done.

MEGA should address this by encrypting keys with AES-GCM or AES-CCM, which are both fast and authenticated encryption modes that would prevent unnoticed manipulation or tampering of ciphertexts.

Category 2: AES-ECB

Throughout MEGA's whitepaper, they demonstrate the frequent use of AES-ECB, most prominently when encrypting sensitive data, like master keys, file keys and more.

On page 17:

The first half (from left) of the Derived Key (128 bits) is called the Derived Encryption Key, and it encrypts the Master Key using the current method:

Encrypted Master Key = AES-ECB( Derived Encryption Key , Master Key )

On page 18:

The private keys are encrypted by the Master Key using AES-ECB and stored by the API. MEGA has no access to plaintext private keys by any means.

On page 24:

Encrypted File Key = AES-ECB(Master Key, Obfuscated File Key)

On page 26:

When a user creates a shared folder, a random Share Key is generated. This Share Key encrypts all the file nodes using: AES-ECB( Share Key, Obfuscated File Key )

Out of all the AES encryption modes, ECB is probably the least secure one out of the bunch.

Wikipedia explains the weaknesses of ECB very well:

The simplest (and not to be used anymore) of the encryption modes is the electronic codebook (ECB) mode (named after conventional physical codebooks[19]). The message is divided into blocks, and each block is encrypted separately.
The disadvantage of this method is a lack of diffusion. Because ECB encrypts identical plaintext blocks into identical ciphertext blocks, it does not hide data patterns well. ECB is not recommended for use in cryptographic protocols.[20][21][22]

In a nutshell, AES-ECB is a horrible choice for encryption because it is simple and highly predictable. Unlike other AES modes, ECB is not pseudo-random and, therefore, can be deconstructed with relative ease. This presents a whole slew of problems, especially when a service, like MEGA, uses ECB to encrypt sensitive account keys.

To further add onto the reasons to avoid using ECB, the issues with ECB were given real-world tests when Adobe was breached in 2013. When storing user credentials, passwords must be hashed with password hashing algorithms, like Argon2, and not encrypted. Hashes are one-way representations and cannot be reversed, meaning even if password hashes were leaked onto the internet, they would be almost impossible to crack because of their exponential memory costs. ECB is not a hashing algorithm mode, and therefore can be reversed (or decrypted in this context). Hackers were able to crack these ECB encrypted passwords dumped from Adobe's database, putting thousands of users at risk.

What should MEGA do to rectify this mistake? Well, I'm pretty sure they know already, seeing as they use better AES encryption modes in other parts of their security architecture. Nonetheless, it bears repeating. MEGA should encrypt encryption keys using pseudo-random authenticated modes, like AES GCM or CCM, or use unauthenticated modes with an EtM SHA-512 HMAC.

Category 3: Relatively Weak Keys

Humanity is making enormous leaps in technological advancements, and one of them is in quantum computing. Quantum computers have extremely powerful architectures that can compute information exponentially faster than traditional binary computers we're used to today. This is why quantum computers pose a serious threat to current encryption algorithms, even the ones used by big companies, government agencies, and ordinary people.

According to ifsecglobal:

“Attacks that can run on quantum computers simply divide the number of bits of security that an AES [Advanced Encryption Standard] key provides by two,” says Martin. “A 256-bit AES key will provide 128 bits of security, etc. So if you are already using AES-256, you are already using an encryption algorithm that will provide an adequate level of security against quantum computers.”

If a 256-bit AES key provides half of its security in the presence of quantum computers, how will a 128-bit AES key fare?

Well, we should start asking these questions, especially when companies, like MEGA, boast "properly applied end-to-end encryption".

On page 16:

The client generates a random Master Key of 128 bits (16 Bytes) using the client’s native CSPRNG. For example, the web client uses the WebCrypto API’s Crypto.getRandomValues() function.

On page 24:

For encrypting files, a File Key is created of 128 random bits and a nonce of 64 random bits. Files are split into chunks, then each chunk is encrypted with AES-CCM. The 64-bit nonce is incremented for each chunk being encrypted.

MEGA uses 128 bit AES keys for both account master keys and file keys, instead of the industry standard 256. While 128 bit keys are not necessarily at jeopardy today, they might become insufficient for security in the next decade, maybe even half a decade.

The solution here is to switch to AES-256, or use another post-quantum encryption algorithm.

Category 4: Inconsistencies Everywhere

This section is a little more opinionated, but I believe it's still a relevant point nonetheless.

MEGA's encryption schemes look like they were designed by a 6th grader. Some data is encrypted with insecure modes, while others are encrypted with secure modes, but sometimes not without integrity verification.

On page 24:

For encrypting files, a File Key is created of 128 random bits and a nonce of 64 random bits. Files are split into chunks, then each chunk is encrypted with AES-CCM. The 64-bit nonce is incremented for each chunk being encrypted.

For some reason, MEGA chose to use AES-CCM, an authenticated secure AES mode, for file chunks, but AES-ECB, an insecure and unauthenticated AES mode, for account master keys. This makes absolutely no sense at all. Why not just use AES-CCM for both data types? It would be significantly more secure end-users.

As well, sometimes MEGA calculates HMACs to authenticate certain data, but not others, even those that require higher levels of security.

On page 33:

Message payloads are encrypted using AES in CTR mode, using the sender key and message nonce derived via computing an HMAC using the message’s master nonce as a key and the byte sequence “payload” as a value. The message nonce will be trimmed to use the 96 most significant bits (12 bytes) only, leaving 32 bits for the counter.

Why is HMAC computed for AES-CTR, but not for AES-ECB? If message payloads are authenticated, shouldn't account master keys and file keys be too? I'd argue that keys need authentication more than message payloads, but ideally they both should be authenticated.

Encryption algorithms with varying security are also used for some reason. MEGA uses AES-128 and RSA-2048 in some places, but implements more secure 512-bit keys for ECC and Curve25519 encryption.


MEGA's security architecture has a lot of room to improve. When their marketing explicitly talks about end-to-end encryption done right, they should actually do it correctly. Instead, MEGA's encryption is full of flaws, including lack of integrity verification, use of the insecure AES-ECB mode, relatively weak keys and a messy and inconsistent scheme. Many of these issues should have been resolved years ago, especially during the periods when MEGA saw the most growth in userbase.

Personally, if I used MEGA, I would switch off and find better alternatives with more secure encryption architectures. Below is a list of my favourites: