
A word on cryptography - rsingel
https://mega.co.nz/#blog_3
======
doe88
This is just another example where I don't understand why people are so
critical toward someone who try to build something. Are there any flaws?
probably, but who would honestly expect such massive code base wouldn't have
any flaw? but does that fatally undermine what he's trying to achieve? I don't
think so.

But i'm going to tell you why he has no good press, because he has no crypto
creds, there are plenty of experts who think that you don't have the right to
write any crypto code if you don't have the appropriate creds and are very
vocals when any attempt is made by someone not of their kind, some of them
even behave like bullies. I say don't listen to them, write some crypto code,
make some mistakes, learn from them and correct them.

~~~
grecy
Ignore the down votes, I agree with you 100%.

These guys have tried really hard to do something complicated nobody has
really done before. Sure, it has a few bugs and isn't 'perfect'. Neither was
the space shuttle, neither was the HTML 1.0 spec. Nothing ever is.

It's currently in style to put down tall poppies and complain about everything
and anything, even when it's free and you don't even have to use it if you
don't want to.

A community like Hacker News should be praising people trying to get off the
beaten path. Sure, constructive criticism is good, but flat complaining "It's
just unacceptable" is complete nonsense and a waste of everyone's time.

~~~
jy-p
plenty of people have done this before, they just weren't nearly as focused on
dodging legal liability for housing copyrighted data.

to claim that nobody has done client-side encrypted storage with sharing is
clearly incorrect.

~~~
grecy
So it's OK to cut down tall poppies just because they're trying to do
something someone else has already done?

You'll not go far with that mentality.

~~~
jy-p
if by "cut down tall poppies" you mean bring mega's claims of security and
privacy in-line with reality, sure.

there are plenty of people doing more interesting work with encrypted data
storage. to suggest that mega is blazing a new trail is absurd. backblaze has
been using a similar key-per-file encryption method since 2007, except they
actually executed properly.

------
comex
marcan tweeted that the JavaScript verification mentioned in the article is
completely broken: <https://twitter.com/marcan42>

_I thought MEGA's sales pitch was pretty good. And then I saw their Javascript
hashing code. Oh, the hilarity._

 _They're using a broken variant of CBC-MAC to authenticate their Javascript.
Except CBC-MAC isn't a hash. The key is public, so it's a joke._

 _CBC-MAC only works as a MAC, not as a hash function. You can replace all of
their JS, do a trivial subtract, and make it "hash" the same._

 _They also make other mistakes, like not authenticating the length and just
concatenating the various files, so other attacks are possible._

~~~
tptacek
CBC-MAC is also tricky to get right even if you know what it is. It's a very
weird choice.

But I wouldn't want to dignify the notion that one piece of Javascript can
"validate" other Javascript "files" anyways; the whole notion of Javascript
validation is dubious, because what you need to validate is the whole JS
runtime, not just individual files. Browsers don't provide tools to do that.

~~~
comex
Huh? It's perfectly valid in theory for one piece of trusted JavaScript to
download another from an insecure source and validate it before evalling it -
the attack scenario is not the browser being compromised, it's the source
delivering malicious code. (Whether this is really a useful thing to do
compared to serving all the JS in one place is another question.)

~~~
tptacek
Real systems that try to implement this scheme generally wind up implementing
the misconception that everything that contributes to the JS runtime comes
from discrete Javascript files.

~~~
dmix
Do you have a source?

I tried googling javascript runtime (primarily v8) exploitation and haven't
been able to find any examples of this ever happening.

Edit: I'm not saying its not plausible, but wouldn't it require root/user
access? What benefit would it provide over other type of attacks with that
level of access? Just because there's no browser tools to check for it?

~~~
marshray
This looks like a good read:

[http://www.adambarth.com/papers/2009/barth-weinberger-
song.p...](http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf)
Cross-Origin JavaScript Capability Leaks: Detection, Exploitation, and Defense

 _Although these vulnerabilities are imple- mentation errors in WebKit, the
presence of the bugs illustrates the fragility of the general architec- ture.
(Other browsers have historically had similar vulnerabilities [17, 18, 19].)
We detail these vulner- abilities and construct proof-of-concept exploits to
demonstrate how an attacker can leverage a leaked JavaScript pointer to inject
a malicious script into an honest security origin._

~~~
dmix
Thanks I'll check it out, but I thought that tptacek was talking about
manipulation of JS runtimes instead of exploitations of XSS bugs in webkit.

~~~
marshray
That's the thing about Javascript. The tiniest little XSS or subtle origin
violation results in the entire browser app being 100% 'pwned' (to use the
technical term).

The pwnage can even persist into the future for that user when you consider
the ability of browsers to cache content and HTML5's data store.

------
danso
I haven't read much actual writing from the Mega crew...but I was impressed
with its lack of ad hominem in its rebuttal. Sometimes, these technical
debates, especially when played out in the media, can get quite snarky.

