Megafail
fail0verflow.com
fail0verflow.com
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.
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.
[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
alert('Hello World');
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.
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:
>>> 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'
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.
if (data == x) then { good_program } else { evil_program }
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
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.
It isn't like people are going to be using it to store trade secrets and diplomatic cables. The government isn't in the business of attacking a crypto system just to go after jor pirate consumer.
These keys are going to be leaked all the time - after all, it's for piracy so you need to give them out to your friends etc. The trick here is that the resultant takedown won't include any obligation to take down all the other copies of the same film, since they've all been keyed separately and aren't deduplicated.
Mega is an encrypted document service in the same way the pirate bay is a self publishing channel.
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.
That said, I think many of us have been missing the point with this site. The cryptography they provide allows for plausible deniability. No more, no less. They are perfectly able to view the contents of your uploads, and they never denied that. If you want truly private and secure files, then encrypt them yourself prior to uploading them.
The scope of this particular flaw (which, again, can be fixed transparently) is that you don't only need to trust Mega, you need to trust their CDNs as well. Neither of these levels of trust is enough if you truly are concerned about the privacy of your files.
It can only be considered a flaw in the first place because Mega claims to be the only party you need to trust and attempted to provide a means to ensure that. It just so happens that version 0 of this implementation does not work.
Then, fail0verflow goes ahead and say that since they have made this mistake they don't understand cryptography and should not be trusted to store your stuff. I'm sorry but that's bollocks. This system is big enough so absolutely anyone can make a stupid mistake or 2. Cryptography is just one element. A red herring IMO, being completely honest. If you are storing sensitive data don't let them do all the work and encrypt it yourself. Or just don't upload it to the cloud at all.
Absolutely everybody makes stupid mistakes and a single stupid mistake does not prove anything. I'd ask them to come down from their high horse because breaking a system is a lot less work than creating one. Especially when working under tight deadlines.
It doesn't.
Their product has two selling points.
i) 50 GB
ii) encryption
Without encryption they're going to be under very heavy disruptive scrutiny. This seems to be a product breaking flaw.
They claim to be able to read your files.
The difference between their claims and the actual system after this flaw is this:
CDNs can also potentially read your files if they are malicious and actively try (which would be a breach of their contract I assume).
Doesn't change a thing for me to be honest. I don't trust Mega and all their employees, or whoever breaks into their facilities, to have my bank accounts logins and passwords in plain text. I trust them to keep my kindle purchased books with me not being liable of being "broadcasting them" as they are reasonably protecting them.
Obviously it's a flaw and they should fix it. But it's not a doom and gloom, "their whole system is a farce" kind of flaw.
In big red capitals on their front page they say "THE PRIVACY COMPANY".
I couldn't find anything in the 46 point TOS that said explicitly that they can read your files.
On their about page they say "Unlike most of our competitors, we use a state of the art browser based encryption technology where you, not us, control the keys." - that doesn't make it sound like they're telling you they can access your files.
On their "The Privacy Company" page they quote from the universal declaration of human rights,and they say "All files stored on MEGA are encrypted. All data transfers from and to MEGA are encrypted. And while most cloud storage providers can and do claim the same, MEGA is different – unlike the industry norm where the cloud storage provider holds the decryption key, with MEGA, you control the encryption, you hold the keys, and you decide who you grant or deny access to your files, without requiring any risky software installs. It’s all happening in your web browser!" - that doesn't sound like they're telling you that they can read your files.
On their help centre page they say "Because the server can't see filenames, filename collisions have to be dealt with on the client side. With standard settings, if you upload a file that you already seem to have in your account (same target path/filename, same size, same last modification time), it is skipped, but nothing prevents you from keeping multiple files or folders with the same name in the same folder." - which doesn't sound like they're saying they can read your files. They also say "Because our end-to-end encryption model inherently precludes any server-side manipulation of your data, which would be required to implement such a feature." - which also doesn't sound like they're saying they can read your data.
But now we find out that not only can they read your files but a CDN could read your files. Since we know that companies must comply with correctly formed legal requests anything that extends the number of companies that can read the files increases the number of companies that can be leaned on by well funded groups.
> Obviously it's a flaw and they should fix it. But it's not a doom and gloom, "their whole system is a farce" kind of flaw.
Their whole system is cloud storage with encryption - without encryption it's just cloud storage and there's a bunch of other people offering that. Those other providers have the advantage of not having been previously raided by paramilitary police from an aggressive government.
Crypto is hard. It's easy to go wrong. I have no idea what kind of research they did before launching, but to have broken crypto a few days after launch is not a good sign.
If you buy into slogans as tech feature listings.
They store with encryption. That remains true. The fact that CDNs can potentially break into it doesn't mean that they store without encryption. Let's not exaggerate the scope of this flaw. A flaw that in any case is going to be fixed soon.
Crypto is hard, true. But this system is fixable on the server, so it's not as critical as a hardware system that may need to be recalled.
Don't worry, and remember that in any case THEY WILL STILL BE ABLE TO READ YOUR FILES.
They are possibly not emphasizing this enough. If you have truly sensitive data don't put it there as-is.
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.
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.
I might just use it as an extra backup repository.
Oh and once set, you can't change any password or delete your account.
http://arstechnica.com/security/2013/01/cracking-tool-milks-...
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.
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.
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.
Edit: found this, I don't know why they picked that name: http://bcrypt.sourceforge.net/
My original point wasn't to recommend a particular encryption software. My intended point was that you should take responsibility for protecting your files yourself, and rely as little as possible on trusting others, like Kim Dotcom.
[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...
Of course you still need to be able to MITM a 1024-bit SSL connection to make use of it.
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?
SSL/TLS: Without transport level security (SSL/TLS), and no other encryption, it is absolutely trivial to intercept data. Unsecured WiFi, malicious network operators, hacked middlemen, spoofed DNS; there are many threat vectors. Adding SSL/TLS significantly increases security.
Server-side encryption: Added server-side encryption to SSL/TLS marginally increases security. It actually doesn't protect from much. Disposal of the hard drives is a common one people cite, in case HDDs aren't wiped when sent to the junk yard or for RMA. It could also protect against some accidental data leaks if files become readable through unintended means, or if the server is actually hosting the files in a third-party service (e.g., CDN, S3). It doesn't protect from employees of the server host, and it does little to protect from hackers that get full server access as the decryption key is likely stored in a file on the server.
Client-side JavaScript: JavaScript encryption actually adds a reasonable amount of security. Yes, you have to trust the browser makers, the browser update mechanism, and the company hosting the service (they could always change the JavaScript to steal your password). It does make it less trivial for a malicious employee to access your data, they would have to write and deploy new JavaScript. It also makes it less trivial for a hacker that gains server access, they would have to modify the JavaScript too. Modifying the JS is feasible for a targeted attack. It also protects against offline attacks, where a hacker copies data to their own systems to analyze before they get detected.
I think you have to trust the browser makers and their update mechanisms. The browsers always have access to everything, they could be capturing your banking passwords, or insert dummy SSL CAs, they could do anything. You also have to trust the makers of client software, whether it's JavaScript in the browser or C on the command-line, very few people are going to check the source code, most people will accept whatever client updates are provided.
Where client-side JavaScript falls apart is that it is vulnerable to some of the most common security exploits. Namely random browser vulnerabilities, XSS attacks, and malicious or vulnerable browser extensions and plugins. People are far too willing to install or unwittingly install (thanks InstallMonetizer) browser extensions and plug-ins which have too much access to your browser data. But your bank account is also vulnerable to the same issues. So while you shouldn't use client-side JavaScript to protect Top Secret government information, it does provide a decent amount of security, and is probably good enough for most cloud storage solutions.
I think you'd have to both create a file that passed the hash check and was valid javascript, which seems somewhat more difficult.
I have one request for you (the owner of fail0verflow.com): please enable me to increase the font size on your site. Reading that font size on a 24" monitor is painful.
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?
Their new album needs work.
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?
Other than that, their system is pretty clever, they are basically shifting the server load of strong-HTTPs'ing everything to the client.
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?