Does anyone understand how their implementation of client-side encryption is actually supposed to make my data safer? After logging in for the first time, a 2048-bit RSA key pair was generated, but it seems that every time I log in I just use a username (email) and password. Does that mean the RSA private key is stored on MEGA's servers? If so, doesn't that render the whole "client side encryption" bit moot? If MEGA has the private key, they can decrypt the data or am I missing something?
The service seems to have ground to a halt, and I am not able to upload anything, so perhaps this all becomes clear once one starts using the service, but I'm curious about how the encryption is used in practice.
Edit: Found a bit more detail in the developer documentation: https://mega.co.nz/#developers
According to this, they use the symmetrical AES-128 to encrypt files, so why do I need an (asymmetrical) RSA key pair? It also says there that the private part of the RSA key is stored encrypted with the symmetrical AES key, but MEGA has that key, so what good does that do in case of an FBI raid?
One of the things that I was most curious about regarding MEGA was to see how they would manage to make encrypted file storage safe but user friendly. It seems like this is user friendly, but not safe at all, or am I wrong?
| 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.
The key is stored encrypted on their servers, but is unlocked with your password. Technically they could capture your password and unlock the key, gaining access to the files.
MEGA servers store the hash of the password, not the password itself.
Unlocking a key requires a real password but the server knows only the hashed version. This way they can't capture the real password to unlock. The trick would be to make sure server always gets only the hashed password. Even at website login, the password must be hashed before sending!
We used similar crypto for http://timegt.com product where everything is end-to-end encrypted with a keypair generated by the user yet stored at the server. But it's stored at the server in a locked form that can be opened with a password that user entered. But this password is never sent to the server, only the password hash is and is used only to make sure that it's ok to send this locked key to the user. Hopefully this didn't sound too confusing now...
As long as the logins go via normal web page hashing the passwords before sending them does not really add that much security. If the security of the server is somehow compromised, it would be trivial to put up new Javascripts that send the cleartext password to server. Users are not likely to go through the Javascript to check what it is actually doing.
This is how similar services have responded to warrants. They voluntarily alter javascript for some ip addresses in order to capture passwords to use for decryption of the user's files.
It would probably be easy to write your own login page or a browser toolbar that would either do the hashing on a page you control or check that the javascript was what it should be.
At that level of distrust however you might as well encrypt the stuff yourself (and send the decryption keys to the people you want to share with in some other, more annoying but secure, way)
What if I don't trust you? Is it still safe for me to use MEGA?
If you don't trust us, you cannot run any code provided by us, so opening our site
in your browser and entering your password is off limits. If you still want to use
MEGA, you have to do so through a client app that was written by someone you trust.
Fully agreed on the server compromise risk. Fortunately this attack vector would compromise only users who log in after the attack. Users who don't are still safe.
Improving this situation could involve keeping a browser extension that takes care of the hashing algorithm and makes sure the real hash is sent. As long as the extension is not updated, the hashing would be safer.
In my eyes, it's not secure because the AES key is stored, albeit encrypted by a password, on the server side along with a file of the password hashes. Even when best practices are followed, it's still relatively easy for an attacker to recover passwords from their hashes via a brute force attack.
If the goal was actually to create something very secure, I would say that the keys would need to stay entirely on the client side, but this of course has its own usability problems. As it is, I'm curious as to how password resets can be carried out.
That being said, it's probably relatively secure as long as the cloud provider isn't raided or coerced to act badly. They can reasonably say that the data is encrypted and that they don't have access to the key.
I would be interested to see what the crypto looks like when the site is used for file sharing (e.g. I upload once, then post a link for many to download). Or am I just assuming that there's an option for this use case?
EDIT: The senario in the posts above sound more likely. The exact text of the help is "No usable encryption keys ever leave the client computers (with the exception of RSA public keys)." So they probably store an encrypted version of the keys server side.
According to Ars, the public sharing works by bundling the encryption key with the link to the data [1]. I don't have reliable access to the site, so I don't want to speculate too much, but I suppose there must be a way to export your keys so you can view your files from different computers.
I agree with the sentiment, though, that this is security theater. It's subject to the same problem as Hushmail, where they could be forced to snoop on their customers by modifying client code.
Ok, just my guess, not sure if that's what they do.
They can store the encrypted key on their server and send the encrypted key to the client whenever the client requests it. The client decrypts the key locally and use the decrypted key to decrypt the data.
With this scheme, the user can use a client on any machine to download his encrypted key and use it locally.
The service seems to have ground to a halt, and I am not able to upload anything, so perhaps this all becomes clear once one starts using the service, but I'm curious about how the encryption is used in practice.
Edit: Found a bit more detail in the developer documentation: https://mega.co.nz/#developers According to this, they use the symmetrical AES-128 to encrypt files, so why do I need an (asymmetrical) RSA key pair? It also says there that the private part of the RSA key is stored encrypted with the symmetrical AES key, but MEGA has that key, so what good does that do in case of an FBI raid?
One of the things that I was most curious about regarding MEGA was to see how they would manage to make encrypted file storage safe but user friendly. It seems like this is user friendly, but not safe at all, or am I wrong?