Slashdot Mirror

I posted this back when Wuala shut down. Seems relevant again just a few months later.

I've been using Sync.com for the past year. They've been sort of in beta but releasing features. 5GB free.

SpiderOak is decent but they recently dropped their free plan, so not sure what's going on there.

MEGA was great but Kim.com said last week in Wired that the company is run by criminals

Tresorit is good but expensive. Maybe that's why they've been around so long.
Bitcasa pulled a Wuala last year and closed down their consumer cloud storage after a lawsuit. That's pretty much it.
There's OwnCloud which is do it yourself. And BitTorrent Sync which is kind of do it yourself but they've been adjusting pricing so it's bait and switch as well.

I've been using Sync.com for the past year. They've been sort of in beta but releasing features. 5GB free.

SpiderOak is decent but they recently dropped their free plan, so not sure what's going on there.

MEGA was great but Kim.com said last week in Wired that the company is run by criminals

Tresorit is good but expensive. Maybe that's why they've been around so long.
Bitcasa pulled a Wuala last year and closed down their consumer cloud storage after a lawsuit. That's pretty much it. There's OwnCloud which is do it yourself. And BitTorrent Sync which is kind of do it yourself but they've been adjusting pricing so it's bait and switch as well.

If you get rid of the mobile requirement, http://mega.co.nz/ might be the solution for you.

Specifically designed by Kim Dotcom's folks so that they CANNOT access your data (so they don't tell if you've got financial paperwork or pirated movies). Has a method for sync'ing a local unencrypted filesystem into their cloud architecture.

The list of email addresses (without passwords) is at https://mega.co.nz/#!rgFDDRSD!...

Cloud services which use client-side encryption can store your private data securely. Mega.co.nz for example offers 50GB of storage space for free and they have support for linux, windows, mac nad android.

My first guess was the close working and financial relationship between PayPal and rent-a-spy Palantir with all it's NSA, FBI, and other government investors/customers. It would be way to easy for one of Palantirs 'customers' to make a few phone calls and pull a few strings to get this guys details.

I remember trying a fully anonymous P2P client years ago, but it was WAY to slow to be practical. Perhaps TOR + a file hosting service like megaupload could work. Megaupload was shut down, but iteration 2 (MEGA) has survived a year so far thanks to its encrypt-before-upload plausible deniability technique. Just don't ask for cash by PayPal, jeesh!

If that's "cheap" what would you call https://mega.co.nz/

They offer 50GBytes for FREE...

50 / 0 = !@#%$^*&^&(*$%^&

All those other companies gave no illusion of being secure.

Neither did Mega. They explain these very risks and others right in the FAQ and since they launched have using alternatives that do not involve trusting them. Providing a interface is a significant convenience, but you can't trust anything truly secret to a script someone else can remotely replace on a whim.

https://mega.co.nz/

For a Hoster that offers true Security take a look at https://mega.co.nz/. Your Data will be stored in New Zealand as far as i know but its probaby saver as in US.

You could use MEGA. But really, to even mention the nebulous word means that you don't care about security, encryption, or manner of storage. A company could design their "cloud" storage as a bunch of USB keys stuffed into the pockets of the employees with ROT-13 encryption and you'd be none the wiser as long as latency doesn't suffer (obviously the USB keys would be mirrored on a slighly lower latency device).

Nevermind. THOSE are gone now, too. Pity the State Department doesn't realize NOTHING goes away on the net. . .

So. . .

DEFCAD Mega Pack 4.2 (Saito)

Have you been hiding under a rock for the last few months? Mega gives you 50GB for free.

Some how this link just showed up to the whole article I wonder how ...

Dont read this

If that's the case, you can grab the paper by Dacke, et al. from: https://mega.co.nz/#!ytIz2bpL!S2P0Nk4NigHmr4Y0keSURlNzNElroFnUzx23nqKG0js and that of Wu and Dickman from: https://mega.co.nz/#!z5ohjYza!HZafDHCHTh8r1XcxKqOS6CuT4epGwK6PUh6ARCJbwd0

If that's the case, you can grab the paper by Dacke, et al. from: https://mega.co.nz/#!ytIz2bpL!S2P0Nk4NigHmr4Y0keSURlNzNElroFnUzx23nqKG0js and that of Wu and Dickman from: https://mega.co.nz/#!z5ohjYza!HZafDHCHTh8r1XcxKqOS6CuT4epGwK6PUh6ARCJbwd0

Hit the menu key on your phone and click "Request Desktop Site", or is this something else iPhones don't do?

Funny. It opens fine on my phone in Chrome, but on my desktop Chrome reports "The webpage at https://mega.co.nz/#blog_3 might be temporarily down or it may have moved permanently to a new web address".

User's password is used for unlocking user's RSA key. File key is randomly generated (and encrypted with said RSA key before sent to server).

They cover the crypto in section 1.4 here, if you're interested.

Not true. Have you actually checked the code, or do you just repeat the nonsense mentioned on many sites?

I haven't done a thorough analysis of the code / traffic so far, but from what I've seen so far the key is generated on the client-side using this Javascript, namely SJCL (Stanford Javascript Crypto Library). For example this is the keygen: https://eu.static.mega.co.nz/keygen_0.js, this is the RSA implementation https://eu.static.mega.co.nz/rsa_0.js and so on. Once the key is generated on client, the private key is encrypted with the user's password (which is also kept on client-side only), and this (public and encrypted private key) is sent to Mega server. On the next login the server sends the encrypted key (after some initial handshake, described in the developer docs) and the key is decrypted on the client-side again.

Please, explain to me how the server knows both my keys, how can they decrypt the data?

