This is just another example where I don't understand why people are so critical toward someone who try to build something. Are there any flaws? probably, but who would honestly expect such massive code base wouldn't have any flaw? but does that fatally undermine what he's trying to achieve? I don't think so.
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.
There's a big difference between writing your own code just to learn how AES works and writing code and then saying "we will protect your privacy using this code". The reason experts discourage people from writing crypto code is because it's Hard; even the experts get it wrong. Even if you ignore all the weaknesses you can create by using bad keys, there are still simple mistakes that will ruin you system. For RSA you need to make sure your key generation isn't subject to Pollard's p-1, Pollard's rho, William's p+1, Fermat factorization, Wiener's attack, and others. And then once you do that, if you pad incorrectly the whole thing gets blown up anyway.
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.
Please do not ship crypto software or, especially, crypto protocols (e.g. Alice does this, then Bob does that) that haven't been publicly audited. It's an unnecessary liability to your company, your customers, and the public when there are alternative solutions that do not have the flaws that a) you think that you don't have but do, or b) don't know that you have.
This is really not an area for hotshot lone developers to contribute to, the stakes are just too high.
People hear "don't roll your own crypto", and think that it means "don't invent your own encryption algorithm". Really it should be reprhased, "don't ever touch crypto directly".
I understand, I Must Not Write Crypto Code™. However I choose to write whatever I want anyway, crypto experts must not be the only ones writing crypto flaws, so can i.
I don't care what you write, but if you go into it thinking that the dangerous stuff is in the primitives like the AES core, and if you just stick to the glue you'll be safe, you're gonna have a bad time.
if the crypto implementation is this poorly thought-out, you can only imagine how shaky the rest of the backend code is.
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.
Don't worry I knew that this rant would be controversial, I have few sparred karma points to handle it, it's worth it, anybody should be able to freely express what he thinks.
if by "cut down tall poppies" you mean bring mega's claims of security and privacy in-line with reality, sure.
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 not like other features of a web application. With most other features, it can be mostly working and have a few bugs, but still be useful and functional. Bugs can be ironed out over the course of time.
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.
CBC-MAC is also tricky to get right even if you know what it is. It's a very weird choice.
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.
Huh? It's perfectly valid in theory for one piece of trusted JavaScript to download another from an insecure source and validate it before evalling it - the attack scenario is not the browser being compromised, it's the source delivering malicious code. (Whether this is really a useful thing to do compared to serving all the JS in one place is another question.)
Real systems that try to implement this scheme generally wind up implementing the misconception that everything that contributes to the JS runtime comes from discrete Javascript files.
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?
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.
That's the thing about Javascript. The tiniest little XSS or subtle origin violation results in the entire browser app being 100% 'pwned' (to use the technical term).
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 think he's confusing the key-derivation function this article talks about for your "master key" with the MAC-in-JS this particular thread is discussing.
I haven't read much actual writing from the Mega crew...but I was impressed with its lack of ad hominem in its rebuttal. Sometimes, these technical debates, especially when played out in the media, can get quite snarky.
The ad hominem way of discussion may or may not be present in technical debates in general. What actually doesn't surprise me is that this style surfaces on publications associated with Dotcom. If you happen to speak/understand German you (really!) should read this: http://arnold.babsi.de/KIMBLE.txt
Basically the file contains old newsgroup postings from de.org.ccc wherein Dotcom (Kimble) argues with or better harrasses the CCC guys. It's really "worthwhile" and and an eye-opener.
well, you know. i can see now why the ccc guys hate him. my coworkers said he was a douche. and I can also see how they would say he talks more sales than skill...
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.
Your post include many different topics, but I will just try to address one of them. The anecdotal about open source and the implied socialist implication.
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.... ?
Where he surely has a point is the ability of the german economy to actually monetize on new and innovative technologies. Which is, to be frank, not so good no matter the german industry keeps telling. It used to be different, so.
So, first of all: Does that look like recruiting to you? Looks more like a personal vendetta to me. If you're trying to recruit someone, you're most likely not going to do it by saying "oi, look. I'm gonna be the next chancelor, don't you wanna work for me?". Not even ironically.
"ACTUALLY making money on stuff" is great, probably more people should do that. But making money out of something and then selling out your customers (if you can call them customers) is not at all the right way to do it. And that's exactly what happend with Dotcom and his BBS stuff, where he was actually selling warez and denouncing his customers to the authorities, afterwards working for von Gravenreuth.
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.
It seems like the security vulnerabilities are somewhat beside the point. It's basically a beta, it's got bugs. But what they're trying to do is capable of being secure. You can store data on a server without the server operator having any ability to know what it is. It's not a new thing: You've always been able to upload a truecrypt volume to any untrusted server. They're just trying to make it easier to use for the man in the street.
So their implementation has flaws. Security experts are pointing them out. I expect they'll be fixed soon enough.
They haven't found any concrete flaws though. Just speculation and outright wrong information.
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.
>They haven't found any concrete flaws though. Just speculation and outright wrong information.
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.
It's not, they did, and I don't think they were. Quote from article:
> 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.”
Meh. He's not complaining about Mega, he's complaining about SSL. He's always complaining about it, and he's mostly right. There are legitimate problems with it. In particular, too many questionable entities are registered as certificate authorities in common browsers, so you periodically see these imbeciles issuing wildcard certificates for * .google.com or * .gov which totally compromises the ability of browser-based SSL to prevent man in the middle attacks against anyone who can socially engineer or coerce their way into one of those certificates from any one of the inept certificate authorities.
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.
Kim Dotcom made something like $60 million in income from Megaupload the year before it was shut down. Some people will jump through a lot of hoops to make $60 million a year.
They get shut down for copyright infringement and immediately come back with a service touting a privacy system. Privacy from whom?
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.
I'm not so sure using encryption just to eliminate liability for themselves would go over all that well. It makes sense to me that they would lie about the purpose.
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.
Am I the only one that noticed that when the page loads, it shows an image very similar to stripe.com's cloud-with-gears image? Here are the two images overlayed on top of each other: http://i.imgur.com/pEuIbiD.png?1
Leaving aside the issues of whether they've made mistakes in their crypto, I think the more interesting point brought up by tptacek is that you can't truly trust any client-side application that gets downloaded from the server every time you go to the site. As much as Mega wants to protect your privacy, there is always the possibility that some entity forces them to trivially break your encryption by adding some javascript that uploads your private key and steals your password.
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?
You can't trust any code for which you can't review the source. Even so, you can't trust its interpreter/compiler without verifying its source and the compiler that compiled it. This includes your OS of course. One would probably also want to verify hardware level exploits too.
it is conceivable that such a system could work but it would have to rely on some kind of authenticity check on the binary/script that runs.
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.
The article is not accessible from what their system deems a mobile device (a Nexus 7 in my case), all I get is a redirect to a "dedicated mobile app coming soon" page..
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".
Whatever respect and excitement I had for Mega and Dotcom was lost when I tried visiting the link on Phone and iPad and it automatically redirected me to "An app will be launched soon for your device".
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!
I'm not sure if they were being intentionally vague on how the deduplication works, or just bad at writing, or writing for an incompetent audience. It didn't seem clear based on what they said how it works.
It looks like they know what they're doing. I was especially curious about deduplication. The way they do it sounds perfectly reasonable:
> 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.
Yes, but the first part makes no sense. If the 128-bit key is indeed chosen at random for each file (as it should be), the probability that the same key will be chosen again for a second upload of the same file is effectively zero (1/2^128).
Exactly. Read: There is no real deduplication of data. So if 1 file is reported, there's no way to track all the other copies, or automatically ban a specific file hash.
Then it's easy for law enforcement to force Mega to remove all known versions of certain copyrighted material as they can now prove that Mega are hosting copies of that particular bit of copyrighted material, .e.g.
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.
That has a good practical benefit (deduplication of files that most benefit from deduplication), but it doesn't actually solve the security problems at all, it's just choosing to make the trade off one way for large files and a different way for smaller files. If you have a legitimate reason to want privacy against data confirmation attacks then you need what you need regardless of file size.
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.
They don't seem to do that, though. Note that they claim that it's a random key and that deduplication is "much more likely" to happen when files are copied. If they would derive the key from the data in a deterministic way, they could always dedup and the previous statement (deduplication of copied files is more likely) could not be true.
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?
So it basically dedupes whatever you copy to a different folder on your own account. I guess this is the best they can do without knowing anything about the files (though not really that useful). To get true deduplication, convergent encryption is needed, which reveals more information about what you are storing (e.g. if I store the same file as you I will know what your file is)
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.