Cryptocat Considered Harmful: The Root Cause
datavibe.net
datavibe.net
Make formal security proofs, implement them, open source your prototypes, and have them vetted by as many cryptographers as possible (so one or two if you're lucky.) Then figure out how to market your product.
By far the hardest aspect of cryptography engineering is getting people to use your software in the first place. It doesn't matter how good you are at crypto if your software is never used.
It's very easy to criticize. Much harder to actually make more secure, more usable alternatives. (And, ironically, the people who ought to be doing this the most are much more hesitant to do so since they know of many more subtle ways to make mistakes.)
I think perhaps a neglected aspect of the problem is how to turn difficult social / political problems (eg. nobody uses PGP and people think you're a weirdo if you try to persuade them to) into tractable technical problems (the kind cryptographers mostly talk about). I sometimes think it would be preferable to start from a point where everybody had public and private keys and knew how to use them, but the crypto was no better then ROT13, than the current situation where the crypto is pretty good but getting people to use it is nearly impossible.
I also think the emotive "bad crypto puts lives at risk" argument only really makes sense if you're talking about crypto for the military or a small number of political activists, who will in any case benefit if their encrypted transmissions are buried among everybody else's. Those people need to be more careful than the rest of us with our more quotidian privacy concerns. I would rather have more bad (but tractable) crypto than great crypto that is used by nobody.
Hopefully somebody will persuade me I am wrong about this so I can stop feeling like a crypto heretic.
Also, a part of the social/political problem is that people tend to not know that the crypto they are using is bad, and political activists tend to not necessarily be cryptography experts either, so how would they know that they are in danger when everyone around them tells them that the broken crypto they are using is the thing to use?
> Also, a part of the social/political problem is that
> people tend to not know that the crypto they are using is
> bad, and political activists tend to not necessarily be
> cryptography experts either, so how would they know that
> they are in danger when everyone around them tells them
> that the broken crypto they are using is the thing to use?
But there is always going to be a problem with telling people "use our software and you can organise the overthrow of your government without fear". There is no way around the fact that people who are doing that need to understand the risks better than most people do.
(How are you supposed to blockquote text on HN?)
As for the fact that people who do risky things need to be a bit more cautious anyway: Well, yes, but that does not mean that they would not benefit if everyone knew which crypto tools are secure and how to use them, and in contrast to most of physical security, there really is not that much need to distinguish between "professional" and "end customer" tools - proofing your vault against bombs might be a bit more expensive than proofing it against a burglar, but secure cryptography does not need more expensive computers or anything like that.
And also no clue how you to quote here ... ;)
There is also TextSecure (https://whispersystems.org/), but it requires text messaging.
Agree that TextSecure and Redphone are great tools, albeit in different categories, and as far as I can tell their implementations are sound.
Also, suppose some new appliance regularly killed its users due to bad electrical isolation. Would you use the same argument when someone criticizes the manufacturer of that appliance? People doing things in a way that harms others is beyond criticism unless you yourself are doing things better? You wouldn't complain if your doctor treated you incompetently unless you could do it better yourself?
Also, your basic premise is flawed: Making valid criticism is not "very easy", but also often requires considerable expertise, which in turn takes considerable work to acquire. But that doesn't matter anyhow: Criticism either points out actual problems or it doesn't, it's completely irrelevant to its validity how much work went into it.
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?
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:
This is actually created by someone with a clue and isn't full of cutesy icons and faux Amiga designs.
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.
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.
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.
> 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.
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.
Of course, if that was the case, the edge of your response is blunted, because then responsibility for that failure is more distributed.
It's not that black and white. Yes, usability tends to carry with it some measure of sacrifice in security, but Skype used to have a lot more security, and was as easy to use as it is today. They're not absolutes. You can have "quite usable and very secure" and "very usable and quite secure", things none of the apps we're discussing are.
I don't have any big concerns with OTR (aside from the inability to do offline messaging,) just the implementions, mainly OTR in Adium. OTR in Pidgin appears to be decent, but hasn't received a lot of review, as far as I know, and Pidgin has its own problems/provides its own attack surface.
I think it's misleading to insinuate that security is an absolute, but, again, you're missing my point. I'm not telling anyone to use Skype. I'm saying that the added security didn't come at a cost to usability.
> for the NSA to intercept everyone's messages while it was more distributed would have required releasing a version update and waiting for the supernodes to pick it up, but that's not a high bar.
I would say that your bar is very high, then. This would defeat nearly everything that exists and is in use today.
Also, there's probably no one in the world that can actually defend themselves against the NSA if the NSA is determined to know what they, specifically, are doing.
What added security? I didn't say it's impossible to be easy and as safe as older versions of skype (which is to say, not very). I said it's impossible to be easy and safe. (In particular, you need some kind of key fingerprint checking, and no-one's found an effective, user-friendly way to do that).
> I would say that your bar is very high, then. This would defeat nearly everything that exists and is in use today.
It wouldn't defeat GPG, or OTR-based systems used in reasonably popular open-source clients.
> Also, there's probably no one in the world that can actually defend themselves against the NSA if the NSA is determined to know what they, specifically, are doing.
Sure. But let's look at a realistic threat model, and at what's actually happened: the NSA did intercept all communications channels run by individual providers, including skype. The NSA was prepared to demand these providers deploy new backdoors into software they distributed that didn't currently have them, as we saw with lavabit and RSA, and when lavabit refused they were shut down. The NSA were not terribly effective at compromising open, respected standards (they did succeed in getting a broken algorithm standardized, but the main reason this wasn't noticed is that hardly anyone was using it, and even then questions were being raised in the crypto community), and did not compromise GPG or similar open-source projects. Nor did they tap users of those systems indirectly by compromising their email clients or similar. Observe that Snowden, with inside knowledge, chose to use PGP to communicate with journalists, and this did in fact provide sufficient security.
Meaningful security is possible. Skype isn't it.
Until you consider where GPG and OTR are used, e.g. Enigmail or Pidgin, addons or clients which both autoupdate or ask to be updated.
There are very, very, very few pieces of software that either don't need to be updated, or can't trivially be backdoored by the vendor itself through updates.
You keep going back to "Skype didn't have security"--and I can't tell if you're trolling, or what--but you can't seriously harp on it for auto-updating. So does Chrome, and it's lauded for auto-updates (the downside of not updating is obviously that security issues aren't fixed, arguably a much bigger risk than the vendor backdooring the software in later updates.)
I can't speak to those; I use KMail and Kopete, neither of which auto-updates. My OS does ask to update those packages, but it will only do so with my explicit intervention, there's a code signing process in place (and any bad updates would be traceable to individuals rather than an institution), and the people who run it are based outside the US.
The "cutesy" icons and flashy colours that Cryptocat displays are really nothing more than lipstick on a pig.
As a user, I just want to be able to message another person, over the internet without having to worry about setting up plugins or setting up any kind of keys. I want to add them to my friend list, click their name, send them a message and be comfortable in the fact that my communication cannot be intercepted.
/s
..than communicate in plain text? Yes.
Where's the alternative? We can have Cryptocat shut down, which is what the author is suggesting, but then what are we (and by that I really mean people who currently use Cryptocat) going to do?
You would prefer to communicate in plaintext-equivalent where you think nobody can read it even though in fact everybody can over communicating in plaintext where you know everybody can read it?
I think it is somewhat naive to believe that any mechanism other than a one-time pad will absolutely keep your communications safe, and that it's a little dangerous to insinuate that Cryptocat leaks information about the plaintext but X or Y doesn't.
He makes the very valid point that advertising a insecure product as secure to people who need security but don't understand it is very wrong. He's asking that the advertising be corrected.
We're not worrying about your credit card getting ripped off - this software claims to solve life or death problems.
I don't disagree with the point that you shouldn't pretend, but literally no one is in a position to make absolute promises like that, yet everyone's doing it.
I'm not saying it's okay, but let's keep in mind that they say on their frontpage (http://crypto.cat) that you shouldn't trust it with your life. That's better than most security software marketing.
The people at heml.is are looking at implementing something like TextSecure as an IM, and its interface does look quite attractive, but it's a no-go as long as they're not open source (especially given that none of its authors are cryptographers), and thus can't receive a thorough review. (Actually getting qualified people to perform a review once it's open source is a challenge in itself, but perhaps people will spend more of their energy on that than writing blog posts saying they could do it better.)
The problem isn't that nobody understands that, the problem is that that's a very difficult (arguably impossible) problem to solve.
https://news.ycombinator.com/item?id=5776111
Edit: another thought, looking at the incentives involved:
* If you, as a security guy, spend your time breaking stuff, you win some points for that if you score a 'hit'. If you don't, well no one is really paying attention. Pretty much all systems - even those written by really bright guys like cperciva - have flaws, so if you look enough, you'll probably find some.
* If you write your own system, you attract the attention of all the people out to break it. And eventually they probably will find some problem and write Comic Book Guy style posts about how the system is badly flawed. And your reputation will suffer.
I have nothing against criticism. If there's a flaw in something, let's talk about it. But I don't care for "I know how to do it better," and nothing more.
I'm still waiting for simple, usable crypto - but I'm not willing to settle for evidence-free, warm assurances of safety from borderline incompetents in the field while I wait for it.
>I can't help but think if security researchers spent as much time on creating usable, secure software as they did in proving that other's implementations were flawed we'd be in a much better place.
Can this comment be part of the HN crypto thread drinking game? It's in every thread x10. I can't help but think if commenters spent as much time learning how to use good crypto as complaining about the time researchers spend picking apart bad crypto, all of their issues with the current implementations would disappear.
Not really, because each commenter here interacts with 10's if not 100's of people who have little to no chance of learning to use good crypto.
After listening to Glen Greenwald at the CCC it was quite clear that cryptography that is easier to use than PGP is really needed in this world (he almost lost the Snowden story due to it). I think that Nadim needs to be encouraged. Sure, point out any flaws but aim for constructive feedback.
The points here centre around it "not good enough". This is a bit of a chicken and egg problem and isn't really helpful.
The issues are, to put it mildly, insurmountable. The environment is simply too toxic to trust. Between standard Web security flaws, timing attacks (what happens when one context can detect the timing of another? Remember, the code is slow, so your resolution doesn't have to be good), inadequate random number generators, an inability to securely manage memory (don't want key materials floating around), etc.
I'd rather trust Bob's Discount Car And Certificate Authority than JS crypto.
I agree that the "world" could benefit from an easier to use cryptography product than PGP (event thought I'm fine with PGP) and I think that this post is valid criticism.
Disclaimer: Not a cryptography expert in any way, neither annoyed by the fact cryptography is hard and will probably benefit from processes like peer-review.
Slightly off-topic, but this is one of those areas that bugs the hell out of me, and I don't know the solution. On one hand, security and cryptography people tell lawmakers and those in authority that crypto is math, anyone can do it, it's silly to try to regulate it, etc. On the other hand, these same experts tell the "anyones" of the world not to implement their own crypto, mistakes are easy to make, correct implementations are hard ...
Here's the kicker for me: If you absolutely should never release another piece of software that might have bugs that could endanger someone's life, then you'll never release another piece of software. You can become the greatest cryptographic implementor on the planet, implement to the current state of the art, and, in a couple years, still have your work completely obliterated by a new attack against a cryptosystem that you are using correctly.
For all I know this guy could be totally right about Cryptocat, but this is absolutely not the way to make this kind of statement. It isn't well-reasoned and it sure as shit isn't informative.
"I remember a conversation with Brian Snow, a highly placed senior cryptographer with the NSA. He said he would never trust an encryption algorithm designed by someone who had not earned their bones by first spending a lot of time cracking codes. That did make a lot of sense. I observed that practically no one in the commercial world of cryptography qualified under this criterion. "Yes", he said with a self assured smile, "And that makes our job at NSA so much easier." A chilling thought. I didn't qualify either. "
https://www.schneier.com/blog/archives/2011/04/schneiers_law...
edit:
By the way I think that Jeffrey Paul has a relevant point, I think it deserves to be taken into account. I understand his words can hurt Nadim Kobeissi nevertheless from my point of view they carry no such will.