Obviously, there could be a malware, or they could send the password to the server, but let's suppose that's not the case.

Not true. Have you actually checked the code, or do you just repeat the nonsense mentioned on many sites?

I haven't done a thorough analysis of the code / traffic so far, but from what I've seen so far the key is generated on the client-side using this Javascript, namely SJCL (Stanford Javascript Crypto Library). For example this is the keygen: https://eu.static.mega.co.nz/keygen_0.js, this is the RSA implementation https://eu.static.mega.co.nz/rsa_0.js and so on. Once the key is generated on client, the private key is encrypted with the user's password (which is also kept on client-side only), and this (public and encrypted private key) is sent to Mega server. On the next login the server sends the encrypted key (after some initial handshake, described in the developer docs) and the key is decrypted on the client-side again.

Please, explain to me how the server knows both my keys, how can they decrypt the data?

Obviously, there could be a malware, or they could send the password to the server, but let's suppose that's not the case.

You haven't read their own FAQ I take it?

They're actually upfront about threats to the user's security.

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 shared folders and is detectable on the client side as well.

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.

Doesn't that look pretty reasonable? What more do you want them to do? They created a pretty impressive webclient-driven easy-to-use file locker system, and they clearly spell out the problems with that approach.

Many of the article's points are pretty moot, btw. It does not use JS random function, they have extra verification for the 1024 bit SSL encrypted data, and the deduplication only works for shared files ("copy to my locker" functionality is mentioned - same data, same key, same place on the storage servers).

The part about mega.co.nz being able to send malicious code stealing your password is explicitly mentioned in their FAQ, and in a better way too. They even cover other attack vectors the article didn't.

They made a decent system, and they're upfront and honest about it's limitations. The article is at best FUD.

You haven't read their own FAQ I take it?

They're actually upfront about threats to the user's security.

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 shared folders and is detectable on the client side as well.

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.

Doesn't that look pretty reasonable? What more do you want them to do? They created a pretty impressive webclient-driven easy-to-use file locker system, and they clearly spell out the problems with that approach.

Many of the article's points are pretty moot, btw. It does not use JS random function, they have extra verification for the 1024 bit SSL encrypted data, and the deduplication only works for shared files ("copy to my locker" functionality is mentioned - same data, same key, same place on the storage servers).

The part about mega.co.nz being able to send malicious code stealing your password is explicitly mentioned in their FAQ, and in a better way too. They even cover other attack vectors the article didn't.

They made a decent system, and they're upfront and honest about it's limitations. The article is at best FUD.

Update : Regarding the random source, this is the code they use, and it's from this project. It use mouse and keyboard events (not all, math.random is used to decide which ones), with rc4 as mixing function.

And it seems to be running since page load (started in crypto0001,js) - AES function is from Stanford Javascript Crypto Library btw, and RSA code is from this project.

In the article, is this what they're referring to or is it another script file? https://eu.static.mega.co.nz/keygen.js

It says on their developer page:

This master key is stored on MEGA's servers, encrypted with a hash derived from the user's login password. ... In addition to the symmetric key, each user account has a 2048 bit RSA key pair to securely receive data. Its private component is stored encrypted with the user's symmetric master key.

According to that, the keys are stored on the server, but it's encrypted with a hash of your password... I understand that all they would have to do is store the generated key somewhere and have full access to all your files if they wanted. I'm not debating that.

The part I'm trying to figure out is:

The cryptographic integrity of MEGA's user data is important to us. We can therefore not allow you to distribute or make available your client application without going through us. We will perform a code audit of your product and promote/distribute it on our site.

So they want full access to the source of your client "to ensure the integrity of MEGA's user data" but for some reason I keep reading that as though they know the properly coded application could damage their site.

I wrote a comment about the crypto system yesterday, from a outsider amateur's point of view. Nothing in that article was even surprising.

It's actually pretty cool, they do point out more or less the exact things in their FAQ, which is surprisingly honest for such a site. Most would try to handwave it away or just outright ignore it.

As extra info to that comment I wrote earlier, I confirmed that they save a version of the RSA key on their server, and during login a blob of data is sent in (login user in cleartext, and probably hashed / crypted pw) to check if its a valid user before handling out the RSA key.

I can imagine sharing works like this : 1. find friend, 2. get pub key for friend, 3. decode file key with my private key, 4. encrypt it with friend's public key, 5. send to server

And sharing folders .. I guess each folder have an encrypted list of keys to files in it, and the key for the folder is encrypted with your key. So sharing a folder would then work much the same as sharing a file.

And regarding deduplication I saw an idea in a comment that could explain that. Every file is hashed locally, the hash being the actual AES key. Encrypt file, use pub RSA to encrypt hash, send both to server. Same file will be same file, dedup works, and everyone got their own key to it. That would also allow them to nuke all uploads of an illegal file, and keep "bad file" hash lists for child porn and similar.

Now, I haven't actually looked at the JS code for the service yet, so all of this guesstimate :)

Links in the summary... NONE of them to the actual service. Brilliant!

Here is the actual site: https://mega.co.nz/

2. AES-256 is slower than AES-128, but actually slightly weaker. Why, specifically, was AES-256 chosen? 3. What cipher modes are used, and where? I skimmed the site briefly but though some other details were disclosed,

From the API documentation (at https://mega.co.nz/#developers):

"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."

Of course their own client may work differently.

To add to that, they do have API and let you build clients with it, although you need to have it approved with them.

https://mega.co.nz/#developers
As far as their future (at bottom), it looks like they'll just be developing this for the browser, but the API appears to be fully open for developers.

https://mega.co.nz/#developers
As far as their future (at bottom), it looks like they'll just be developing this for the browser, but the API appears to be fully open for developers.