How does Mega's encryption work for sharing?

Question

I have some issues regarding to find a way to achieve the encryption of arbitrary data that can be shared with multiple recipients. Mega seems to do exactly that. As far as I read it encrypts the data before its uploaded to the web server. Still it is possible to share that file with others. How is that done with the encryption?

Imagine the following scenario:

1. User Alice uploads a file to the server, it is being encrypted
2. Alice wants to share that file with Bob and Dave. How can Bob and Dave access the file and see its original content (decrypted)?

Answer 1

How is that done with the encryption?

The answer is symmetric-key algorithm. Mega utilizes in-browser, symmetric key encryption provided by HTML5. See question "What encryption algorithms does MEGA use internally?" below.

As onemouth said, your data glob is encrypted with a master key.

Every user also has a public/private key pair. And every file is encrypted under different session key. Session keys are encrypted under user's master key.

To understand how it all works means looking at all the component pieces and seeing how they interoperate. Mega explains the process of encrypting symmetric/shared keys on their website:

(embedded links and emphasized text in quoted text added by me)

What encryption algorithms does MEGA use internally?

For bulk transfers, AES-128 (we believe that the higher CPU utilization of AES-192 and AES-256 outweighs the theoretical security benefit, at least until the advent of quantum computers). Post-download integrity checking is done through a chunked variation of CCM, which is less efficient than OCB, but not encumbered by patents.

For establishing shared secrets between users and dropping files into your inbox, RSA-2048 (the key length was chosen as middle grounds between "too insecure" and "too slow"). All encryption, decryption and key generation is implemented in JavaScript, which limits throughput to a few MB/s and causes significant CPU load. We are looking forward to the implementation of the proposed HTML5 WebCrypto API in all major browsers, which will eliminate this bottleneck. JavaScript's built-in random number generator is enhanced through a mouse/keyboard timing-driven RC4 entropy pool as well as crypto.* randomness where available (Chrome and Firefox only at the moment - keys generated by Internet Explorer and Safari are less secure than they could be).

How does folder sharing work?

You can share any subtree of your cloud drive with friends, family or coworkers. Invitation is by e-mail address. Invitees who do not have an account yet will receive an e-mail notification with a signup link. Alternatively, you can create a public link to any of your folders and export the folder-specific crypto key, making it accessible without a MEGA account. It is then your responsibility to securely transmit the folder key to the recipient(s).

To establish, modify or delete a share, simply right click on a folder in your file manager and select Sharing. There are three access levels: Read-only, read/write (files can be added, but not deleted), and full (files can be added and deleted). If you added an e-mail address that did not have an account yet, you need to be online at least once after the recipient completes the signup process so that you can encrypt the share secret to his newly created public key.

Is data that I put in shared folders as secure my other data? Shared folders, by nature, are only as secure as their least secure member.

Instead of just one master key, you now have another key that you have entrusted to X number of people. Your security is as great as your trust of those X people.

Each file on Mega has a unique ID. So if the credentials are:

fileId=Abc123Ab
shareKey=abcdefghijklmnopqrstuvwxyz0123456789ZYXWVUT
https://mega.co.nz/#!fileId!shareKey

Attempting to download

https://mega.co.nz/#!fileId

will result in downloading the encrypted file. The file cannot be decrypted unless the user has the shared decryption key. How you get the "shareKey" to someone is up to you. But anyone with access to that shareKey can decrypt the downloaded file so sending the full URL via email or other unencrypted mediums is a bad idea. Once a shareKey is generated (by "Get Link" in the webapi) it cannot be changed.

And additionally,

However, a compromise of our core server infrastructure poses an additional risk: Public keys could be manipulated, and key requests could be forged.

What they are saying is the security issues that arise without sharing enabled increase because the individual threats of individual private key compromise.

Is my stored data absolutely secure? All security is relative. The following attack vectors exist - they are not specific to MEGA, but we want you to know about the risks: Individual accounts are jeopardized by:

• Spyware on your computer. A simple keylogger is enough, but session credentials and keys could also be extracted from memory or the filesystem.
• Shoulder surfing. Do not type your password while someone could watch your keystrokes.
• Password brute-forcing. Use strong passwords.
• Phishing. Always confirm the security status of your connection (https://) and the correct domain name (mega.co.nz) before entering your password. Large-scale attacks could be mounted through:
• A "man in the middle" attack. Requires issuing a valid duplicate SSL certificate in combination with DNS forging and/or attacks on our BGP routes (a DigiNotar-style scenario).
• Gaining access to the webservers hosting https://mega.co.nz/index.html and replacing that file with a forged version (this would not affect access through the installed app base). Note that manipulating content on our distributed static content CDN does not pose a security risk, as all active content loaded from index.html is subject to verification with a cryptographic hash (think of it as some kind of "secure boot" for websites). This type of attack requires sending malicious code to the client and is therefore detectable.
• Gaining access to our core server infrastructure and creating forged key requests on existing shares. This type of attack only affects data in accounts with shared folders and is detectable on the client side as well.

Furthermore, not all data is private and most user-identifiable information is stored unencrypted.

Is all of my personal information subject to encryption? No. Only file data and file/folder names are encrypted. Information that we need operational access to, such as your e-mail address, IP address, folder structure, file ownership and payment credentials, are stored and processed unencrypted. Please see our privacy policy for details.

More detail can be had in their API documentation at https://mega.co.nz/#doc

12.2 Cryptography

All symmetric cryptographic operations are based on AES-128. It operates in cipher block chaining mode for the file and folder attribute blocks and in counter mode for the actual file data. Each file and each folder node uses its own randomly generated 128 bit key. File nodes use the same key for the attribute block and the file data, plus a 64 bit random counter start value and a 64 bit meta MAC to verify the file's integrity. Each user account uses a symmetric master key to ECB-encrypt all keys of the nodes it keeps in its own trees. This master key is stored on MEGA's servers, encrypted with a hash derived from the user's login password. File integrity is verified using chunked CBC-MAC. Chunk sizes start at 128 KB and increase to 1 MB, which is a reasonable balance between space required to store the chunk MACs and the average overhead for integrity-checking partial reads. In addition to the symmetric key, each user account has a 2048 bit RSA key pair to securely receive data such as share keys or file/folder keys. Its private component is stored encrypted with the user's symmetric master key.

12.3 Shared folders

The owner of the folder is solely responsible for managing access; shares are non-transitive (shares cannot be created on folders in incoming shares). All participants in a shared folder gain cryptographic access through a common share-specific key, which is passed from the owner (theoretically, from anyone participating in the share, but this would create a significant security risk in the event of a compromise of the core infrastructure) to new participants through RSA. All keys of the nodes in a shared folder, including its root node, are encrypted to this share key. The party adding a new node to a shared folder is responsible for supplying the appropriate node/share-specific key. Missing node/share-specific keys can only be supplied by the share owner.

12.4 Unauthenticated delivery

MEGA supports secure unauthenticated data delivery. Any fully registered user can receive files or folders in their inbox through their RSA public key.

Ultimately, you are trusting their javascript code which is verified authentic by HTTPS. Then you are trusting your javascript engine (web browser) to correctly handle the transaction. And finally you are trusting your operating system to not allow other running processes to sniff out the unencrypted private key in RAM (see https://nzkoz.github.io/MegaPWN/).

There are certainly precautions to take along the way, but it is one of the best options currently available. You can always encrypt your files before uploading to Mega with GPG to alleviate some of the issues outlined above.