A word on cryptography
mega.co.nz
mega.co.nz
But i'm going to tell you why he has no good press, because he has no crypto creds, there are plenty of experts who think that you don't have the right to write any crypto code if you don't have the appropriate creds and are very vocals when any attempt is made by someone not of their kind, some of them even behave like bullies. I say don't listen to them, write some crypto code, make some mistakes, learn from them and correct them.
This isn't someones little toy app, this is a professionally done, "we will protect your privacy" service with the government already breathing down their neck. The sloppiness they are showing in their crypto (or at least in their presentation of the crypto) is just unacceptable.
You can write crypto code and not rewrite all the primitives, I certainly think that any good software engineer could write his own implementation of operations on GF(2^n) but if it's a good software engineer he will also prefer to pick the right primitives, use the right libraries and write the right crypto glue code. It's not all or nothing. You can be a professional software engineer and write crypto code.
This is really not an area for hotshot lone developers to contribute to, the stakes are just too high.
it would not surprise me if the service is shutdown again somehow. i would guess they would lean on the banks of CC companies that process his CCs first.
These guys have tried really hard to do something complicated nobody has really done before. Sure, it has a few bugs and isn't 'perfect'. Neither was the space shuttle, neither was the HTML 1.0 spec. Nothing ever is.
It's currently in style to put down tall poppies and complain about everything and anything, even when it's free and you don't even have to use it if you don't want to.
A community like Hacker News should be praising people trying to get off the beaten path. Sure, constructive criticism is good, but flat complaining "It's just unacceptable" is complete nonsense and a waste of everyone's time.
That's not a small bug! That's a totally broken product.
> A community like Hacker News should be praising people trying to get off the beaten path.
They do, when it's done right.
to claim that nobody has done client-side encrypted storage with sharing is clearly incorrect.
You'll not go far with that mentality.
there are plenty of people doing more interesting work with encrypted data storage. to suggest that mega is blazing a new trail is absurd. backblaze has been using a similar key-per-file encryption method since 2007, except they actually executed properly.
Crypto is in a very real sense all-or-nothing. You either get it right, or you get it wrong. There is no inbetween. Given a weakness, the best attacks almost inevitably drop from requiring O(2^keylen) operations to something along the lines of O(messagelen) operations.
Worse, it is often very difficult to dig yourself out from a deep cryptographic hole that you've gotten yourself into. If you've done it right, you won't be able to do things like rehash user passwords without the user actually supplying his/her password. You won't be able to reencrypt data with new algorithms until the user supplies his/her key. And if you haven't thought ahead and added proper metadata to identify the algorithms and encodings you've used, your migration to any new architecture is going to be a massive pain in the ass. And even in the best case scenario, you will never be able to "upgrade-in-place" the algorithms and approaches you've used for users who've gone dormant. Worse again, if anyone has already gained access to encrypted data before you began the process of upgrading, they have literally an indefinite period of time with which to attack it.
Bad cryptography almost always implies a lack of people with a real cryptographic background. And that implies that at least one of: they don't value security as much as you think they do, or they actually think they know what they're doing and are utterly mistaken. Neither of which bodes well for real long-term solutions, and hints to an endless game of exploit whack-a-mole.
Everything I've read about the cryptography used in Mega leads me to believe it was implemented by well-intentioned amateurs who have tragically fallen victim to the Dunning-Kruger effect. Their use of cryptography amounts to little more than advanced cryptographic voodoo — their approach is to cryptography what Deepak Chopra's approach is to quantum mechanics. It's little more than advanced cryptographic voodoo. I'll note also that they seem to be taking the exact stance you seem to be advocating: just writing glue around a sound cryptographic core. Except their glue code is pitifully insecure, combines primitives in nonstandard or cryptographically unsound ways, and uses primitives for operations they were never intended for and aren't suited for.
TL;DR, bad cryptography is forever.
I thought MEGA's sales pitch was pretty good. And then I saw their Javascript hashing code. Oh, the hilarity.
They're using a broken variant of CBC-MAC to authenticate their Javascript. Except CBC-MAC isn't a hash. The key is public, so it's a joke.
CBC-MAC only works as a MAC, not as a hash function. You can replace all of their JS, do a trivial subtract, and make it "hash" the same.
They also make other mistakes, like not authenticating the length and just concatenating the various files, so other attacks are possible.
But I wouldn't want to dignify the notion that one piece of Javascript can "validate" other Javascript "files" anyways; the whole notion of Javascript validation is dubious, because what you need to validate is the whole JS runtime, not just individual files. Browsers don't provide tools to do that.
I tried googling javascript runtime (primarily v8) exploitation and haven't been able to find any examples of this ever happening.
Edit: I'm not saying its not plausible, but wouldn't it require root/user access? What benefit would it provide over other type of attacks with that level of access? Just because there's no browser tools to check for it?
http://www.adambarth.com/papers/2009/barth-weinberger-song.p... Cross-Origin JavaScript Capability Leaks: Detection, Exploitation, and Defense
Although these vulnerabilities are imple- mentation errors in WebKit, the presence of the bugs illustrates the fragility of the general architec- ture. (Other browsers have historically had similar vulnerabilities [17, 18, 19].) We detail these vulner- abilities and construct proof-of-concept exploits to demonstrate how an attacker can leverage a leaked JavaScript pointer to inject a malicious script into an honest security origin.
The pwnage can even persist into the future for that user when you consider the ability of browsers to cache content and HTML5's data store.
I get what you're driving at, but can't infer what you're conspicuously not explaining in full.
you can probably drive a nail with a screwdriver handle if you try hard enough.
without going back and looking at the mega js, i recall it working as follows
password --> CBC-MAC --> master key --> decrypt RSA private key with derived master key
if you're deriving a key from a password, seems to make sense to use a password-based key derivation function.
but the other side of it is, he's kinda right too. he's recruiting from the ccc. a good place to recruit from. and he's talking about ACTUALLY making money on stuff. it's kinda what my mother was saying when i was doing mainly opensource stuff. she said, why are you working for free, and I said you don't understand.
Germany is a kinda socialist country. I know, I grew up there. That's why there's a whole bunch of great open source projects coming out that place. And then the americans come, and make money on it.
I'm kinda derailing, and I could go on, but I'll just leave it at he's a douche, and he may be a fraud, but the guys he's trying to recruit from are not. And he kinda has a point.
And look at him now. He's got a shitload of funds, enough to pick a fight with a government, and where's the CCC? It's still hiding behind political correctness, still doing stuff years ahead of defcon, and yet everyone talks about defcon instead.
Many people only see programming as a job, and thus do not understand why anyone would ever program if they didn't get paid. That is the only aspect they see in it, and thus they think that their logic is without fault. But had one been spending time playing music, with that independent band in a an abandon factory and only playing music "for free" at charities and bars, that mother would not wonder why you where "working for free". We would also not call it a socialist thing to do.
There is of course political movements involved with programming, ie free software. But even there, the term socialism is hard to use when there is so many large companies involved. If one then take a look at music bands that refuse "the big labels", or who are anti-establishment, we would also there not call them socialistic just because they do stuff without getting paid.
In the end, one can not take a single economic model and apply it to open source or free software, or for that matter any other thing that people has as a both work and hobby.
germany is socialist. when you go to university, and you do something you are expected to do it for free. all the research is free. you attend university for free.
the flipside of it is that you are expected to give 50% or more of your salary for everyones and your own benefit. you have no say in it whatsoever. you cannot choose to have insurance, it was chosen for you. you are not supposed to get rich. when they wanted to get indian engineers to germany the indians said what do we get? and germany said, just the opportunity to work for us should be enough. It should give you a hint on the mindset.
i had this discussion with one of my professors, and he said yes. his salary is low, but the positive side is that he research anything he wants. he doesn't have to say what the industry wants him to say, because his funding depends on it.
it has good sides, and it has bad sides. of all the things I said, you chose to pick on the open source side of it. really.... ?
The funny thing is: In the mid 90s he was making money out of surveiling other people's messages and posts on his own BBS.[1] By the way, that whole story makes me nervous when I think about people hosting their sensitive data with him. That can't be good.
Now, back to the recruiting thing: Would you like to be recruited by that kind of guy? I for one completely understand the CCC people.
What is it with him that people seem to trust him and his businesses? I mean, it's not that any of them have prevailed and not been closed down by authorities after some time.
-----
[1] Again, German. Maybe I should translate that. :-) http://de.wikipedia.org/wiki/Kim_Schmitz#Auftreten
The basic idea would be that Megaupload looked very much like his mid-90s warez BBS scheme, just on a much larger scale.
So their implementation has flaws. Security experts are pointing them out. I expect they'll be fixed soon enough.
The "If you can break SSL, you can break MEGA." made my day. I think MEGA is the least of your worries if SSL is broken; credit card transactions would be compromised big time.
I have no doubt that some of the criticism is rooted in just a general hatred and cynicism about "kim.com" and has no foundation, but some of the things they're doing are legitimately questionable. Like having javascript served from their servers have access to your password. If you want it to be secure against them, you can't really do that. If they get compromised then their server will serve compromised javascript and your data can be read by the attackers the next time you access it.
But it's a trade off -- using javascript has somewhat lower security but is easier for users to use -- and it seems like they even recognize it. The way around it is to use a community-verified open source client (like a browser plug in) to process users' passwords and never leave them or the unencrypted data in the control of code from the Mega server, and it appears they have plans to do that. And that has other benefits as well, like making it easy to use high entropy machine-generated passwords for every piece of data and having the plug in store the passwords encrypted on your local disk with a master secret, so that you only have to remember one strong password for all your data (or, if you're paranoid, one password for each set of data classified by security level).
>The "If you can break SSL, you can break MEGA." made my day.
Yeah, is that actually not a straw man? Someone really said that? I have to hope they were being sarcastic.
> But the problem goes beyond trusting Mega’s servers, says cryptographer Moxie Marlinspike, who recently left a position as head of product security for Twitter. Browser-based cryptography also means that anyone who breaks the SSL encryption that protects the data sent by the server could tamper with the code just as easily.
> “The security of Javascript-based cryptography is reducible to the security of the channel in which the Javascript is transmitted (every time you visit the page), which in this case is an SSL connection,” Marlinspike writes to me in an email. “If you can break SSL, you can break MEGA.”
Source: http://www.forbes.com/sites/andygreenberg/2013/01/21/researc...
And actually it's not a bad point for a service like this, in the sense that browser-based SSL will never protect you against a government who is trying to read your secrets, because the government can always coerce a local certificate authority into giving it a certificate for whatever site it wants to impersonate. The only way to prevent that is to remove all the common certificate authorities, which doesn't actually improve security at all (it really makes it worse under normal usage patterns), but it reduces your inclination to have a false sense of security.
So it's a valid point: If you need really good security, especially against governments, javascript-based password decryption is a fail, not least because it depends on SSL. But those people may still be able to use the service, just not the web interface to it, and I kind of expect they'll be a minority of the users in any event.
If the the security of MEGA reduces to the security of SSL, then all this Javascript crypto amounts to just extracomplicated security theater.
Q: So why bother?
A: It might be useful in a situation like Megaupload where the adversary seizes their servers while simultaneously shutting down their service.
Several XSS flaws were fixed quickly:
http://reflets.info/le-retour-du-mega-merdier-de-kim/
(french)
Taking a quick look at the source, it looks like they're doing some sort of crypto. Very weird.
At Megaupload, your files were private from other people. Mega themselves has/had no interest in snooping through your files. Various copyright enforcement agencies are very interested in ensuring that users are not violating copyright.
There is nothing about their system that is less secure than Megaupload was. In both cases, everything goes over HTTPS. The only new addition (no matter how broken their system is) is that now Mega cannot be reasonable expected to monitor file upload content, or provide third parties with the ability to monitor content.
Certainly if they are advertising security for end users, they should deliver it properly, but honestly I doubt that is their actual intent. This seems to be the sort of 'security' that only needs to be strong enough that they can say with a straight face in court that they cannot break it themselves.
The gears are a little suspicious, though.
Is it possible or desirable to secure a web app from its own creators? The web is by far the largest and most successful software distribution mechanism of all time (depending on how you define 'software') and it's built around the idea that the creator can update the app at any time in a completely agile fashion. But for certain classes of software, maybe it makes sense to protect the users from the authors, or the authors from their future actions.
You might be able to accomplish something like this in a really hacked-up fashion with HTML5 application manifests. Perhaps you could have the application manifest include itself, to prevent the page from ever trying to load itself again, and then have all updates happen though an AJAX mechanism that validated each download and allowed third parties to verify that it was safe.
But rereading the idea, it sounds neither pleasant to use nor particularly safe. Is this "packaged software" mechanism something that should be built into the browser at some level, or are we just doomed to running this class of applications as native apps?
that's not to say you shouldn't be worried either your silicon or NIC firmware are compromised ;)
when "crossing your t's and dotting your i's" it is usually best to use an out-of-band method to check signatures, e.g. download binary installer, check gpg signature or calling them on the phone to verify fingerprints. even so, this cannot stop a MITM unless you do the key exchange in person, e.g. meet the software creator and exchange gpg pubkeys on the spot.
But, in case you think that makes you unable to actually read the article: on the Nexus 7, you can click the "menu" button (those three vertical dots) and select "Request desktop site".
Ultimately, they have a good chance to be the most secure hosting service available for masses.
Huh, I don't know how they do not get Internet. All the messed up encryption and now this.
Bye Mega, I'm never joining of visiting you. And Kim Dotcom, sir, you make good entertainment but I don't think your services suit me!
> 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.
If they find a ripped version of a movie/ebook/whatever they can just encrypt it using Mega's scheme (which would now derive the key from the data) and get a single version of the file out. They then tell Mega to remove any files that match that encrypted file.
If all files are encrypted with a random key there's no way for law enforcement to do this.
The whole thing with deduplication is a little bit overblown anyway. You don't want a hundred copies of the same big file, but is that what really happens? Nobody wants to upload the same file a hundred times, especially if the file is very large. Once there is already a copy, passing around a link to it is much easier than uploading it again. So the most common cause for it to happen is when two totally unrelated people upload the same bit-for-bit identical file, which happens, but not so often as to be prohibitive.
And in many cases file-level deduplication is difficult or impossible anyway because users make changes to the files (like editing embedded metadata or pointlessly encapsulating a single already-compressed file into a .rar archive), so the benefits you get from deduplication are not nothing, but there are situations where it is or isn't a reasonable trade off to make against privacy.
edit: Clarify.
Based on all the analyses published so far, it does not look like that at all. In your view, what makes it appear that their crypto was implemented in anything resembling a proper fashion?
I bet they support this. If I were Mega, I'd be doing this yesterday.
var x = new Uint8Array(10);
window.crypto.getRandomValues(x);
console.log(x);Probably substitute cmd for ctrl on other OSes.