Wanting hard problems to be easy doesn't make them easy. Computer science and math don't care how much you need cryptography.

And, a reminder: while I agree that we could use better UX for GPG, that's not what Cryptocat is. Cryptocat is simpler to use because it's a simpler, less secure system.

The Cryptocat team seems to have a flair for attractive, usable interfaces, and people seem to like the way Cryptocat works. They should spend their time building a similar interface for GPG and give up on the custom cryptosystem. They wouldn't be able to say they'd designed their own cryptosystem, but in reality, people with a professional understanding of cryptography would think more highly of them for that, not less.

I thought they actually had given up a custom cryptosystem and went with OTR (for person to person chats)? Although only after a year or two of crying about how the community was meaning mean to CryptoCat, etc. and viewing every bug report as a personal attack.

The problem is there is no "mpOTR" for them to switch to for multiperson. I'd argue for SSL protected IRC (like, SILC) and some kind of transparent/tamper-evident server on an .onion as an interim measure, instead of a roll-your-own alternative.

GPG supports multi-recipient encryption.

Without perfect forward secrecy. I'd probably take perfect forward secrecy over not needing a trusted third party for the protest use case, although neither is ideal.

It's easy to fetishize forward secrecy, but the reality is probably that forward secrecy is much more important in the context of TLS, where the lost of a single key might compromise billions of messages, than it is in the desktop case, where losing your key to an attacker also lost your keyboard inputs forever.

Or in a scenario where seizure of a device is likely incident to arrest (i.e. your mobile phone), or where the key is stored online, or where your key is derived from a passphrase.

Resistance to compelled disclosure (at least for historical stuff; they could still turn someone and force him to chat with people with an FBI agent watching over his shoulder...) is the benefit for PFS in the user to user case.

> Cryptocat is simpler to use because it's a simpler, less secure system.

Simple does not need to mean less secure. HTTPS is easy (for the user) and secure.

> They should spend their time building a similar interface for GPG and give up on the custom cryptosystem

Yes, that could be an approach, using a higher level crypto infrastructure and focusing on the UX.

No, that's not true. HTTPS is simpler than GPG and also provides less security. You rely on HTTPS/TLS today with certificate-pinned DHE HTTPS connections to Gmail. Clearly, the people who use Cryptocat don't feel like they're getting enough security from Gmail. HTTPS is simpler to use because it's a simpler, less secure system.

How much less secure exactly? Certificate pinning certainly helps in some cases (unless the pinning itself is attacked, which may be possible).

You just seem to be confirming my point, that in the name of "more security" they're shunning everything that's not their idea of "perfect security" (which may be faulty). Result: less people using encryption.

It's one thing to use a fragile encryption key like the Cryptocat failure, another to exclude RSA in favour of ECC (except if you're dealing with leaking government secrets of course)

I don't know how to answer this question. I'm not sure what you mean by RSA and ECC. The answer to how much more secure GPG on your desktop is than TLS to Gmail is "much more secure".

The question can be answered in terms of "how many people do I need to trust in each case for my communication to remain private?" In the former case, it's "the intended recipient" and in the latter case, it's "a few thousand people".

RSA refers to Rivest-Shamir-Adleman and ECC refers to Elliptic curve cryptography. They are both algorithms which take different approaches to public key cryptography. RSA has been in use for longer than ECC and it's considered to be more well understood. However there are some exciting things going on with ECC, for example it is thought that you could have the same or better security as RSA with a much smaller ECC keysize.

Using 521 bits with ECC is comparable to 15000+ bits with RSA.

SSL has various problems, mostly related to CAs. Also it is only easy to use because the server admin has done the hard part for you, therefor you have to trust them.

To apply SSL to a cryptocat style system would require both parties to generate keys and somehow verify them, not so simple.

While I think SSL/TLS is "less secure" in some sense than GPG, which is fundamentally end-to-end, I still think SSL/TLS is a good system, if for no other reason than that it's the focus of a huge amount of research.

The CA problems with HTTPS/TLS aren't fundamental to SSL/TLS. They're a consequence of browser UI. If you build your own software that uses TLS to make secure connections, you have a variety of options to avoid the browser CA problem; you can run your own CA (every instance of Burp Suite, the industry standard web pentest tool, does exactly that), or you can verify certificate fingerprints statically, or you can invent a new authentication system.

Yes, that's a good point. However you are always somewhat reliant on a third party to do the security for you whether that is a CA or an app developer. That third party has to be trusted. It doesn't solve the fundamental problem of:

Alice -> Bob

without doing.

Alice -> Facebook -> Bob

Unless both alice and bob know how to generate and manage their own keys (and verify each others keys).

No, also not true. You can use the TLS protocol to build a "web of trust" scheme just like GPG's out of self-signed certificates and key continuity.

Right, but web of trusts/PGP are inconvenient in a way that "look for the padlock icon" isn't. Which is likely why they are not in widespread use by the general populous.

> Because the crypto people usually don't care

It's not because crypto people don't care, it's because privacy is hard.

Say you and a friend are in opposite corners of a crowded room and you have to somehow come up with a mutual secret by yelling at each other with everyone listening. Do you think you'd be able to design a way to do it? Thanks to Diffie and Hellman, that's not only possible, but rather easy.

Do you think you could design a seamless way for all your snail mail to be private, even when the post office has an unlimited budget and its #1 priority is to read your mail? I'm pretty sure you'd make some concessions, such as "you have to lock it in a box before sending", and then make sure the recipient had the corresponding key, etc etc. Saying "these security guys make me jump through all these hoops, if they cared about me I could just send the exposed letter and it'd somehow be secure" is not only unfair, but completely unrealistic.

They should be commended for trying to make security accessible.

I strongly agree with you.

Unfortunately they have made security less accessible.

Why are they rolling their own crypto, and not trying to make some existing product easier to talk?

> At least the documentation warns it's really a bad choice.

It seems the warnings are small and the hype is big.

>Making technology accessible to everybody is very important

What if the technology is fundamentally flawed and the users are at risk for using it?

GPG and such are terrible to use, imo, but at least they work. CryptoCat could be exploited with relative ease, at least at times. Considering their considered demographic, this is quite dangerous.

"Making healthcare accessible to everybody is very important"

So we should commend young, inexperienced kids with no medical training and an obviously deeply flawed understanding of neuroscience - for bringing easy-to-use "home brain surgery kits" to "regular people or even non-experts".

"At Trepan-o-cat, we've undertaken the difficult mission of trying to bridge the gap between practical first aid kit use, and frontal cortex lobotomy. This will never be easy."