
MEGAChat now includes end-to-end encryption - ponyous
https://mega.nz/#blog_38
======
infinity0
Note in particular that the current system does not have forward secrecy. Near
the end of the post:

> Then we plan to launch a 'Whisper Mode' for additional protection when in
> instant messaging sessions (e.g. message transcript/order consistency,
> delivery assurance, forward secrecy, and some others).

This is what I was working on at MEGA, but recently they decided to stop
funding me, and I'm under the strong impression that nobody else there is
working on this. So it's unclear that they have a concrete time frame for it.

The source code and docs are here though:

[https://github.com/meganz/mpenc_js](https://github.com/meganz/mpenc_js)
[https://github.com/meganz/mpenc_doc](https://github.com/meganz/mpenc_doc)
[https://docs.mega.nz/chat/mpenc/](https://docs.mega.nz/chat/mpenc/)

If anyone wants to continue funding this work, feel free to drop me a line.

~~~
eganist
Scroll down to buu700's comments. They're likely relevant to your background
and probably in a better position to embrace what you've got so far.

------
buu700
Since no one else has explicitly brought this up:
[https://tonyarcieri.com/whats-wrong-with-
webcrypto](https://tonyarcieri.com/whats-wrong-with-webcrypto) (also see
Matasano's "JavaScript Cryptography Considered Harmful", etc.). There is
nothing that a service like this will protect you from that you don't already
get while using TLS in just about every insecure/non-E2EE chat service.

If you're looking for actually secure communication that runs as a Web app, my
startup Cyph (cyph.com) is the only option that exists. This is because we put
in the time to build it correctly; the root page of our application is a
permanently pinned (TOFU) bootstrap that validates/executes signed application
packages, and the scheme to accomplish this was rigorously vetted in a 12-day
audit.

Edits:

* Here's how it works: [https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...](https://www.reddit.com/r/encryption/comments/4027ci/how_2_spacex_alums_are_using_encryption_for_good/cyywmc8)

* Here's Cure53's audit report: [http://cyph.team/cure53report](http://cyph.team/cure53report)

~~~
tptacek
I don't think it's a good idea to provide secure messaging services that boot
from a web page, under any circumstances.

This stuff has to work. The adversary for secure messaging is world
governments. If all you're worried about is criminals, Gchat will do a fine
job of protecting you. For a vivid example of what I'm talking about, see the
Telegram/Iran fiasco.

It's hard enough building secure messaging in a native application; there are
lots of details that are not easy to get right (as Cure53 demonstrated to your
team).

Bluntly: I feel that it's irresponsible to add to that portfolio of
difficulties the added attack surface of content-controlled Javascript.

The reason people build services like this is that users will prefer them to
(more secure) native app alternatives. It's easy to see why. The common
response to this observation is: "but users won't install an app". They won't
install an app because people keep luring the away with insecure web-page
based secure messengers.

~~~
buu700
Hey Thomas, thanks for the comment; I'd been wanting a chance to get your
thoughts on WebSign for ages!

While our audit demonstrates that this scheme shouldn't be expected to be
cracked without a critical vulnerability making its way into your browser, it
does introduce some odd dependency relationships that certainly introduce new
attack vectors not seen in the TOFU property of regular standalone apps.

For example, given that the NSA can be assumed to be indiscriminately
passively logging all HTTPS traffic, imagine that one day they gain the
capability to break 4096-bit RSA: in a targeted attack scenario, suddenly they
can now go back through their traffic logs, find whichever public key is
pinned in a particular Cyph user's browser, compute the associated private
key, and undo method #2 as descried in the linked reddit comment (the
"permanent offline" trick), which gets them half of the way toward completely
breaking that user's TOFU.

That having been said, I consider it a perfectly acceptable and pretty neat
solution to the problem. Is there something else you're seeing that makes you
object to it?

Edit: If your objection isn't to WebSign but to the Web / JS as an execution
environment in general, I'll throw in a link to this note on how we're
mitigating those traditional risks while also benefitting from the
sophisticated sandboxing of modern browsers:
[https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...](https://www.reddit.com/r/encryption/comments/4027ci/how_2_spacex_alums_are_using_encryption_for_good/cyybn23)

~~~
tptacek
Am I understanding correctly that you consider your adversary to be the
National Security Agency, the world's best funded, best equipped, best staffed
SIGINT agency, and that you think they're limited to passive observation?

Again: I just think this is a bad idea. I'm sure you're great people, but
cryptographic security is hard enough for native apps, without trying to
deploy it in the jungle gym of some random browser runtime.

You should stop deploying this app from a web page. Altogether. And soon. Port
it instead to be a Chrome extension that users install.

I'm sure you're not hurting anyone right now. But you've built the kind of
application that will, if it ever gets to be very successful, probably get
people hurt. Better instead to work on something that will help people more as
it gets more popular.

~~~
buu700
_Am I understanding correctly that you consider your adversary to be the
National Security Agency, the world 's best funded, best equipped, best
staffed SIGINT agency, and that you think they're limited to passive
observation?_

No, you aren't; the example was to illustrate an entirely different point.

 _Again: I just think this is a bad idea. I 'm sure you're great people, but
cryptographic security is hard enough for native apps, without trying to
deploy it in the jungle gym of some random browser runtime._

Do you have a specific criticism, or is your argument more of a general point
that solving multiple hard problems is more difficult to do correctly?

If that is what you're getting at, it seems like it would be effectively
addressed by frequent audits of the Cyph source code.

~~~
tptacek
There are very specific concerns I have about implementing secure cryptography
in a browser runtime. I wrote an article about this a while back. I don't love
that article and never did, but one complaint I've heard about it is that it's
"dated". In fact: I think the last few years have made it _harder_ to securely
deploy crypto in a browser. So one short answer is, for a bunch of fiddly
reasons, I think you're building one of next year's Black Hat Briefings talks.

But the broader concern is, in fact, that by offering people a secure
messenger, you're accepting some responsibility for securing traffic that can
jeopardize lives if you're compromised. You have, I think, a moral
responsibility to be as conservative as you possibly can be. When someone gets
hurt because this system is flawed --- assuming you ever learn about it --- I
think you're going to be surprised by where it happened. People with causes
you've never even considered will use this thing in ways that, if you knew
about, you'd say "fuck! stop! i like my application but i can't let you bet
your life on it!".

It's great that you paid for an audit, but audits aren't magic feathers. If
you got audited again by a strong team, they'd find _other_ things you missed.
As it stands, the team that audited you found devastating crypto flaws; for
instance, you repeated nonces! Crypto is hard even on the "easy" setting.
You've got the difficulty setting dialed all the way to "nightmare".

Dial it back down.

~~~
cyphar
> But the broader concern is, in fact, that by offering people a secure
> messenger, you're accepting some responsibility for securing traffic that
> can jeopardize lives if you're compromised. You have, I think, a moral
> responsibility to be as conservative as you possibly can be. When someone
> gets hurt because this system is flawed --- assuming you ever learn about it
> --- I think you're going to be surprised by where it happened. People with
> causes you've never even considered will use this thing in ways that, if you
> knew about, you'd say "fuck! stop! i like my application but i can't let you
> bet your life on it!".

I agree with you about web crypto, but I disagree with this point. A point
that Roger Dingledine (of Tor fame) made a few years ago was that people who
are going to say something which their government doesn't want them to say are
going to say it anyway. If they can't communicate using the internet, they are
willing to make protests in the streets, to shout and scream to try to improve
their world. The job of people making cryptosystems to try to keep such
activists safe is to minimise risk and do the best they can. You shouldn't
think that you're responsible for what happens to those people, you're doing
the best you can for them. But at the end of the day, they are willing to die
for their goals and it is disrespectful to ignore that fact.

But yes, I agree that the service in question probably needs much more work.
And it should probably say "this is still Alpha".

~~~
buu700
I felt that that was a perfectly fair statement on Thomas's part. It's fine if
people are willing to risk their lives for a cause, but they shouldn't be
misled into outright sacrificing their lives because someone irresponsibly
marketed a tool as being suitable for a particular purpose.

I'm also not sure where you get the impression that Cyph is currently at an
"alpha" stage, but I'm going to have to disagree with you there too. Do you
have more specific feedback, and/or did you run into a bug while using it?

------
Freak_NL
It's great that there is such a strong interest in secure communication, but
all of the solutions that keep getting placed in the limelight in recent years
are either centralised or exclusively available for use with a smartphone
(because of the phone number requirement), often both!

I'm sure that these solutions are a lot more secure than completely
unprotected alternatives, but am I wrong in assuming that if you want secure
and private communications, the following principles must be met _at the
least?_

* The protocol used must be open, standardized and implementable by others

* Widely endorsed by cryptography experts

* An implementation must be available and developed as free and open source software

* End-to-end encryption is used for the contents of the conversations, private keys do not leave the user's computing device

* The protocol must not have any technological barriers that prevent an implementation from working on any modern operating system (i.e., a phone number is not required)

* The protocol must allow for a complete communications network (clients and servers) to be implemented without the need for centralised third-party services

(The last point probably implies federation.)

For e-mail, OpenPGP meets these requirements. For chat, XMPP has Off-The-
Record messaging.

Some of the above points are hostile towards any party that creates secure
communications tools with the intent of growing a large user base for economic
purposes. Call me a sceptic, but this is probably why use of these protocols
and principals is limited to security experts and software developers who
understand these principles — for anyone betting on creating the next WhatsApp
in one of the mobile walled gardens embracing the whole list means risking
losing your potential advertising eyeballs to alternatives.

Of course, there is also the matter of infrastructure. A lot of people expect
to be able to use these tools for free, but that implies that someone is
paying for the hosting of (relay) servers.

~~~
DanBC
> Call me a sceptic, but this is probably why use of these protocols and
> principals is limited to security experts and software developers who
> understand these principals

OpenPGP is impossible for most email users to get working correctly.

Remember that most people don't even know the difference between CC and BCC.

Here's an example of de-anonymising anonymous messages, supossedly from
clueful users: [https://ritter.vg/blog-
deanonymizing_amm.html](https://ritter.vg/blog-deanonymizing_amm.html)

~~~
Freak_NL
> impossible

Difficult perhaps, certainly not impossible, and quite feasible if someone
helps you. But I am not suggesting OpenPGP as an alternative for chat-apps for
everyone; only for those who understand how to use the technology properly.

I mention OpenPGP and XMPP OTR because they are examples of open standards
that do fulfil the principles outlined above. That is, to illustrate that it
is certainly not impossible or infeasible to create such a technology. What is
missing is a technology that does that, and allows anyone (regardless of
technological prowess) to use them safely. It is a tough problem though.

~~~
zanny
From a UX perspective, _can_ we do better? I'll base both off my personal
experience - Kmail and KDE Telepathy - since those are my email and IM client.

In kmail, to use GPG keys, I need to go to Settings -> Configure -> Identity
-> Modify -> Cryptography, change my signing and encryption keys (and it
supports PGP or MIME) and then, since I don't already have keys, need to open
Kleopatra, the KDE GPG client.

Kleopatra uses keys.gpupg.net as its default keyserver, and you can do file ->
new certificate to make one. Its a wizard, so you go step by step, setting up
a password for the cert along the way. You also make a revoke cert you save
somewhere.

Once you made the key, you need to export it to the server. And you probably
want to make a signing and encryption key, since if you got this far you are
already a super techy nerd and that is what makes my point right there.

If you want normal people to be able to use gpg in kmail, there needs to be a
wizard just like the "add account wizard" called "Setup GPG" that searches for
keys that match your email address first in case you already have them and if
there are none generates you new ones and just asks you for the password. It
handles the propagation and importing of keys itself because thats not
something a user should be dealing with unless they need to.

And even that is unlikely to happen - you want the GPG setup to really be a
part of the first-start of Kmail process. Like the first time you open the
program and get the "add account" button you should also get "setup security".

But even if you can get people _making_ keys, the UX sucks because it makes
them enter a password every time you send an email. You should be able to do
what kwallet recently did, and bind the unlock key to your GPG keys to your
user session so that when you enter the desktop via SDDM it unlocks your GPG
keys just like it unlocks your wallet. Then people can use secure email
whenever they want without any bullshit.

There are even more UX nightmares - getting your keys across different
computers, easily revoking them if they get compromised, even knowing what
that means.

By comparison OTR in Telepathy is almost usable. In KTP you just hit the "use
OTR" button and if your chat partner does the same it automagically generates
and shares the keys, no user interaction required. The only downside is that
you don't get local logging of your OTR conversations - that should definitely
be an option, maybe even encrypt them with your kwallet keys! Eh, eh?

But these kind of UX nightmares keep secure communications from being a thing.
Mumble is literally the best security solution I have, because I can get a
letsencrypt cert, run my own server, put on a password, and anyone chatting on
it has perfect security in voice and text - the whole thing is encrypted, I
can do my own trust network based off my x509 cert, and it even supports
pinned users so nobody can impersonate anyone else.

But I say that its the best because for anyone I invite, they literally just
need to enter the password I give them to my server. Sure, its problematic to
_give_ them the password if you don't have a secure communication link
beforehand, but I guess thats what OTR is for! Oh drat...

~~~
rakoo
I 100% with you that UX is the most important problem that is not solved with
PGP, and as long as nobody will do something we'll never be able to use
crypto. I also believe that if your crypto doesn't solve something that PGP
doesn't already solve, then you'd better spend your time on bettering UX
instead.

However Mumble is not a valid comparison, because Mumble is not End-to-End
encrypted. The security of Mumble amounts to an encrypted connection to the
server, protected by a password; from this POV Mumble is no more secure than
Facebook or Hacker News.

~~~
zanny
It is end to end encrypted when you are one of the participants and you own
the server. Thats what I mean by its the best secure communications solution I
have - I can sholder the work of getting a valid cert, but once its setup as
long as I trust who I'm talking to is who I think I'm talking to, I am sure
nobody can evesdrop because its _my_ server. And for the people I care to have
private conservations with, downloading / install Mumble on their phone or
desktop is their regular patterns of behavior and isn't inconvenient at all
compared to insanity like GPG or OTR.

------
jpgvm
It sounds reasonable? If anything this highlights the problem with all the new
encrypted communications options, even highly technical people can't really
know how good it is from a cursory look. Just because it says end to end
encryption and uses some nice ciphers it doesn't mean the implementation is
not critically flawed.

I use Signal right now (from Moxie Marlinspike/Whisper Systems) and would only
really consider alternatives if they were endorsed by other cryptographers I
know because I really just don't have a strong enough grasp of how all the
machinery interacts.

~~~
treenyc
It is great that Whisper Systems/Signal implement cryptography properly.

However, the NEWER versions of Signal requires access to your contact to work.

For many users that is a show stopper.

Implement a way for user to search by User ID and allow user to find each
other by ID in addition to phone number.

~~~
brbsix
Recent updates also show disconcerting "Joe is on Signal!" messages for
everyone in your contacts (who is registered with Signal) regardless of
whether or not you've had any contact with them. They've stated that this is
not a security issue (I don't recall the specifics) but it was pretty
disturbing nonetheless. I'll definitely be paying closer attention and
consider switching to an alternative if this trend continues.

~~~
asddubs
Why specifically are you worried about that?

~~~
brbsix
I've recommended Signal (then TextSecure) to a number of non-technically savvy
friends as a trustworthy app that takes security seriously. Moxie is somewhat
unique in this respect, among the sea of proprietary apps put out by larger
shops. Upon seeing these "X is on Signal" messages, I had a number of people
contacting me with concerns. At least the outward appearance is that Signal is
somehow leaking contact data to their servers. Presumably it is also alerting
people to the fact that "Joe" is a Signal user, despite no communication with
that user having taken place.

I realize that phone numbers are probably hashed before being sent, with only
local contact data being displayed, but it has people concerned nonetheless.
It starts to err more towards convenience, ease of use, and network building
above security.

~~~
asddubs
you can easily enumerate this data anyway, though. Just go through your
contact list and try to add people. You could come up with an elaborate system
where the other person has to confirm you, but everyone knows that's rubbish
and users hate it. Sorry for the late response, I forgot I made this comment.

~~~
brbsix
Yes I'm well aware at the ease in which someone could build a client that
would provide such a feature had it not been included. Moxie takes great care
not to provide mere illusions of security (or in this case obscurity) such as
self-destructing messages or other features of that ilk. I appreciate it, and
it's a big part of why I use and recommend projects affiliated with Open
Whisper. Still don't believe it was the right decision to blast users with a
notification from every Signal user in your contacts. Let Telegram or Whatsapp
or some other crap play that game.

------
mtgx
Didn't Kim Dotcom say you can't trust Mega anymore?

[http://www.wired.co.uk/news/archive/2015-07/31/kim-dotcom-
me...](http://www.wired.co.uk/news/archive/2015-07/31/kim-dotcom-mega-3)

~~~
aw3c2
If Kim Dotcom says you can't trust something does that mean you can?
[https://de.wikipedia.org/wiki/Kim_Dotcom#Werdegang](https://de.wikipedia.org/wiki/Kim_Dotcom#Werdegang)

~~~
junto
Nice! For those that don't know, Kim Schmitz / Kimble(now Dotcom), sold out
his fellow warez peers to the copyright lawyer Günter Freiherr von
Gravenreuth. Like the wild West he was supposedly paid per head.

[http://www.forbes.com/sites/andygreenberg/2013/04/17/where-k...](http://www.forbes.com/sites/andygreenberg/2013/04/17/where-
kim-dotcom-got-his-start-the-house-of-coolness/#2c0ff577c134)

Not mentioned in the article is his involvement in the AT&T calling card fraud
conspiracy (estimated losses $20 million) in the early '90's. It is that case
that put him on the US Secret Service's radar and he's been on it ever since.

~~~
DyslexicAtheist
not to mention having made most of his cash with insider trading in Germany.

~~~
Kristine1975
Which wasn't illegal at that point, though.

~~~
DyslexicAtheist
yepp indeed. that just made me think ... a lot of things weren't ... such as
bribing gov officials when participating in tenders (example Siemens and
others learned the hard way). Lot of things seemed to have become illegal in
Germany just over the past 20 years. Now they're even trying to curb our
creativity when writing software for exhaust emmissions test /s

------
iofj
Powered by code that you download every time you use it, and that therefore
can leak your keys and conversations at any time, just as centralized chat
can.

~~~
vortico
Hopefully you can download the web client. The mobile apps do not have this
problem.

~~~
jimktrains2
But mobile apps can still wrap web views. Also, if you can't inspect the
source, you can't even be reasonably certain keys are handled properly.

------
doomrobo
Somewhat off topic, but does anybody remember when MEGASync (a MEGA desktop
sync client) came out and the Linux source code was "on its way?" It's been
over a year (maybe 2?) and I've seen nothing. I have no reason to trust the
security of the file storage backend until then.

------
DyslexicAtheist
alternative title for this post: _" rolling your won crypto and smoking it
too"_

~~~
lindx
The "don't roll your own crypto" mantra was created by the NSA to make people
afraid to develop and deploy cryptography. See here:
[http://www.youtube.com/watch?v=fwcl17Q0bpk](http://www.youtube.com/watch?v=fwcl17Q0bpk)

~~~
DyslexicAtheist
oh wow that is awesome background context. thanks!!

------
merpnderp
How does this compare to something like cryptocat?

~~~
tptacek
It is basically cryptocat.

~~~
garrettr_
Have you taken a look at Cyph (mentioned elsewhere in this thread)? Their app
is also basically cryptocat, but they've taken the time to engineer an
interesting solution [0] to the "Trust on Every Use" problem that secure web
applications have.

Of course, you still have the problem of deploying a secure application within
the attack surface minefield of a web browser, but that's a separate issue.

[0]:
[https://docs.google.com/document/d/1PGS50eZB9Ud7wVKmrc0HU_FD...](https://docs.google.com/document/d/1PGS50eZB9Ud7wVKmrc0HU_FDygZkyuFjmTRrukAz3sw/edit)

~~~
tptacek
Secure messaging has to work. All the time. If your threat model is criminals,
Gchat will protect you just fine. You use encrypted messaging to prevent
governments from reading your messages. Look at the Telegram/Iran fiasco for
an example of this.

So: my recommendation is, never use any secure messaging system that boots off
a web page. No matter what they claim to do to mitigate the risk.

I'm actually, for a bunch of specific reasons, not super comfortable with
browser extension applications either. But at least the browser _tries_ to
protect an extension you have to explicitly install and explicitly run.

------
lampe3
when i try to go on the page with the latests firefox nightly:
[http://i.imgur.com/FsLiIz8.png](http://i.imgur.com/FsLiIz8.png)

~~~
dchest
Firefox bug:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1238354](https://bugzilla.mozilla.org/show_bug.cgi?id=1238354)