~~~
gegenschall
The ad hominem way of discussion may or may not be present in technical
debates in general. What actually doesn't surprise me is that this style
surfaces on publications associated with Dotcom. If you happen to
speak/understand German you (really!) should read this:
<http://arnold.babsi.de/KIMBLE.txt> Basically the file contains old newsgroup
postings from de.org.ccc wherein Dotcom (Kimble) argues with or better
harrasses the CCC guys. It's really "worthwhile" and and an eye-opener.

~~~
rjzzleep
well, you know. i can see now why the ccc guys hate him. my coworkers said he
was a douche. and I can also see how they would say he talks more sales than
skill...

but the other side of it is, he's kinda right too. he's recruiting from the
ccc. a good place to recruit from. and he's talking about ACTUALLY making
money on stuff. it's kinda what my mother was saying when i was doing mainly
opensource stuff. she said, why are you working for free, and I said you don't
understand.

Germany is a kinda socialist country. I know, I grew up there. That's why
there's a whole bunch of great open source projects coming out that place. And
then the americans come, and make money on it.

I'm kinda derailing, and I could go on, but I'll just leave it at he's a
douche, and he may be a fraud, but the guys he's trying to recruit from are
not. And he kinda has a point.

And look at him now. He's got a shitload of funds, enough to pick a fight with
a government, and where's the CCC? It's still hiding behind political
correctness, still doing stuff years ahead of defcon, and yet everyone talks
about defcon instead.

~~~
belorn
Your post include many different topics, but I will just try to address one of
them. The anecdotal about open source and the implied socialist implication.

Many people only see programming as a job, and thus do not understand why
anyone would ever program if they didn't get paid. That is the only aspect
they see in it, and thus they think that their logic is without fault. But had
one been spending time playing music, with that independent band in a an
abandon factory and only playing music "for free" at charities and bars, that
mother would not wonder why you where "working for free". We would also not
call it a socialist thing to do.

There is of course political movements involved with programming, ie free
software. But even there, the term socialism is hard to use when there is so
many large companies involved. If one then take a look at music bands that
refuse "the big labels", or who are anti-establishment, we would also there
not call them socialistic just because they do stuff without getting paid.

In the end, one can not take a single economic model and apply it to open
source or free software, or for that matter any other thing that people has as
a both work and hobby.

~~~
rjzzleep
sorry man you completely missed the point.

germany is socialist. when you go to university, and you do something you are
expected to do it for free. all the research is free. you attend university
for free.

the flipside of it is that you are expected to give 50% or more of your salary
for everyones and your own benefit. you have no say in it whatsoever. you
cannot choose to have insurance, it was chosen for you. you are not supposed
to get rich. when they wanted to get indian engineers to germany the indians
said what do we get? and germany said, just the opportunity to work for us
should be enough. It should give you a hint on the mindset.

i had this discussion with one of my professors, and he said yes. his salary
is low, but the positive side is that he research anything he wants. he
doesn't have to say what the industry wants him to say, because his funding
depends on it.

it has good sides, and it has bad sides. of all the things I said, you chose
to pick on the open source side of it. really.... ?

------
AnthonyMouse
It seems like the security vulnerabilities are somewhat beside the point. It's
basically a beta, it's got bugs. But what they're trying to do is capable of
being secure. You can store data on a server without the server operator
having any ability to know what it is. It's not a new thing: You've always
been able to upload a truecrypt volume to any untrusted server. They're just
trying to make it easier to use for the man in the street.

So their implementation has flaws. Security experts are pointing them out. I
expect they'll be fixed soon enough.

~~~
cmircea
They haven't found any concrete flaws though. Just speculation and outright
wrong information.

The "If you can break SSL, you can break MEGA." made my day. I think MEGA is
the least of your worries if SSL is broken; credit card transactions would be
compromised big time.

~~~
AnthonyMouse
>They haven't found any concrete flaws though. Just speculation and outright
wrong information.

I have no doubt that some of the criticism is rooted in just a general hatred
and cynicism about "kim.com" and has no foundation, but some of the things
they're doing are legitimately questionable. Like having javascript served
from their servers have access to your password. If you want it to be secure
against them, you can't really do that. If they get compromised then their
server will serve compromised javascript and your data can be read by the
attackers the next time you access it.

But it's a trade off -- using javascript has somewhat lower security but is
easier for users to use -- and it seems like they even recognize it. The way
around it is to use a community-verified open source client (like a browser
plug in) to process users' passwords and never leave them or the unencrypted
data in the control of code from the Mega server, and it appears they have
plans to do that. And that has other benefits as well, like making it easy to
use high entropy machine-generated passwords for every piece of data and
having the plug in store the passwords encrypted on your local disk with a
master secret, so that you only have to remember one strong password for all
your data (or, if you're paranoid, one password for each set of data
classified by security level).

