
Megafail - comex
http://fail0verflow.com/blog/2013/megafail.html
======
lancewiggs
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.

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 ;-)"

~~~
spyder
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.

~~~
adcoelho
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.

~~~
badgar
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.

------
PhrosTT
When I started the article I thought, "Oh great another speculative Mega
bashing."

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.

~~~
dlitz
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>

~~~
redthrowaway
Well that was an hour productively wasted.

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

~~~
rurounijones
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.

~~~
timothya
M55 is also known to be insecure: it's straightforward to find hash collisions
with the MD5 function.

~~~
rorrr
Really?

Can you generate a JS file (that will actually execute) with the same MD5 as

    
    
        alert('Hello World');
    

MD5 is 7ecf458bad499f6815cbc10ed597dd3a

~~~
waffenklang
alert('Hello World'); // add random chars here until hash fits

sure its not trivial, but not impossible.

~~~
lawnchair_larry
Actually that particular attack is impossible as far as humans currently know.

~~~
CamperBob2
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.

~~~
lawnchair_larry
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.

So, I rounded up to impossible.

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

~~~
ChuckMcM
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.

~~~
forrestthewoods
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.

~~~
throwaway125
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.

~~~
narag
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.

~~~
mrgoldenbrown
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.

~~~
narag
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.

------
trotsky
Isn't this missing the entire point? The only purpose of the encryption is to
give Mega a strong basis for being able to deny any knowledge of what the
content stored on their servers represent.

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.

~~~
ctdonath
I was wondering if the flaw was intentional.

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

~~~
ma2rten
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.

Time will show if they fix this flaw, or not.

~~~
DigitalSea
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.

~~~
Havoc
> at present it is a gimmicky feature

Its also labelled beta.

------
muyuu
All these issues can be fixed in a completely transparent way for the end
user. And they should be.

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.

~~~
DanBC
Mega said that their system ensures privacy for your files.

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.

~~~
muyuu
They don't say exactly that.

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.

~~~
DanBC
> They don't say exactly that.

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.

~~~
muyuu
That's a slogan and it can be interpreted in many ways.

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.

------
chacham15
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?

~~~
RyanZAG
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.

~~~
moxie
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.

~~~
RyanZAG
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!

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

~~~
sillysaurus
_If your objective is to stash sensitive files, there are plenty of
established options._

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.

~~~
easytiger
I was considering using them. Somehow i trust them more because they havn't
got a 3MB front page covered in JS animations

------
jpxxx
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!

~~~
chii
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.

~~~
dalke
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.

------
nwh
I liked this one too. They're emailing hashes of the users password, full
name, and their encryption key as the "verify address" URL.

Oh and once set, you can't change any password or delete your account.

[http://arstechnica.com/security/2013/01/cracking-tool-
milks-...](http://arstechnica.com/security/2013/01/cracking-tool-milks-
weakness-to-reveal-some-mega-passwords/)

------
jiggy2011
So, who are these people who don't completely fail at crypto and how do you
hire them?

~~~
sk5t
What do you want to hire them for?

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.

~~~
jiggy2011
I mean more in a theoretical sense.

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

~~~
lawnchair_larry
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.

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.

~~~
jiggy2011
So , only use stuff written by google/MS sized companies or very mature OS
projects?

~~~
lawnchair_larry
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.

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

~~~
jiggy2011
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.

~~~
zanny
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?

~~~
jiggy2011
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.

~~~
zanny
Thanks, I forgot asymmetric keys were easily computed. I'm just thinking
random number space brute force against something like SHA2 SSL.

------
jiggy2011
So, forgive me for asking a dumb question. What would be a better approach
here? I'm assuming that SHA1 doesn't cut it.

~~~
tptacek
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.)

~~~
sillysaurus
Is browser-based crypto ever feasible?

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.

~~~
jiggy2011
Is the problem with the JS language itself, with certain JS runtimes or with
just the idea of running a program inside a web browser to do crypto?

~~~
STRML
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).

~~~
JoachimSchipper
> However the future is bright

... for attackers with some knowledge of side-channel attacks, which are
almost impossible to block from Javascript.

------
gsibble
I was impressed by the analysis and blown away by the proof of concept.
Awesome article. Mega, you listening?

