Skip to content

Comment on Cryptocat Considered Harmful: The Root Causeparent

Comments

You sure are extracting a lot of things from my comment that I actually didn't say.

I don't think anyone is above criticism, nor do I think truly understanding how a piece of software works is "very easy." All I'm saying is that we see criticism of Cryptocat over and over, yet, here we are, with people still using Cryptocat.

The author wants Cryptocat shut down, but if that happens, what will the people using Cryptocat do? Communicate in plaintext? Isn't it irresponsible (and in line with your own reasoning about putting people in danger) to not present the users with a better alternative first?

I don't see that he wants it shut down - all he wants is to be made sure that people are aware of the risk. If your alternatives are to communicate in plaintext-equivalent (that is, broken crypto) while thinking you are protected or to communicate in plaintext, knowing that eavesdropping is possible, the latter is the better alternative! And there are even more alternatives already, like meeting people in person, or using PGP, or any number of things. Even using cryptocat while knowing that it is not reliable is better. There are tons of options right now, and the worst of them is to use an unreliable protection while thinking it is protecting you, hence the criticism.

All I'm saying is that we see criticism of Cryptocat over and over, yet, here we are, with people still using Cryptocat.

People make poor decisions all the time. The fact that people use Cryptocat might indicate that it has good marketing; it might indicate that it has a good UI; it might indicate that people are responding to network effects in communications. What it doesn't do is contradict the security criticism of Cryptocat. It's irrelevant to the question of whether or not Cryptocat is secure.

The author wants Cryptocat shut down, but if that happens, what will the people using Cryptocat do? Communicate in plaintext?

They are already effectively communicating in plaintext; it's better for them to have to do so, and be forced to recognise the fact. Someone who lives in an oppressive regime and incorrectly believes his communications secure may very well betray himself; someone who lives in an oppressive regime and believes his communications insecure is less likely to do so.

Isn't it irresponsible (and in line with your own reasoning about putting people in danger) to not present the users with a better alternative first?

It's more irresponsible to give them a false sense of security, and lead them into deadly danger.

It really is quite simple: at some point, Cryptocat's bad marketing will cost more human beings their lives than good marketing would; at some point, Cryptocat's bad design will cost more human beings their lives than good design would; at some point, Cryptocat's bad implementation will cost more human beings their lives than a good implementation would. Those lives are IMHO far more important than the warm-and-fuzzy convenience of easy-to-use but insecure communications.

They are already effectively communicating in plaintext

Got anything to back up this statement, or is this what you're inferring from the post and the analysis of the group chat component a while back? Are you saying that the OTR implementation in Cryptocat leaks the plaintext? That would be very serious.

Also, I don't disagree about misleading messages, but take a look at https://crypto.cat/ and tell me if the content on there is misleading compared to the messaging of many other security software companies.

> They are already effectively communicating in plaintext
Got anything to back up this statement, or is this what you're inferring from the post and the analysis of the group chat component a while back?

That flaw meant that key-guessing was easy, and with an easily-guessed key even the best-encrypted data becomes plaintext.

Given the numerous flaws so far found in Cryptocat and the quality of its code, I wouldn't trust my treasure, freedom or life to it.

Indeed, the PRG was flawed, but IIUC, this applied to only the RSA key generation used for group chat, not OTR, which is what cryptocat is mainly used for.

People reference "numerous flaws" a lot, but it all seems to lead back to the criticism of group chat from a while back. I'm not saying you're wrong--just be careful of the echo chamber.

The author wants Cryptocat shut down, but if that happens, what will the people using Cryptocat do? Communicate in plaintext? Isn't it irresponsible (and in line with your own reasoning about putting people in danger) to not present the users with a better alternative first?

First of all, I personally think that if you have to use Cryptocat that you might want to exhaust all other options before using it.

Second of all, if you're already in a compromised situation, do you want to use a compromised communication medium? It doesn't seem sensible.

Lastly, there are alternatives to Cryptocat:

https://otr.cypherpunks.ca/

This is actually created by someone with a clue and isn't full of cutesy icons and faux Amiga designs.

Ironically, OTR is what Cryptocat uses. But for the sake of argument, let's compare it to the OTR plugin for Pidgin, another IM: It's just not as usable. I'm sorry. Look at the very website you linked!

But... it's possible to make it just as easy to use! Or even better: To make a minimal client that accomplishes the same as Pidgin without presenting as large of an attack surface.

Glenn Greenwald nearly missed out on the biggest national security story of the past decade because he couldn't figure out how to get PGP to work. Yes, we can expect people to put a little more effort into protecting themselves if they genuinely believe they're at risk, but we can't expect to do things they can't do. Not everyone is a techie.

OTR is only used in one-on-one communications in CC; group chat mechanisms are custom, and may now converge towards the mpOTR draft but that's still a pretty big risk.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.