>The "If you can break SSL, you can break MEGA." made my day.

Yeah, is that actually not a straw man? Someone really said that? I have to
hope they were being sarcastic.

~~~
haldean
It's not, they did, and I don't think they were. Quote from article:

> But the problem goes beyond trusting Mega’s servers, says cryptographer
> Moxie Marlinspike, who recently left a position as head of product security
> for Twitter. Browser-based cryptography also means that anyone who breaks
> the SSL encryption that protects the data sent by the server could tamper
> with the code just as easily.

> “The security of Javascript-based cryptography is reducible to the security
> of the channel in which the Javascript is transmitted (every time you visit
> the page), which in this case is an SSL connection,” Marlinspike writes to
> me in an email. “If you can break SSL, you can break MEGA.”

Source:
[http://www.forbes.com/sites/andygreenberg/2013/01/21/researc...](http://www.forbes.com/sites/andygreenberg/2013/01/21/researchers-
warn-megas-new-encrypted-cloud-cant-keep-its-megasecurity-promises/)

~~~
AnthonyMouse
Meh. He's not complaining about Mega, he's complaining about SSL. He's always
complaining about it, and he's mostly right. There are legitimate problems
with it. In particular, too many questionable entities are registered as
certificate authorities in common browsers, so you periodically see these
imbeciles issuing wildcard certificates for * .google.com or * .gov which
totally compromises the ability of browser-based SSL to prevent man in the
middle attacks against anyone who can socially engineer or coerce their way
into one of those certificates from any one of the inept certificate
authorities.

And actually it's not a bad point for a service like this, in the sense that
browser-based SSL will never protect you against a _government_ who is trying
to read your _secrets_ , because the government can always coerce a local
certificate authority into giving it a certificate for whatever site it wants
to impersonate. The only way to prevent that is to remove all the common
certificate authorities, which doesn't actually improve security at all (it
really makes it worse under normal usage patterns), but it reduces your
inclination to have a false sense of security.

So it's a valid point: If you need _really good_ security, especially against
governments, javascript-based password decryption is a fail, not least because
it depends on SSL. But those people may still be able to use the service, just
not the web interface to it, and I kind of expect they'll be a minority of the
users in any event.

------
RaphiePS
I have no idea why a simple blog post would take 20 seconds to load--long
enough to have its own loading bar!

Taking a quick look at the source, it looks like they're doing some sort of
crypto. Very weird.

------
oconnore
It's important to understand that the only reason they are doing this at all
is for copyright defense.

~~~
tptacek
I find that idea very hard to square with their home page.

~~~
oconnore
They get shut down for copyright infringement and immediately come back with a
service touting a privacy system. Privacy from whom?

At Megaupload, your files were private from other people. Mega themselves
has/had no interest in snooping through your files. Various copyright
enforcement agencies are very interested in ensuring that users are not
violating copyright.

There is nothing about their system that is less secure than Megaupload was.
In both cases, everything goes over HTTPS. The only new addition (no matter
how broken their system is) is that now Mega cannot be reasonable expected to
monitor file upload content, or provide third parties with the ability to
monitor content.

~~~
tptacek
They didn't say "Strong". They said "Stronger". They didn't say "Safe". They
said "Safer".

------
zomgbbq
Am I the only one that noticed that when the page loads, it shows an image
very similar to stripe.com's cloud-with-gears image? Here are the two images
overlayed on top of each other: <http://i.imgur.com/pEuIbiD.png?1>

~~~
e-dard
How many ways are there to draw a cloud?

~~~
wmf
Obligatory:
[http://www.hanselman.com/blog/ThereIsOnlyOneCloudIconInTheEn...](http://www.hanselman.com/blog/ThereIsOnlyOneCloudIconInTheEntireUniverse.aspx)

The gears are a little suspicious, though.

------
mnutt
Leaving aside the issues of whether they've made mistakes in their crypto, I
think the more interesting point brought up by tptacek is that you can't truly
trust any client-side application that gets downloaded from the server every
time you go to the site. As much as Mega wants to protect your privacy, there
is always the possibility that some entity forces them to trivially break your
encryption by adding some javascript that uploads your private key and steals
your password.

Is it possible or desirable to secure a web app from its own creators? The web
is by far the largest and most successful software distribution mechanism of
all time (depending on how you define 'software') and it's built around the
idea that the creator can update the app at any time in a completely agile
fashion. But for certain classes of software, maybe it makes sense to protect
the users from the authors, or the authors from their future actions.

You might be able to accomplish something like this in a really hacked-up
fashion with HTML5 application manifests. Perhaps you could have the
application manifest include itself, to prevent the page from ever trying to
load itself again, and then have all updates happen though an AJAX mechanism
that validated each download and allowed third parties to verify that it was
safe.

But rereading the idea, it sounds neither pleasant to use nor particularly
safe. Is this "packaged software" mechanism something that should be built
into the browser at some level, or are we just doomed to running this class of
applications as native apps?

~~~
kansface
You can't trust any code for which you can't review the source. Even so, you
can't trust its interpreter/compiler without verifying its source and the
compiler that compiled it. This includes your OS of course. One would probably
also want to verify hardware level exploits too.

~~~
jy-p
well, he's talking about software, so getting into hardware exploits is a bit
out-of-scope.

that's not to say you shouldn't be worried either your silicon or NIC firmware
are compromised ;)

