MEGAChat now includes end-to-end encryption • Hacker News Board

Re: MEGAChat now includes end-to-end encryption

#71

Post by Freak_NL » Sat, Jan 23, 2016, 9:51 PM UTC

c22 wrote: post #68

zanny wrote: post #54

Earlier quoted context omitted.

Thats why you cannot expect them to understan PGP and PKI. You want a sane default that can secure 99% of people and expose the guts to the last 1% through options menus. The perfect PGP secure email client would be cross platform and provide its own email server. The client has included trusted keys to communicate with upstream, but when you first start it you make your account and that generates you a signing and e…

> The perfect PGP secure email client would be cross platform and provide its own email server. The client has included trusted keys to communicate with upstream, but when you first start it you make your account and that generates you a signing and encryption key based off your password, backs it up on their server (remember, its password protected, they cannot access it despite backing it up) and then whenever you…

If the FIDO U2F standard takes off, we may just see this happen. U2F keys do not include the functionality to hold OpenPGP keys, but they could help in having people understand the notion of a keychain for security.

Re: MEGAChat now includes end-to-end encryption

#72

Post by buu700 » Sat, Jan 23, 2016, 9:57 PM UTC

sdevlin wrote: post #70

buu700 wrote: post #66

Earlier quoted context omitted.

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,…

Cure53's report details a complete bypass of WebSign as implemented, as well as stern warnings against relying on a non-security feature for security.

Not denying the increased attack surface, but that bypass was immediately fixed and verified by Cure53 (so no known vulnerabilities exist); furthermore, as you'll see in both our foreword to that report and the linked reddit comment, the current version of WebSign actually no longer has that general flaw.

Breaking WebSign would require defeating TLS public key pinning (which is a security feature), thanks to the technique that an email I just received so perfectly referred to as "HPKP suicide".

Re: MEGAChat now includes end-to-end encryption

#73

Post by tptacek » Sat, Jan 23, 2016, 10:47 PM UTC

buu700 wrote: post #66

tptacek wrote: post #63

Earlier quoted context omitted.

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 a…

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,…

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.

Re: MEGAChat now includes end-to-end encryption

#74

Post by tptacek » Sat, Jan 23, 2016, 10:50 PM UTC

eganist wrote: post #64

tptacek wrote: post #63

Earlier quoted context omitted.

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 a…

There are plenty of casual users who want the capability to have one-off conversations without worrying about who might be intercepting and storing the conversations, let alone without having to install anything new and try to convince their friends to use it too. This is made with them in mind. I see where you're coming from with the added attack surface argument, though I'd counter that browser sandboxing actually…

If you want to have a one-off conversation without worrying about someone intercepting and storing your conversation, use Google's IM protocol. You won't have to install anything.

If you want to protect your communications from the kinds of adversaries who can defeat Google's security, you're talking about a class of adversary that is largely government sponsored, and all of them are likely to be able to compromise a messaging application that boots from a web page.

For those serious adversaries, users need real secure messaging solutions, and today, they need to install software to do that.

Re: MEGAChat now includes end-to-end encryption

#75

Post by DyslexicAtheist » Sat, Jan 23, 2016, 10:50 PM UTC

Kristine1975 wrote: post #32

DyslexicAtheist wrote: post #20

Earlier quoted context omitted.

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

Which wasn't illegal at that point, though.

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

Re: MEGAChat now includes end-to-end encryption

#76

Post by buu700 » Sat, Jan 23, 2016, 10:51 PM UTC

tptacek wrote: post #73

buu700 wrote: post #66

Earlier quoted context omitted.

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,…

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 brows…

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.

Re: MEGAChat now includes end-to-end encryption

#77

Post by DyslexicAtheist » Sat, Jan 23, 2016, 10:52 PM UTC

lindx wrote: post #50

DyslexicAtheist wrote: post #22

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

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

oh wow that is awesome background context. thanks!!

Re: MEGAChat now includes end-to-end encryption

#78

Post by tptacek » Sat, Jan 23, 2016, 11:00 PM UTC

buu700 wrote: post #76

tptacek wrote: post #73

Earlier quoted context omitted.

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 brows…

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 nati…

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.

Re: MEGAChat now includes end-to-end encryption

#79

Post by buu700 » Sat, Jan 23, 2016, 11:25 PM UTC

tptacek wrote: post #78

buu700 wrote: post #76

Earlier quoted context omitted.

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 nati…

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…

There are very specific concerns I have about implementing secure cryptography in a browser runtime. ...

What are your thoughts on our strict uses of asm.js for the actual encryption (libsodium) and static typing for the rest of the code via TypeScript?

I'm aware that asm.js isn't literally native code, but we and, (without putting words into their mouths) I believe, the Cure53 team felt that these were both very effective mitigations to the risks you point out. Combined with a strong CSP and an entirely Angular-based UI (so no silly mistakes like untrusted user input in jQuery selectors, and to date no known XSS), I would say that Cyph is vastly different from a project like Cryptocat.

As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces!

It was an accident, in pre-production code. (And hardly "nightmare"-level; it was one nonce reuse that only occurred during the initial handshake, and notably wasn't obviously exploitable.) That was also the only bug found by 5 experts over 12 days in the entire protocol implementation[1], which I would say is more impressive than not.

The whole point of that audit was to catch those sorts of silly mistakes before we switched away from OTR in prod.

This also has nothing to do with WebSign or the impact the browser has on our attack surface; we could very easily switch back to the asm.js libotr cross-compilation we'd been using if Castle turned out to be unfit for production.

---

1: There were three Castle-related findings, but only one was in the Castle implementation. One was an outdated/no-longer-correct statement in a document and one was a configuration weakness elsewhere in the code.

Re: MEGAChat now includes end-to-end encryption

#80

Post by eganist » Sat, Jan 23, 2016, 11:44 PM UTC

tptacek wrote: post #74

eganist wrote: post #64

Earlier quoted context omitted.

There are plenty of casual users who want the capability to have one-off conversations without worrying about who might be intercepting and storing the conversations, let alone without having to install anything new and try to convince their friends to use it too. This is made with them in mind. I see where you're coming from with the added attack surface argument, though I'd counter that browser sandboxing actually…

If you want to have a one-off conversation without worrying about someone intercepting and storing your conversation, use Google's IM protocol. You won't have to install anything. If you want to protect your communications from the kinds of adversaries who can defeat Google's security, you're talking about a class of adversary that is largely government sponsored, and all of them are likely to be able to compromise a…

> all of them are likely to be able to compromise a messaging application that boots from a web page.

All of them are likely to be able to compromise your OS, the Intel Management Engine (http://hackaday.com/2016/01/22/the-trouble-with-intels-manag...), your flash drives, the baseband on your blackphone... There's so much code, so many layers of abstraction involved in doing even the most basic things and so many things for which the US IC (let alone the 5E) almost certainly has exploits for that this quoted line is entirely moot when put in the context of attack economics.

I was looking for any insight you might have into why a web application with the latest in protections surrounding the execution of unauthorized code and running in a sandboxed browser would still be more vulnerable compared to a native application running in usermode, but then you said...

> and today, they need to install software to do [address serious adversaries].

I guess I can keep looking forward to someone else to address the point you tried to raise, since your position seems to be more of an emotional one. The only way we'll be able to advance privacy is by advancing ease of use. Web applications do a good job of providing that, and the IETF and browser makers are doing an excellent job of creating and integrating security standards to allow developers to bring that ease of use to realms of secure computing which traditionally required extensive manual configuration.

Do you want wider adoption of security and privacy-assuring technologies by the general public? Be like the rest of us in the AppSec community and support the devs who try to advance the state of the art.