------
inetsee
I remain convinced that the best security of all is to encrypt your files
yourself, on your own computer, using trusted encryption software (I use
bcrypt), with a strong password, before uploading the files to any cloud based
storage service, even the ones with excellent trust ratings.

~~~
mylittlepony
Isn't bcrypt a hashing algorithm based on an encryption algorithm? Meaning you
can't use it for encrypting your files.

Edit: found this, I don't know why they picked that name:
<http://bcrypt.sourceforge.net/>

~~~
inetsee
I believe the "b" in bcrypt stands for Blowfish, which is the underlying
encryption algorithm used in this open-source, cross-platform file encryption
utility to which I was referring. I hadn't known about the bcrypt used for
password hashing.

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.

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

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

------
tlrobinson
This appears to be the first _actual_ vulnerability in Mega.

Of course you still need to be able to MITM a 1024-bit SSL connection to make
use of it.

------
jpalomaki
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?

------
antoncohen
To address the comments about client-side JavaScript encryption being
insecure, client-side JavaScript isn't inherently insecure, or rather security
is entirely dependent on the threat vectors you are trying to protect against.
Some examples of levels of security:

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.

~~~
7952
What if you host the javascript separately to the dynamic content (say on S3)?
This would give users some protection against compromised servers. This is
akin to having an app supplied from a trusted source (ITunes) and then
accessing an API through client side encryption.

------
scriby
I don't think the attack as described would work in practice, because the
modified javascript file would no longer be valid javascript and would just
break the site.

I think you'd have to both create a file that passed the hash check and was
valid javascript, which seems somewhat more difficult.

------
dkersten
The real "megafail" here is that browser zoom doesn't actually make the blogs
text any bigger.

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

------
runeks
Interesting article.

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.

~~~
wlesieutre
It's using 15px with a 22px line height, which looks pretty typical and about
as readable as any other blog. Even the code blocks are 14px, noticeably
larger than the 12px in HN comments.

~~~
runeks
Which is why I resize the HN comments page. I'd really like to be able to do
the same on that site (resizing just enlarges the background images, not the
text).

------
6ren
Now here's where we will see Kim Dotcom's true colours:

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?

~~~
dfc
Kim Dotcom is a judge, prosecutor and LEO?

~~~
babblefrog
I think there's a joke in there.

------
Mahn
So, a bit offtopic, but other than the hype and the encryption discussions, is
anyone actually using the service?

------
sambomillo
Personally I can't wait to use this service. How can they afford the storage
though? Is it sustainable?

------
cientifico
I really hope any of my banks implement this poor implemented check some day !

------
orionblastar
Megafail: The File System Has Failed

Their new album needs work.

------
mortdeus
Glad you guys are back!

------
ratonofx
KDC, what are u waiting for hire this guy now?

~~~
badgar
Why would this guy want to work for KDC?

~~~
frere
His money is still green.

~~~
badgar
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.

~~~
frere
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.

------
kahawe
It never ceases to amaze me how schmitz is doing the EXACT same thing for at
least 2 decades now. He did exactly this on BBS, had other people upload to
him and offer it up for download; then he ratted everyone he knew and worked
with out to the police. Rinse and repeat with megaupload, let's see what kind
of deal he will be going for in the end; and now there is "mega", let's see
where this will go.

------
martinced
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?

~~~
Xylakant
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.

------
rorrr
So all they have to do is switch to a proper hash function. Probably even MD5
would do.

Other than that, their system is pretty clever, they are basically shifting
the server load of strong-HTTPs'ing everything to the client.

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

~~~
tnuc
Google makes money from copyright infringing youtube videos and music.

Does this make anyone who works for Google a "piece of shit"?

~~~
MTWomg
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.

~~~
tnuc
>Megaupload was designed to be used to host pirated content...

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

~~~
MTWomg
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.

~~~
hef19898
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.

~~~
MTWomg
That's fine and all, but the evidence is pretty clear....

~~~
hef19898
That's for proper jury or court to judge. At least in democratic legal
systems.

------
tommaxwell
Ugh, text-align:justify.

~~~
tommaxwell
Really, a downvote for this? Just pointing out the obvious -- that you
probably shouldn't use justify for blogs.