------
augustl
The article is not accessible from what their system deems a mobile device (a
Nexus 7 in my case), all I get is a redirect to a "dedicated mobile app coming
soon" page..

~~~
erre
If that's just your criticism, fair enough.

But, in case you think that makes you unable to actually read the article: on
the Nexus 7, you can click the "menu" button (those three vertical dots) and
select "Request desktop site".

~~~
augustl
Ah, good stuff, didn't know Chrome for Android could do that!

------
jakozaur
It is likely that they got a few flaws, but they make an effort and so many
security researchers look at them.

Ultimately, they have a good chance to be the most secure hosting service
available for masses.

------
ishansharma
Whatever respect and excitement I had for Mega and Dotcom was lost when I
tried visiting the link on Phone and iPad and it automatically redirected me
to "An app will be launched soon for your device".

Huh, I don't know how they do not get Internet. All the messed up encryption
and now this.

Bye Mega, I'm never joining of visiting you. And Kim Dotcom, sir, you make
good entertainment but I don't think your services suit me!

~~~
noknockers
So you're saying that you're pissed off because they're working on a free app
for you, for a free service for you?

~~~
raylu
I think his gripe is that he couldn't see the blog post because their site did
some browser detection and took him to the mobile version.

------
cometc
I would love to see this effort open sourced - both for others to learn from
and to establish it's security more openly.

~~~
jy-p
it is essentially open sourced already - the client-side crypto is done in
javascript which you can download or find online.

------
rdl
I'm not sure if they were being intentionally vague on how the deduplication
works, or just bad at writing, or writing for an incompetent audience. It
didn't seem clear based on what they said how it works.

------
htf
It looks like they know what they're doing. I was especially curious about
deduplication. The way they do it sounds perfectly reasonable:

> MEGA indeed uses deduplication, but it does so based on the entire file
> post-encryption rather than on blocks pre-encryption. If the same file is
> uploaded twice, encrypted with the same random 128-bit key, only one copy is
> stored on the server. Or, if (and this is much more likely!) a file is
> copied between folders or user accounts through the file manager or the API,
> all copies point to the same physical file.

~~~
guessWhy
Yes, but the first part makes no sense. If the 128-bit key is indeed chosen at
random for each file (as it should be), the probability that the same key will
be chosen again for a second upload of the same file is effectively zero
(1/2^128).

~~~
RaphiePS
It'd make more sense to derive the key from the data. That way, if two files
are duplicates, their encrypted versions will also be duplicates.

~~~
wmf
As mentioned in the last ten Mega crypto threads, security pedants aren't
satisfied with the level of privacy that convergent encryption provides.

~~~
guessWhy
I better idea might be to use convergent encryption only for really large
files. Practically this would mean deduplication of software, movies, etc.

~~~
AnthonyMouse
That has a good practical benefit (deduplication of files that most benefit
from deduplication), but it doesn't actually solve the security problems at
all, it's just choosing to make the trade off one way for large files and a
different way for smaller files. If you have a legitimate reason to want
privacy against data confirmation attacks then you need what you need
regardless of file size.

The whole thing with deduplication is a little bit overblown anyway. You don't
want a hundred copies of the same big file, but is that what really happens?
Nobody wants to upload the same file a hundred times, especially if the file
is very large. Once there is already a copy, passing around a link to it is
much easier than uploading it again. So the most common cause for it to happen
is when two totally unrelated people upload the same bit-for-bit identical
file, which happens, but not so often as to be prohibitive.

And in many cases file-level deduplication is difficult or impossible anyway
because users make changes to the files (like editing embedded metadata or
pointlessly encapsulating a single already-compressed file into a .rar
archive), so the benefits you get from deduplication are not nothing, but
there are situations where it is or isn't a reasonable trade off to make
against privacy.

------
rorrr
Some browsers already provide quality random numbers. This works in Chrome:

    
    
        var x = new Uint8Array(10); 
        window.crypto.getRandomValues(x);
        console.log(x);

~~~
gameshot911
How do I run code in Chrome?

~~~
bajsejohannes
On OS X: cmd+alt+j, paste, enter

Probably substitute cmd for ctrl on other OSes.

