TL;DR - Mega designed their own cryptosystem. Not surprisingly, it's broken: They used CBC-MAC as a one-way hash function, but CBC-MAC is not a one-way hash function.
Maybe I am being stupendously dumb here but why didn't they just use md5? Is it that easy to compute to make it unsuitable here?
[Edit] Huge thanks to tptacek for the thorough explanation. He did make one mistake in that I was being dumber than he thought. I believed that being able to create a static file with matching hashes would be too much hassle to be worth bothering with, other replies have stated that this is not the case, hence the MAC route.
[2nd Edit] Ok, so it looks like I may not have been as dumb as I thought I was, good discussions further down.
Practical collision attacks against real systems employing MD5 have been successfully carried out in places where people thought a lack of collision-resistance wasn't a problem. Cryptography software is hard enough to implement already; Let's not make it harder by building brand new systems using weak primitives when there are better alternatives available.
I agree; it would be very difficult to do this: you would have to essentially define some padding area at the bottom of the file for random data (e.g. stored in a string) then generate data to go through all 2^64 possible hashes until you get a hit. I don't know if this is practical or not but it certainly sounds difficult.
You underappreciate what computers can do these days.
GPU password crackers run at billions/second. "The cluster can try 180 billion combinations per second against the widely used MD5 algorithm" ( http://arstechnica.com/security/2012/12/25-gpu-cluster-crack... ). That's not exactly the same task, but close enough that I'll estimate the actual performance as 100,000 faster than what you estimated.
That takes you down to 2.5 years with 25 AMD Radeon HD6990 graphics cards, which costs $1000 each. For $100,000, based on your estimate, a dedicated and well-heeled hobbyist can probably find a match in a year.
Wait a few years and that price goes down quite a bit. In a decade it will likely be a semester project at some schools.
Even if I'm off by a factor of 100, GPUs are fast enough that a mid-sized organization would be able to brute force it, should they be motivated.
This assumes that those .js files on Mega will stay the same for those 2.5 years (or semester). Much more likely is that those files will be updated somewhat regularly, and any attempt to collide a specific hash will be rendered irrelevant.
This is incorrect and doesn't apply for several reasons. It does not find collisions. It finds a pre-image (which is already known - it's the JavaScript file) for very short message lengths. Very different.
What you're describing is very different. They are searching for the shortest possible text that will result in the same hash. It's possible to generate hashes very fast because the texts are so short.
What we're talking about is not just generating some random text, but an actual JS file (that will execute malicious code that you want) with the same hash.
I don't believe that it's different. All you're looking for is the small bit of extra characters which converts the desired malicious Javascript into the target MD5.
You take your JS payload, add a terminal "#", then generate the hash information for that content. This gives the initial hash state. Now set the brute force GPUs on a mission to search for the smallest string of non-newline bytes which, which added to that hash state, gives the desired MD5 result.
A problem is that this requires 2^128 bits to brute force, not 2^64 as was mentioned earlier. I didn't catch that. 2^64 is brute-forceable. 128 isn't.
Another thing you didn't catch is the difference between MD5 and the broken Windows password algorithm.
And the fact that you still have to calculate MD5 for your WHOLE malicious javascript file, plus the comment with the random tail with all the random stuff you modify.
The link and numbers I used were in regards to MD5. I even quoted "The cluster can try 180 billion combinations per second against the widely used MD5 algorithm."
And no, you don't need to recompute the whole MD5 each time. Here's the Python code which shows that you can capture the hash state at an intermediate point:
>>> import hashlib
>>> h1 = hashlib.md5("This is the start")
>>> h2 = h1.copy(); h2.update(" # Blah!"); h2.hexdigest()
'a309b70b0bc8de4e7aad1d0ac6e14b16'
>>> h3 = h1.copy(); h3.update(" # Fnord!"); h3.hexdigest()
'a0a5979225e0ba46543856242daeab3c'
>>> hashlib.md5("This is the start # Blah!").hexdigest()
'a309b70b0bc8de4e7aad1d0ac6e14b16'
>>> hashlib.md5("This is the start # Fnord!").hexdigest()
'a0a5979225e0ba46543856242daeab3c'
You may think that perhaps the copies are keeping track of the entire string. However, this is not correct. Indeed, it would make the MD5 rather useless, because it would limit processing to available memory. How would one MD5 a multi GB file with only a small amount of RAM?
I wouldn't say its easy, but the obvious known example is the forged microsoft certificates on the Stuxnet/Flame/Gauss viruses (widely believed to be developed with nation state backing / resources).
That example does not apply here. A collision attack doesn't help. You need a second preimage attack, of which a practical one doesn't exist for MD5.
The difference is with the collision attack, the attacker controls the inputs and has to find any two valid messages with the same hash - any hash. That's what was done with forged certificates.
In this case, the hash you need to match against is fixed. You have one preimage, which is also fixed of course. You have to find a second preimage that also matches that specific hash. If you can do this at all, let alone "easily", you will significantly advance the field of cryptography.
(To raise the bar even higher, your second preimage has to be valid javascript that executes your malicious action.)
That last point isn't particularly deep; the same techniques used in http://www.win.tue.nl/hashclash/rogue-ca/ can be used for two files which are UTF-16 encoded and contains sections which are commented out.
With this said, that is a collision attack and not a preimage attack and so your first point is crucial.
While it might take some time to solve your particular problem, similar problems have been solved previously. Take a look at the hello and erase programs at http://www.mathstat.dal.ca/~selinger/md5collision/ for a nice example of constructed md5 collisions.
Are you saying that any given substring of characters will provably rule out a chunk of "hash space" for the entire message? Because that property sounds sort of interesting in itself.
No, I'm not. Also "impossible" was a bad word for me to use. It's impossible in the "not enough time before the sun burns out" sense, not in the mathematical proof sense.
I should have said impractical, but then people sometimes respond by talking about how fast GPUs are advancing, not getting just how far off they really are.
The best known attack to find a first pre-image is 2^123. To put this in perspective, using a slightly modified common analogy to describe how long 2^128 is:
"Imagine a computer that is the size of a grain of sand that can test inputs against a hash. Also imagine that it can test a hash in the amount of time it takes light to cross it. Then consider a cluster of these computers, so many that if you covered the earth with them, they would cover the whole planet to the height of 1 inch. The cluster of computers would find a valid pre-image on average in 1,000 years."
Even then, you would not have a useful preimage to mount an attack. You wouldn't even have ASCII. If you got ASCII, it wouldn't be syntactically correct javascript. If it was, it wouldn't do anything remotely malicious.
You would have to keep doing this until you randomly generated an input that happens to be valid javascript that performs your malicious action.
No. But what if I was the consultant who wrote that file and I picked it particularly because it shared the hash of one of a family of malicious auto-generated files I had already created?
That'd still be hard but much more likely.
This has implications for people who use tools like tripwire. If you didn't create the original file it might be the benign half of a set, if the details of your hashing are known to the attacker.
It's relatively easy to make collisions with MD5, and attacks like it have been documented against SSL certificates. Something like sha256 would probably be more appropriate.
MD5 by itself isn't a MAC; it's a (bad) one-way hash function. HMAC-MD5 is a MAC, like CBC-MAC; it computes an authentication tag from a key and a message, and it uses MD5 instead of AES. So I guess HMAC-MD5 is what you mean.
CBC-MAC is an unusual choice, and is known to be particularly hard to get right. Very few new systems are designed with CBC-MAC anymore.
The "industry standard" choice for a MAC in a new system is probably HMAC-SHA2; if you wanted to use a cipher core instead of a hash function for your authentication tag, you'd probably use something like OMAC (or, better, EAX mode, which does both authentication and encryption at the same time).
Long story short, you're not wrong, CBC-MAC was a weird choice.
Why would you use a MAC at all here? There is no secret. The hash comes from the "secure" server. What they needed was a plain old hash, not a (H)MAC. This is just an integrity check.
Also, MD5 isn't broken for second preimage attacks.
People like to repeat the blanket statement that MD5 is trivially broken, but in this case, it isn't. Still, it wouldn't be advisable to use here because it's broken in enough other scenarios that it makes people uncomfortable in general now. If they did use MD5, it's still a nation-state or significant crypto breakthrough before anyone could attack it.
As someone else mentioned, MD5 has been known to be broken since 1996, but I'll assume you meant something like SHA-256 or SHA3-256.
I haven't looked closely at the code, but the author of the article speculates that the code was implemented by people who are unfamiliar with cryptography. I think that's a pretty reasonable explanation. Cryptography looks deceptively simple, but it's actually a complex and specialized field that takes years to get good at. Even experts in the field routinely build cryptosystems that are later discovered to be flawed. After all, they're building roadblocks that are designed to prevent everyone---even well-funded experts from the future---from finding a clever way around. Oh, and while they're at it, they have to consider CPU and RAM constraints, too.
Many developers don't treat crypto with the respect that it demands, and, unfortunately for end-users, this is the result.
The answer is now in the article: "If the goal was, as I suspect, to use the same AES core for everything, then a Davies-Meyer construction around AES (which is about the same amount of code as the CBC-MAC is) would’ve worked too, although"
Mega has to include the lengthy JS AES code anyway and did not want to add more files just for MD5 or SHAx. By building a mac/hmac on AES they save code size
I'm not surprised. These are the same guys who thoroughly ripped apart the PS3 security system and presented it for a more-or-less general developer audience: http://www.youtube.com/watch?v=LuIlbmn-4A4
And KDC has shown he doesn't spend much on security. Definitely not enough to entice someone who is outright depressed over his current state of security.
Maybe I'm just biased after having wasted my 20s in a cube, but hanging out with KDC & his crew of henchmen doesn't sound that bad of a gig based purely on the novelty of the idea. Like it or not (and based on your posts, I know which one it is), KDC has shown some insight into how to make cash on the ol' internets... I suppose you have an argument with his ethics? Try working on a bond trading desk for 10 years. You'll see KDC as Christ-like pretty soon thereafter.
A lot of it comes down to recognizing the right tools for the job, and writing-from-scratch absolutely as few of those tools as necessary. Even very good practical crypto users can make mistakes... although in this case, Mega has used the plastic end of a screwdriver to pound nails.
For example I use code that does crypto everyday, probably everyone on the internet does.
Web frameworks , operating systems , browsers etc all use crypto and presumably that stuff is written by some mythical person who can do this stuff properly judging by the fact that my credit card hasn't been frauded yet..
Pretty much every crypto library you use was badly broken, multiple times, during its long history. New attacks are still being found, and browsers and libraries are updated as we learn more.
The first rule of crypto is not to write crypto code. Reuse a high level library that already made all the mistakes you're about to. If you absolutely have to break the first rule, you need to budget between 5 and 6 digits for experts to review it against known attacks and best practices.
No, you don't have to go that far. The same libraries used by those companies are available to all projects, and most crypto uses them (or libraries built on top of them). Mistakes such as those made by Mega result from using a crypto library that makes the author do all the work.
Interesting question but part of them problem is like this:
Crypto Guy 1: That system would take about three weeks to implement.
Crypto Guy 2: That system would take about three months to implement.
Who do you hire? You have a number of scenarios. 1 could have a set of tools that are trusted and he has experience and knows exactly. And 2 doesn't have a clue and needs a month to get up on speed with crypto code. But the reverse scenario is applicable as well. You can't be sure if guy 1 is just a fast coder that hacks together some algorithms from various sources and 2 knows exactly what is needed to from his crypto toolbelt giving you a bigger estimate from experience.
So you can steal the encryption keys from the browser. What a surprise.
I don't think anyone at Mega gives a damn though, or the people who are going to use it to upload movies. The only reason there's an encryption key at all is to cover their asses on future lawsuits, not to make Mega amazingly secure.
This is what I think is the speculation. Let us speculate you wanted to build a "legitimate" Pirate Bay type system, what would you have to do in order to pass the 'sniff test' for litigators while providing an otherwise easy to use service?
I am not in any way at all suggesting that Mega is doing this, or that they are even trying to do this. I am simply observing that there is an interesting case to be made where you can swear under oath you did you best to make the site secure, and yet people more sophisticated than you broke into it and had their way with you. How much liability does that protect you from? Any? All? I haven't got a clue here but I find the question an interesting one. Perhaps Eric Goldman will chime in.
Stopping your digital locker online service from being used for mass copyright infringing material is easy. Go ahead and host a movie on dropbox and share a public link on a popular site. See how long it stays valid.
A normal system admin might decide a single 4gb file accounting for tens of terabytes of traffic is unusual and investigate the cause. Odds are pretty decent you'll be able to find a source driving all the traffic.
Kim Dotcom is going for the blind eye approach. Just close your eyes and cover your ears so it's not your fault. He did this with MegaUpload to the tune of hundreds of millions of dollars of profit. I wonder if the new site will reward users who have highly downloaded files like his last?
Can you prove, or disprove, that the cryptography was intentional broken? Doubtful. Can you prove a website didn't try to prevent the mass sharing of copyrighted material? Yes. Is that illegal? Maybe. Should it be? That's whole 'nother can of worms.
Dropbox doesnt have copyright checking last I checked. The way that they deal with the problem is by bandwidth limiting public urls. You would have the same effect with a video that you legally publish as with an infringing video.
Popularity is not proof of illegal activity. It seems implied that only restricted copyrighted information may bring high traffic, but that's not true. One of the highest traffic torrents I ever had, and which got the computer club network cut off from the university because it was "suspiciously uploading high amount of data" was in fact a linux live cd... It was also a highly effective way to test out the new server's hardware :).
Of course it's implied because > 99% of high traffic volume files on Mega are going to be copyrighted material. To suggest otherwise would be insane. Is high traffic proof of anything? Of course not. Is it reason to investigate? Absolutely, unless your stated mission is to cover your eyes singing "lalalalalala".
Kim Dotcom has already made hundreds of millions of dollars off copyrighted material and he's trying to do it again. I'd say the fact that anyone supports his antics is bewildering but the power of selfishness knows no bounds.
Investigation takes time, effort and money. Its why the police is a group of people being paid to do that work. No one expect the police force to be made out of voluntaries. Why do then suddenly people expect system administrators to do police work for free?
How common is it that people go to the local police station in an afternoon and offered to do some work with no expectation of some kind of salary?
System administrators are not people that work for free. They expect to get paid like everyone else. They also expect to be able to decide what work they accept, and which ones they do not (ie, they are not slaves). Some do investigations for the police without getting any payment because they feel they want to perform some civil duty to do so, but the above comment imply that they must do so. That is wrong. System administrators should not be forced labor for the police.
If there is investigation to do, call the police, pay your taxes (so the police get paid), and let the system work as intended without putting forced labor onto the system administrators of the world. If you dislike a service because its used by criminals (like say, gmail which is abused by spammers), it still the police you should call and not the system administrators.
>99% of high traffic volume files on Mega are going to be copyrighted material.
This is a completely baseless assertion with no facts to back it up. (Difficulty: Pointing to a dodgy DoJ case does not count as "facts")
Attemping to shift the burden of proof by saying "to suggest otherwise would be insane" is not appreciated or necessary.
Futhermore, it's a useless assertion too, since pretty much everything is copyrighted. Whether it's authorized is another matter and not near as easy to figure out from a service provider standpoint. Neither is it their job.
So you're one of the people that buys into the whole "It's easy to tell what files are legally shared" and it's just not true. Which is proven time and time again when publishing companies send DMCA takedown requests for the content another department in their company published intentionally.
Almost everything is covered by copyright, it's indeed not too hard to figure out if something is covered by copyright. It's much harder to figure out who owns the copyright on something, and it's almost impossible to figure out if a certain file is authorized by the copyright owner.
Just because a file is popular doesn't mean it's infringing. Can you guarantee this popular file wasn't posted on twitter by the artist for a marketing campaign? Can you guarantee the artist didn't upload it to a torrent site to get attention? No, you can't. You'll just take a flamethrower approach and many legitimate files will be removed in the process.
I took for granted that most ingringement policy is done locating the links in forums, checking if they really point to copyrighted content, then requesting the file locker to remove the file.
Actually I can't see how encryption could change this procedure. It seems a technical solution applied to a social problem.
You can't take for granted that anyone actually checks the file contents. I'm pretty sure the laser printers that got sent takedown notices weren't actually sharing any content.
I didn't mean that every denounce comes from content inspection, just that this is the most common case and that encryption couldn't stop it: if it's public, someone can inspect it.
Are the cloud providers (dropbox in this case) even allowed to look at the contents of your files?
I guess this would be up to the TOS for each site but the few sites i've actually read at least pretend that they value your privacy.
Also remember the shitstorm after 37signals announced that the millionth file ever uploaded to basecamp was an image of a cat? The official story after all complaints was that they never opened the file but they still "knew" because the filename in the logs showed up as cat.jpg.
> Are the cloud providers (dropbox in this case) even allowed to look at the contents of your files?
DMCA safe harbor means the hosting provider should not have editorial control. If you have editorial control, you're open to liability for not exercising that control. Better to go the legally proven route of getting a credit card and an adult signature, to keep all the liability on the user.
What I got from this is that the code is intended to be set up so you don't have to trust the CDN, however due to an error in the way it's coded, it turns out you do have to trust the CDN. Given that CDNs are reasonably trustworthy in the absence of government intervention, I expect that Mega will fix this before there are any exploits.
It's good work by fail0verflow, but as long as Mega addresses it soon, I don't think it's a big deal. In fact, it's a good test case for how seriously they take this kind of problem.
It seems we've established (very thoroughly) that Mega should not be trusted to keep our files secure.
But that's not the point of their crypto; it's just an effort to ensure plausible deniability that happens to be a marketable feature.
If your objective is to stash sensitive files, there are plenty of established options.
It's obvious that Mega was not intended to serve such a purpose, so the criticism strikes me as pointless except for its instructional/entertainment value.
Tarsnap is simply the best. Spideroak is probably okay. But if you have files that absolutely must remain confidential (e.g. NDA'd source code, etc) then Tarsnap is the service that can be trusted to store them correctly.
Kim Dotcom - piece of shit who makes money on the back of the scene, gets raided for (knowingly) doing so.
Somehow the combination of Kim being a piece of shit (whom no one would want to work for) and the very real possibility of the US Government going after anyone having anything to do with MegaUpload V2 resulted in the new product not being very secure/good. What a surprise.
Maybe the fact SOME programmers even work the Zetas. Unless, that is, you don't consider "copyright piracy" worse than drug trafficing the way the Zetas do...
I find this doubtful. At worst, you can find persons to "consult" to do the job properly, and they can move on to other projects post-launch.
Perhaps his negative reputation preceded him, but that was earned long before the US government's involvement with Megaupload. Heck, I hadn't seen anyone express sympathy for his operations ~until~ the US crackdown.
Youtube has a legitimate use. Megaupload was designed to be used to host pirated content, and for Kim Dotcom to make money off it. I, along with the rest of the scene, am/are insulted by this abuse of the content we released.
Read the US Government's case. It's pretty clearly laid out. Megaupload employees were even sharing links to user-uploaded pirated content hosted on their servers.
Those who release pirated content in a particular way. All non-p2p warez groups.
There is no judgement on this case yet. As far as I know people are still considered inocent until they are judged guilty. And that is without going into all the shit that went on during the Megaupload story.
Are you insulted by Google's funneling of revenue through Bermuda, so they pay only a tiny fraction of the taxes they otherwise would? I'm more insulted by that than what Dotcom does.
Google is “flying a banner of doing no evil, and then they’re perpetrating evil under our noses,” said Abraham J. Briloff, a professor emeritus of accounting at Baruch College in New York who has examined Google’s tax disclosures.
Acting like the entire warez scene exists for the greater good and isn't profit driven is ridiculous. Yeah, there's honest people in it just for the fun of cracking and such, but there's also plenty of siteops selling leech and taking "donations" of hardware in return for leech credits. How do you think the major private torrent sites get their releases so fast nowadays? Releases used to spread onto public sites much slower.
At least Dotcom's service wasn't used /solely/ for piracy... you can attack his intentions all you want but the service itself was not illegal.
Irony meter explosion aside, I still pretty regularly run into entirely legitimate broken links to Megaupload from people just using it as an host for their own stuff.
I don't see any normal (Dropbox, etc) cloud storage companies being designed to make hosting pirated content easy and lucrative for them. Believe it or not, most people want to make an honest living.
Dotcom is seen as criminal only because he isn't rich enough to make the rules, unlike the Fortune 100. Two wrongs don't make a right but neither should a double standard be applied to him.
SJCL, which Mega appears to be using, includes SHA2. They could have used SHA2 if they needed a secure hash function. SJCL also includes HMAC; they could have used HMAC-SHA2 if they really needed a MAC. CBC-MAC was a bizarre choice.
(I'm trying to address the general questions, like "why would I use or not use CBC-MAC", without getting into the general craziness of Mega's design or the idea of doing crypto in browser Javascript.)
I'm surprised you're entertaining the idea. (Edit: Sorry. I misread. I was only hoping to learn something new.)
It seems like at a minimum users would need to disable all browser extensions before uploading their content. That doesn't seem realistic, so browser-based crypto seems dubious.
I'm not entertaining the idea! I'm not interested in picking apart Mega, but I am interested in how people choose crypto primitives and what libraries they have available to them.
The problem is multifaceted; first, JS crypto is slow in most current implementations (but will get better with Typed Arrays). Second and more importantly, it is difficult to ensure total security on a page. While loading all assets from a single server using SSL helps quite a bit, there's really nothing stopping a malicious extension from getting in the way and stealing your passwords.
Of course that's true of any website in general so the lesson is: be careful what extensions you install.
Third, browser support is still garbage. Safari has major issues, Firefox is lacking support in critical places, and IE, don't bother.
However the future is bright. With Typed Arrays & Web Workers running on all threads, you can expect 10+MB/s crypto in-browser very soon. That's slow by any other standard but potentially good enough for a browser. Hell, I'm pushing about 3.5MB/s on a MBA on securesha.re, which does 128-bit AES.
Just for disclosure, I wrote securesha.re (and succumbed to a few of these problems while writing it).
I don't know. I do know that other dynamic languages are trusted to perform crypto (e.g. Python). The fact that any dynamic language is trusted leads me to believe JS as a language may be fine.
or with certain JS runtimes?
Yes, each runtime must be analyzed by a crypto expert to uncover e.g. timing attack vulnerabilities, etc.
or with just the idea of running a program inside a web browser to do crypto?
Yes, implementing crypto within a webpage is a bad idea for many reasons. The first is that you must ultimately trust the browser itself, as well as its updater program. Second, you must trust every browser extension, since any extension can arbitrarily modify the page, and hence the javascript. (e.g. Reddit Enhancement Suite does this.) Since every extension can be updated at any time, you can't really trust any extension. Third, the javascript can be compromised in many other ways (e.g. XSS attack, etc). Fourth, crypto itself is extremely difficult to implement correctly, and it's easy to trick yourself into adding flaws while implementing it.
For these and other reasons, browser-based crypto can't ever be trusted. Not yet, and not until the above concerns are no longer relevant.
When Python performs crypto operations, it isn't doing that while running alongside potentially hostile content-controlled code.
The first thing everyone thinks when they read about browser JS being a hostile environment for crypto is, "LANGUAGE WAR!" But this issue has nothing at all to do with languages. If Python was the de-facto standard content-controlled browser programming language, we'd be saying "don't do crypto in browser Python".
The question was "Can the design of any programming language ever affect the security of crypto code implemented correctly within it?"
This question is extremely broad, and it requires envisioning future languages which haven't been invented yet, and looking for ways the design of the language itself might impact the security of crypto code implemented within it.
That said, the question isn't the most important one. It was his third question which you and I both responded to.
More fundamentally then the reasons others have already stated is that the JavaScript is loaded from a server anyway. So you trust the server anyway, and hence may as well just do the encryption on the server.
Yes. This is also why assurances that XSS bugs have been fixed aren't comforting. The problem isn't simply that attackers will find ways to corrupt the JS crypto code; the problem is that it is extremely difficult for end-users to verify that the crypto code they're running isn't bugged.
Basically, they use CBC-MAC to verify the integrity of their script sources. This is pretty bad because a MAC is not resistant to collisions, and given the original key, it's trivial to generate alternate data that gives the same output. A better approach would be an HMAC, using something like SHA1. Doing so makes it much more difficult to perform this type of attack.
I always encrypt any data sent to 'arbitary hosting' using GnuPG and recipients public keys. Has been working well so far. I'm also eagerly waiting for ECC version to go mainstream. My current signing key is 1024DSA key which is known to be weak. File lockers are nice service, you just need to secure any private data.
So it's fatally broken. But everyone's ignoring Mega's upside: you get to send your sensitive data and money to a charismatic, egomaniacal scam artist!
i doubt anyone is seriously thinking of putting their sensitive data into mega. More than likely, it is going to be a storage medium for music, movies and/or pictures.
What can't "music, movies and/or pictures" be sensitive? People used Megaupload to, for example, exchange video and music for works which hadn't yet been released, and for personal images which would never be released.
Or you encrypt the data yourself first (so that even the browser doesn't see your sensitive data), that way it's a free and probably unreliable (in the long term) 50GB storage facility.
I might just use it as an extra backup repository.
So Mega uses SSL ( RSA 2048) to deliver code that checks if additional resources delivered by SSL (RSA 1024) are identical to the original ones. However they have a flaw in the authentication that checks these resources such that their security can now be broken by breaking the weaker SSL connection. But given the problems with certificates, there are scenarios were breaking SSL, irrespective of the encription used, is not a problem ( if you can install CAs at the target.)
I am actually somewhat surprised that the known problems of Mega are so few. I would have expected that their crypto is more broken than this.
From what I understand the risk is not so much that somebody breaks the 1024 bit SSL. It is that the Javascript code (presumably including security critical stuff) is loaded from a third party CDN network.
So by nature a CDN network is going to comprise many servers in different locations. Therefor if somebody pwns one of those servers it is risky for anybody who downloads the JS code from that particular CDN server.
I was under the impression that even a 128 bit keyspace is prohibitively hard to crack using modern hardware, and that 256 bit would take more computational resources than we can reasonably expect to have available to us for the rest of time. Isn't 1024 bit a bit overkill?
RSA can be cracked by breaking the public key down into it's prime factors to discover the private key. AES is much more expensive per "try" because the algorithm itself includes many more steps to do a decryption even with the correct key.
Not the most detailed answer I grant you, but I don't understand all of the math involved.
When you see "256 bit" used in the context of SSL, this is referring to the block cypher used in the actual transmission rather than the RSA key size.
So an SSL implementation will probably use a 2048 bit RSA key and a 256 bit AES key. RSA is used to swap the shared secret which is used as the key to the main AES tranfer.
The 128 bit strong key is applicable for symmetric key encryption (e.g. AES, Blowfish etc.). However, even 2048 bit keys are considered relatively insecure for asymmetric key encryption (e.g. RSA).
For AES you have to search the entire keyspace, but for RSA ( and AFAIK any public key scheme) you can actually calculate the private key. The security of public key cryptography relies therefore on one-way functions, which are easy to calculate in one direction but very hard to calculate in the other direction. ( This is used to generate the public and private keys together, but the inverse operation, breaking the encryption, should be prohibitively hard to calculate in practice.) Because of this you can not really compare key length between symmetric and asymmetric encryption schemes.
Kim Dotcom and those in the Mega posse know the encryption they are claiming is mega secure is in fact a mega lie. We all know it, but does it actually matter? The whole point of the encryption wasn't so you can upload files without fear of them being looked at by staff, it's to prevent Mega from being taken down by the US government again by claiming they truly can't see the file contents of their server.
The encryption, it is a lie but at the end of the day it shouldn't detract from the fact that Mega is a decent cloud hosting platform with decent ideas. Compare Mega to offerings from Mediafire, Dropbox and insert other cloud file storage provider here and Mega is quite compelling considering the free 50gb of space you get.
I don't think it's a sustainable business, that's why, unless users will get fucked in the long run, one way or the other.
Startups these days and even bigger companies like Google, got into the habit of creating something and giving it away for free or for cheap, then when it gets popular they either raise their prices, pull the plug or sell your data, fucking the same users that made them popular in the process and frankly I'm tired of that.
Right now I'm a Dropbox paying customer and decided against GDrive for instance, even though GDrive is cheaper and even though I was and am already a heavy Google Apps user. I went with Dropbox because they value me enough to provide a Linux client and I simply don't trust Google's pricing anymore, considering their recent history.
So even though I do use free services right now, for new services and products if it ain't open-source, if it isn't backed by a non-profit and if it doesn't have a decent price tag, then I'm not touching it.
I don't think it is fair to dismiss it as a "mega lie". I am actually surprised, how thought out the encryption scheme is. The first version might have flaws, but at least they thought about the case that the CDN might be compromised and implemented a quite clever (but flawed) work-around. Most banks don't put such an effort into security of their website.
Maybe not a lie in the sense of the word, but it's obvious looking at their crypto algorithm that at present it is a gimmicky feature. The lack of a strong encryption scheme doesn't degrade the service in my opinion and it's more of a feature to protect Mega and not its users like they are portraying it to be.
Given the massive amount of backlash and scrutiny from experts and non-experts alike, Kim always seems to win in the end and I am sure they're already planning on hiring a cryptography master to help them write something more serious as we speak.
They have an API where you can write your own client, if you don't want to use the JS client. This doesn't solve every security problem, but at least this one.
I think that they have really tried to make it secure, but they aren't just competent enough. Browser-crypto is always somewhat insecure especially when they actually store your keys and you have to trust them.
Simple question: the flaws that are being pointed out are not fundamental flaws, but rather poor choice of a way to accomplish the goal; therefore, I ask, is there anything in the idea itself that is flawed?
TBMS, if the scheme were as follows: user downloads index.html over 4098-bit SSL (assuming that you trust the CA). index.html contains SHA2 hashes of all the remaining resources to be downloaded and compares the hashes of downloaded resources from completely untrusted servers to the ones that it already has and thusly decides to continue if the hashes are correct. Is there anything fundamentally flawed with this system or is javascript cryptography = bad just an overgeneralization?
Yes, the flaws pointed out are easily fixed. Mega will probably have a fixed version uploaded later today as the fix should be about 15 minutes of work. The good part about javascript cryptography is also the bad part - if any changes need to be made, they can be instantly pushed out to all clients and the clients are upgraded at the next page view.
Of course, this leaves open the main problem people have with javascript cryptography - at any point, Mega can change their javascript to no longer be secure. This means you can't actually trust that your data is secure from Mega - but then, I very much doubt anybody trusted this to start with?
It's the same thing as when I sign into my bank using my browser. My bank could at any time change their website to read in my account number and password, and then email this password to China, along with all my bank statements. I have to trust that my bank will not do this every time I use them. I also have to trust that the policeman I walked past earlier today would not shoot me with his handgun. You have to trust at some point.
I totally agree with half of your comment, Mega will fix all these glitches and the service will be better (eventually).
I'm not sure about the trust part. Both your bank and the policeman have are committed to follow strict regulation, and have something to lose if they fail to do so.
There's a trust factor too, but I don't think Mega has the reinforcement of regulation or the consequences if they don't deliver what they promise.
But the entire point of client-side encryption is to avoid having to trust a server. If you have to trust the server, then there's no reason to do the client-side encryption at all. It's just overhead at that point.
Agree completely if the goal was to provide encrypted storage. However, as noted in other comments, this isn't actually the goal. The goal is to create a plausible legal defense against legal threats from the RIAA and similar.
If the encryption is done on the server side, Mega can legally be required to make a log of all copyrighted works uploaded to their servers and be liable for distribution. If the file is encrypted before it is uploaded, then Mega cannot physically store a log of copyrighted works. This is pretty major as take-down requests can then only be sent for a single upload. The most that could be done is for a court to publicly order Mega to cease and desist, at which point everyone can move on with no legal liability.
This is a piracy platform, not a genuine secure storage. It's fairly clever.
Sidenote regarding comment below:
I live in Africa, I'm not sure who I trust less out of my bank, the police, or Mega. Probably not Mega!
No, client-side encryption makes sense even if you have to trust the server. When Mega's server gets compromised, the attackers cannot get a user's private keys until he visits Mega's site. Without client-side encryption, attackers could get all the user's keys and thus all their data immediately.
> If you have to trust the server, then there's no reason to do the client-side encryption at all. It's just overhead at that point.
Think of it as bootstrapping. If they released a service you couldn't use from a browser, probably nobody would use it. But if they release one, even if it isn't as secure as it ought to be, and get millions of users, then someone will write a browser plug in that makes it so you don't have to trust the javascript anymore, and anyone who needs better security will use that. At that point the javascript is irrelevant because no one who needs better security is (or should be) relying on it, but first you have to get to that point. What the javascript becomes is a gateway into the service for people who don't need security and just want to take advantage of 50GB free storage, or who interact with people who have a different threat model.
For example, here's a use case: You're a whistleblower. You want to distribute something to the world and you can't allow anyone to know who you are. So you don't use the javascript, you use an open source native client, and you make your upload using TOR or pick your favorite anonymizer. Then Mega has an encrypted copy of what you want to publish, they have no idea what it is. Now all you have to do is post the link and password to a public forum (again using an anonymizer, and possibly from a different country from where you made the upload) so that by the time any third party can even know what it is that you've uploaded, it's available to the world and you're in a safe place. Meanwhile none of the downloaders who don't need protection from anyone has to install any special software because they can use the javascript.
Simple question: if JavaScript in the browser cannot be used to encrypt data --as seems to be the consensus here in this thread--, doesn't it severely limit the usefulness of JavaScript client side? I mean, what can then be JavaScript client-side be used for?
Should (could?) SSL have been used to send data "in the clear but encrypted" (including the password to encrypte/decrypt the data) to Mega's servers and then encrypted server-side?
This would allow mega to implement a copyright protection scheme since their servers get to handle the data in clear text and could perform matching. If the encryption happens client-side they can't.
The wonderful thing about the ridiculous level of Mega publicity combined with the availability of code is that Mega are getting this sort of excellent feedback.
I for one am not going to judge them too harshly if they keep listening and responding, as the product will just keep getting better. Sure they are blessed with I guess several million customers a few days after launch, but many here have also been through early product issues, albeit with far fewer customers. Like Mega, we learn and move on by fixing the problems.
I guess Mega appreciate the value of this sort of feedback, and the attendant publicity.
Edit: and just after publishing this, a tweet from Dotcom:
"We welcome the ongoing #Mega security debate & will offer a cash prize encryption challenge soon. Let's see what you got ;-)"
I agree, the big hype is paying off for them because many people looking into their code for free just to show how wrong they are but at the end they can fix these and then the criticism will not be true anymore. After the community "fixed" their front-end code they should open source the back-end too so they can get feedback on that too. After that the only thing that users should trust is that they will not alter the fixed codes.
I guess it is the right time for such a review of how they work as they are on an early stage of deployment. They will benefit greatly security-wise from it.
For users who truly care about their data, the review should have been done before launch.
But Mega isn't a site for governments or enterprises, it's for day-to-day users and file sharers. So I can't be too upset they decided to half-ass it and let the public fix their code.
For CDN scenarios it would be nice if I could include a secure checksum (SHA256) for the script in the script tag and then browser would verify it before executing the script.
If we take the position that CDNs are not to be trusted, how many other high profile sites would be rendered vulnerable? I assume quite many are nowadays using CDNs to distribute part of their scripts.
Wouldn't it be quite easy to for example to steal users Dropbox passwords if one could modify some of the scripts they use on the frontpage and which are delivered via Cloudfront?
Just for the interest of all those worried about RSA 1024 bit keys being unsafe. From my system's (OS X) certificates:
[Thawte Premium Server CA: 1024 bits, valid until 2021]...
[Thawte Server CA: 1024 bits, valid until 2021]...
[http://www.valicert.com/: 1024 bits, valid until 2019]
And some others I am not including...
CALM down with 1024 bits please as of 2013.
(Notice that those come included in the OS)
Edit: this is not an authority argument (I am perfectly calm with 1024bits without OS X's assurance). I am only asking those people complaining about 1024bit keys to remove those certificates from their systems...
206 comments
[ 3.1 ms ] story [ 247 ms ] thread[Edit] Huge thanks to tptacek for the thorough explanation. He did make one mistake in that I was being dumber than he thought. I believed that being able to create a static file with matching hashes would be too much hassle to be worth bothering with, other replies have stated that this is not the case, hence the MAC route.
[2nd Edit] Ok, so it looks like I may not have been as dumb as I thought I was, good discussions further down.
Can you generate a JS file (that will actually execute) with the same MD5 as
MD5 is 7ecf458bad499f6815cbc10ed597dd3aGPU password crackers run at billions/second. "The cluster can try 180 billion combinations per second against the widely used MD5 algorithm" ( http://arstechnica.com/security/2012/12/25-gpu-cluster-crack... ). That's not exactly the same task, but close enough that I'll estimate the actual performance as 100,000 faster than what you estimated.
That takes you down to 2.5 years with 25 AMD Radeon HD6990 graphics cards, which costs $1000 each. For $100,000, based on your estimate, a dedicated and well-heeled hobbyist can probably find a match in a year.
Wait a few years and that price goes down quite a bit. In a decade it will likely be a semester project at some schools.
Even if I'm off by a factor of 100, GPUs are fast enough that a mid-sized organization would be able to brute force it, should they be motivated.
What we're talking about is not just generating some random text, but an actual JS file (that will execute malicious code that you want) with the same hash.
You take your JS payload, add a terminal "#", then generate the hash information for that content. This gives the initial hash state. Now set the brute force GPUs on a mission to search for the smallest string of non-newline bytes which, which added to that hash state, gives the desired MD5 result.
A problem is that this requires 2^128 bits to brute force, not 2^64 as was mentioned earlier. I didn't catch that. 2^64 is brute-forceable. 128 isn't.
And the fact that you still have to calculate MD5 for your WHOLE malicious javascript file, plus the comment with the random tail with all the random stuff you modify.
And no, you don't need to recompute the whole MD5 each time. Here's the Python code which shows that you can capture the hash state at an intermediate point:
You may think that perhaps the copies are keeping track of the entire string. However, this is not correct. Indeed, it would make the MD5 rather useless, because it would limit processing to available memory. How would one MD5 a multi GB file with only a small amount of RAM?edit: I don't know what I'm talking about :)
The difference is with the collision attack, the attacker controls the inputs and has to find any two valid messages with the same hash - any hash. That's what was done with forged certificates.
In this case, the hash you need to match against is fixed. You have one preimage, which is also fixed of course. You have to find a second preimage that also matches that specific hash. If you can do this at all, let alone "easily", you will significantly advance the field of cryptography.
(To raise the bar even higher, your second preimage has to be valid javascript that executes your malicious action.)
With this said, that is a collision attack and not a preimage attack and so your first point is crucial.
sure its not trivial, but not impossible.
I should have said impractical, but then people sometimes respond by talking about how fast GPUs are advancing, not getting just how far off they really are.
The best known attack to find a first pre-image is 2^123. To put this in perspective, using a slightly modified common analogy to describe how long 2^128 is:
"Imagine a computer that is the size of a grain of sand that can test inputs against a hash. Also imagine that it can test a hash in the amount of time it takes light to cross it. Then consider a cluster of these computers, so many that if you covered the earth with them, they would cover the whole planet to the height of 1 inch. The cluster of computers would find a valid pre-image on average in 1,000 years."
Even then, you would not have a useful preimage to mount an attack. You wouldn't even have ASCII. If you got ASCII, it wouldn't be syntactically correct javascript. If it was, it wouldn't do anything remotely malicious.
You would have to keep doing this until you randomly generated an input that happens to be valid javascript that performs your malicious action.
So, I rounded up to impossible.
That'd still be hard but much more likely.
This has implications for people who use tools like tripwire. If you didn't create the original file it might be the benign half of a set, if the details of your hashing are known to the attacker.
CBC-MAC is an unusual choice, and is known to be particularly hard to get right. Very few new systems are designed with CBC-MAC anymore.
The "industry standard" choice for a MAC in a new system is probably HMAC-SHA2; if you wanted to use a cipher core instead of a hash function for your authentication tag, you'd probably use something like OMAC (or, better, EAX mode, which does both authentication and encryption at the same time).
Long story short, you're not wrong, CBC-MAC was a weird choice.
Also, MD5 isn't broken for second preimage attacks.
People like to repeat the blanket statement that MD5 is trivially broken, but in this case, it isn't. Still, it wouldn't be advisable to use here because it's broken in enough other scenarios that it makes people uncomfortable in general now. If they did use MD5, it's still a nation-state or significant crypto breakthrough before anyone could attack it.
I haven't looked closely at the code, but the author of the article speculates that the code was implemented by people who are unfamiliar with cryptography. I think that's a pretty reasonable explanation. Cryptography looks deceptively simple, but it's actually a complex and specialized field that takes years to get good at. Even experts in the field routinely build cryptosystems that are later discovered to be flawed. After all, they're building roadblocks that are designed to prevent everyone---even well-funded experts from the future---from finding a clever way around. Oh, and while they're at it, they have to consider CPU and RAM constraints, too.
Many developers don't treat crypto with the respect that it demands, and, unfortunately for end-users, this is the result.
Mega has to include the lengthy JS AES code anyway and did not want to add more files just for MD5 or SHAx. By building a mac/hmac on AES they save code size
Then you actually wrote the proof of concept and proved it to be a very real problem.
Nice work. Also the mouseover on your site title is sexy.
A lot of it comes down to recognizing the right tools for the job, and writing-from-scratch absolutely as few of those tools as necessary. Even very good practical crypto users can make mistakes... although in this case, Mega has used the plastic end of a screwdriver to pound nails.
For example I use code that does crypto everyday, probably everyone on the internet does.
Web frameworks , operating systems , browsers etc all use crypto and presumably that stuff is written by some mythical person who can do this stuff properly judging by the fact that my credit card hasn't been frauded yet..
For a small sample, read the wikipedia page for http://en.wikipedia.org/wiki/Secure_Sockets_Layer and take a look at how many times we all got that wrong.
The first rule of crypto is not to write crypto code. Reuse a high level library that already made all the mistakes you're about to. If you absolutely have to break the first rule, you need to budget between 5 and 6 digits for experts to review it against known attacks and best practices.
Crypto Guy 1: That system would take about three weeks to implement. Crypto Guy 2: That system would take about three months to implement.
Who do you hire? You have a number of scenarios. 1 could have a set of tools that are trusted and he has experience and knows exactly. And 2 doesn't have a clue and needs a month to get up on speed with crypto code. But the reverse scenario is applicable as well. You can't be sure if guy 1 is just a fast coder that hacks together some algorithms from various sources and 2 knows exactly what is needed to from his crypto toolbelt giving you a bigger estimate from experience.
Oh and once set, you can't change any password or delete your account.
http://arstechnica.com/security/2013/01/cracking-tool-milks-...
I don't think anyone at Mega gives a damn though, or the people who are going to use it to upload movies. The only reason there's an encryption key at all is to cover their asses on future lawsuits, not to make Mega amazingly secure.
I am not in any way at all suggesting that Mega is doing this, or that they are even trying to do this. I am simply observing that there is an interesting case to be made where you can swear under oath you did you best to make the site secure, and yet people more sophisticated than you broke into it and had their way with you. How much liability does that protect you from? Any? All? I haven't got a clue here but I find the question an interesting one. Perhaps Eric Goldman will chime in.
A normal system admin might decide a single 4gb file accounting for tens of terabytes of traffic is unusual and investigate the cause. Odds are pretty decent you'll be able to find a source driving all the traffic.
Kim Dotcom is going for the blind eye approach. Just close your eyes and cover your ears so it's not your fault. He did this with MegaUpload to the tune of hundreds of millions of dollars of profit. I wonder if the new site will reward users who have highly downloaded files like his last?
Can you prove, or disprove, that the cryptography was intentional broken? Doubtful. Can you prove a website didn't try to prevent the mass sharing of copyrighted material? Yes. Is that illegal? Maybe. Should it be? That's whole 'nother can of worms.
Kim Dotcom has already made hundreds of millions of dollars off copyrighted material and he's trying to do it again. I'd say the fact that anyone supports his antics is bewildering but the power of selfishness knows no bounds.
How common is it that people go to the local police station in an afternoon and offered to do some work with no expectation of some kind of salary?
System administrators are not people that work for free. They expect to get paid like everyone else. They also expect to be able to decide what work they accept, and which ones they do not (ie, they are not slaves). Some do investigations for the police without getting any payment because they feel they want to perform some civil duty to do so, but the above comment imply that they must do so. That is wrong. System administrators should not be forced labor for the police.
If there is investigation to do, call the police, pay your taxes (so the police get paid), and let the system work as intended without putting forced labor onto the system administrators of the world. If you dislike a service because its used by criminals (like say, gmail which is abused by spammers), it still the police you should call and not the system administrators.
This is a completely baseless assertion with no facts to back it up. (Difficulty: Pointing to a dodgy DoJ case does not count as "facts")
Attemping to shift the burden of proof by saying "to suggest otherwise would be insane" is not appreciated or necessary.
Futhermore, it's a useless assertion too, since pretty much everything is copyrighted. Whether it's authorized is another matter and not near as easy to figure out from a service provider standpoint. Neither is it their job.
Almost everything is covered by copyright, it's indeed not too hard to figure out if something is covered by copyright. It's much harder to figure out who owns the copyright on something, and it's almost impossible to figure out if a certain file is authorized by the copyright owner.
Just because a file is popular doesn't mean it's infringing. Can you guarantee this popular file wasn't posted on twitter by the artist for a marketing campaign? Can you guarantee the artist didn't upload it to a torrent site to get attention? No, you can't. You'll just take a flamethrower approach and many legitimate files will be removed in the process.
Actually I can't see how encryption could change this procedure. It seems a technical solution applied to a social problem.
I guess this would be up to the TOS for each site but the few sites i've actually read at least pretend that they value your privacy.
Also remember the shitstorm after 37signals announced that the millionth file ever uploaded to basecamp was an image of a cat? The official story after all complaints was that they never opened the file but they still "knew" because the filename in the logs showed up as cat.jpg.
DMCA safe harbor means the hosting provider should not have editorial control. If you have editorial control, you're open to liability for not exercising that control. Better to go the legally proven route of getting a credit card and an adult signature, to keep all the liability on the user.
It's good work by fail0verflow, but as long as Mega addresses it soon, I don't think it's a big deal. In fact, it's a good test case for how seriously they take this kind of problem.
But that's not the point of their crypto; it's just an effort to ensure plausible deniability that happens to be a marketable feature.
If your objective is to stash sensitive files, there are plenty of established options.
It's obvious that Mega was not intended to serve such a purpose, so the criticism strikes me as pointless except for its instructional/entertainment value.
In case anyone is looking for an option, I recommend Tarsnap. http://www.tarsnap.com
Tarsnap is simply the best. Spideroak is probably okay. But if you have files that absolutely must remain confidential (e.g. NDA'd source code, etc) then Tarsnap is the service that can be trusted to store them correctly.
Somehow the combination of Kim being a piece of shit (whom no one would want to work for) and the very real possibility of the US Government going after anyone having anything to do with MegaUpload V2 resulted in the new product not being very secure/good. What a surprise.
Perhaps his negative reputation preceded him, but that was earned long before the US government's involvement with Megaupload. Heck, I hadn't seen anyone express sympathy for his operations ~until~ the US crackdown.
Does this make anyone who works for Google a "piece of shit"?
You got any evidence?
>I, along with the rest of the scene, am/are insulted by this abuse...
Who is the "rest of the scene"?
Those who release pirated content in a particular way. All non-p2p warez groups.
Google is “flying a banner of doing no evil, and then they’re perpetrating evil under our noses,” said Abraham J. Briloff, a professor emeritus of accounting at Baruch College in New York who has examined Google’s tax disclosures.
At least Dotcom's service wasn't used /solely/ for piracy... you can attack his intentions all you want but the service itself was not illegal.
You see the irony, right?
To not encrypt files via a browser using javascript.
One reason this particular flaw happened was due to the need to secure all content loaded insecurely by index.html, for example.
(I'm trying to address the general questions, like "why would I use or not use CBC-MAC", without getting into the general craziness of Mega's design or the idea of doing crypto in browser Javascript.)
I'm surprised you're entertaining the idea. (Edit: Sorry. I misread. I was only hoping to learn something new.)
It seems like at a minimum users would need to disable all browser extensions before uploading their content. That doesn't seem realistic, so browser-based crypto seems dubious.
Don't do crypto in browser Javascript!
Of course that's true of any website in general so the lesson is: be careful what extensions you install.
Third, browser support is still garbage. Safari has major issues, Firefox is lacking support in critical places, and IE, don't bother.
However the future is bright. With Typed Arrays & Web Workers running on all threads, you can expect 10+MB/s crypto in-browser very soon. That's slow by any other standard but potentially good enough for a browser. Hell, I'm pushing about 3.5MB/s on a MBA on securesha.re, which does 128-bit AES.
Just for disclosure, I wrote securesha.re (and succumbed to a few of these problems while writing it).
... for attackers with some knowledge of side-channel attacks, which are almost impossible to block from Javascript.
I don't know. I do know that other dynamic languages are trusted to perform crypto (e.g. Python). The fact that any dynamic language is trusted leads me to believe JS as a language may be fine.
or with certain JS runtimes?
Yes, each runtime must be analyzed by a crypto expert to uncover e.g. timing attack vulnerabilities, etc.
or with just the idea of running a program inside a web browser to do crypto?
Yes, implementing crypto within a webpage is a bad idea for many reasons. The first is that you must ultimately trust the browser itself, as well as its updater program. Second, you must trust every browser extension, since any extension can arbitrarily modify the page, and hence the javascript. (e.g. Reddit Enhancement Suite does this.) Since every extension can be updated at any time, you can't really trust any extension. Third, the javascript can be compromised in many other ways (e.g. XSS attack, etc). Fourth, crypto itself is extremely difficult to implement correctly, and it's easy to trick yourself into adding flaws while implementing it.
For these and other reasons, browser-based crypto can't ever be trusted. Not yet, and not until the above concerns are no longer relevant.
The first thing everyone thinks when they read about browser JS being a hostile environment for crypto is, "LANGUAGE WAR!" But this issue has nothing at all to do with languages. If Python was the de-facto standard content-controlled browser programming language, we'd be saying "don't do crypto in browser Python".
This question is extremely broad, and it requires envisioning future languages which haven't been invented yet, and looking for ways the design of the language itself might impact the security of crypto code implemented within it.
That said, the question isn't the most important one. It was his third question which you and I both responded to.
Other than that, their system is pretty clever, they are basically shifting the server load of strong-HTTPs'ing everything to the client.
Will he fix the problem and thank marcan?
Or arrest him at gunpoint, seize his property, and charge him with as many felony counts as possible?
I might just use it as an extra backup repository.
I am actually somewhat surprised that the known problems of Mega are so few. I would have expected that their crypto is more broken than this.
So by nature a CDN network is going to comprise many servers in different locations. Therefor if somebody pwns one of those servers it is risky for anybody who downloads the JS code from that particular CDN server.
Not the most detailed answer I grant you, but I don't understand all of the math involved.
When you see "256 bit" used in the context of SSL, this is referring to the block cypher used in the actual transmission rather than the RSA key size.
So an SSL implementation will probably use a 2048 bit RSA key and a 256 bit AES key. RSA is used to swap the shared secret which is used as the key to the main AES tranfer.
The encryption, it is a lie but at the end of the day it shouldn't detract from the fact that Mega is a decent cloud hosting platform with decent ideas. Compare Mega to offerings from Mediafire, Dropbox and insert other cloud file storage provider here and Mega is quite compelling considering the free 50gb of space you get.
Startups these days and even bigger companies like Google, got into the habit of creating something and giving it away for free or for cheap, then when it gets popular they either raise their prices, pull the plug or sell your data, fucking the same users that made them popular in the process and frankly I'm tired of that.
Right now I'm a Dropbox paying customer and decided against GDrive for instance, even though GDrive is cheaper and even though I was and am already a heavy Google Apps user. I went with Dropbox because they value me enough to provide a Linux client and I simply don't trust Google's pricing anymore, considering their recent history.
So even though I do use free services right now, for new services and products if it ain't open-source, if it isn't backed by a non-profit and if it doesn't have a decent price tag, then I'm not touching it.
Time will show if they fix this flaw, or not.
Given the massive amount of backlash and scrutiny from experts and non-experts alike, Kim always seems to win in the end and I am sure they're already planning on hiring a cryptography master to help them write something more serious as we speak.
Its also labelled beta.
I think that they have really tried to make it secure, but they aren't just competent enough. Browser-crypto is always somewhat insecure especially when they actually store your keys and you have to trust them.
TBMS, if the scheme were as follows: user downloads index.html over 4098-bit SSL (assuming that you trust the CA). index.html contains SHA2 hashes of all the remaining resources to be downloaded and compares the hashes of downloaded resources from completely untrusted servers to the ones that it already has and thusly decides to continue if the hashes are correct. Is there anything fundamentally flawed with this system or is javascript cryptography = bad just an overgeneralization?
Of course, this leaves open the main problem people have with javascript cryptography - at any point, Mega can change their javascript to no longer be secure. This means you can't actually trust that your data is secure from Mega - but then, I very much doubt anybody trusted this to start with?
It's the same thing as when I sign into my bank using my browser. My bank could at any time change their website to read in my account number and password, and then email this password to China, along with all my bank statements. I have to trust that my bank will not do this every time I use them. I also have to trust that the policeman I walked past earlier today would not shoot me with his handgun. You have to trust at some point.
I'm not sure about the trust part. Both your bank and the policeman have are committed to follow strict regulation, and have something to lose if they fail to do so.
There's a trust factor too, but I don't think Mega has the reinforcement of regulation or the consequences if they don't deliver what they promise.
If the encryption is done on the server side, Mega can legally be required to make a log of all copyrighted works uploaded to their servers and be liable for distribution. If the file is encrypted before it is uploaded, then Mega cannot physically store a log of copyrighted works. This is pretty major as take-down requests can then only be sent for a single upload. The most that could be done is for a court to publicly order Mega to cease and desist, at which point everyone can move on with no legal liability.
This is a piracy platform, not a genuine secure storage. It's fairly clever.
Sidenote regarding comment below:
I live in Africa, I'm not sure who I trust less out of my bank, the police, or Mega. Probably not Mega!
Think of it as bootstrapping. If they released a service you couldn't use from a browser, probably nobody would use it. But if they release one, even if it isn't as secure as it ought to be, and get millions of users, then someone will write a browser plug in that makes it so you don't have to trust the javascript anymore, and anyone who needs better security will use that. At that point the javascript is irrelevant because no one who needs better security is (or should be) relying on it, but first you have to get to that point. What the javascript becomes is a gateway into the service for people who don't need security and just want to take advantage of 50GB free storage, or who interact with people who have a different threat model.
For example, here's a use case: You're a whistleblower. You want to distribute something to the world and you can't allow anyone to know who you are. So you don't use the javascript, you use an open source native client, and you make your upload using TOR or pick your favorite anonymizer. Then Mega has an encrypted copy of what you want to publish, they have no idea what it is. Now all you have to do is post the link and password to a public forum (again using an anonymizer, and possibly from a different country from where you made the upload) so that by the time any third party can even know what it is that you've uploaded, it's available to the world and you're in a safe place. Meanwhile none of the downloaders who don't need protection from anyone has to install any special software because they can use the javascript.
Should (could?) SSL have been used to send data "in the clear but encrypted" (including the password to encrypte/decrypt the data) to Mega's servers and then encrypted server-side?
Early evidence is that they are listening and responding. https://mega.co.nz/#blog_3
Let's see what the response is to this piece.
I for one am not going to judge them too harshly if they keep listening and responding, as the product will just keep getting better. Sure they are blessed with I guess several million customers a few days after launch, but many here have also been through early product issues, albeit with far fewer customers. Like Mega, we learn and move on by fixing the problems.
I guess Mega appreciate the value of this sort of feedback, and the attendant publicity.
Edit: and just after publishing this, a tweet from Dotcom: "We welcome the ongoing #Mega security debate & will offer a cash prize encryption challenge soon. Let's see what you got ;-)"
But Mega isn't a site for governments or enterprises, it's for day-to-day users and file sharers. So I can't be too upset they decided to half-ass it and let the public fix their code.
Wouldn't it be quite easy to for example to steal users Dropbox passwords if one could modify some of the scripts they use on the frontpage and which are delivered via Cloudfront?
[Thawte Premium Server CA: 1024 bits, valid until 2021]... [Thawte Server CA: 1024 bits, valid until 2021]... [http://www.valicert.com/: 1024 bits, valid until 2019]
And some others I am not including...
CALM down with 1024 bits please as of 2013. (Notice that those come included in the OS)
Edit: this is not an authority argument (I am perfectly calm with 1024bits without OS X's assurance). I am only asking those people complaining about 1024bit keys to remove those certificates from their systems...