Dear Cryptocat Users
crypto.cat
crypto.cat
Cryptocat Considered Harmful (2013) https://datavibe.net/~sneak/20130717/cryptocat-considered-ha...
Except: Today, Cryptocat is not for everyone.
Cryptocat is under active development, and is suitable only for
debugging and software experimentation. It is not suitable for
those who desire communications privacy. (This may change 2-5
years in the future, following sufficient peer review.)
Cryptocat has had myriad errors in implementation, spanning the
entire time it has been under active development. Note well that
this is not a criticism: cryptosystems are notoriously difficult
to get right, and it takes a very long time, significant
experience, much peer review (on top of that significant
experience), and lots of sweat and iteration to build systems
that are safe to use.
Schneier post on the adoring media coverage of cryptocat (2012) https://www.schneier.com/blog/archives/2012/08/cryptocat.htm...
† Despite looking like this yesterday: https://web.archive.org/web/20160205030908/http://crypto.cat...
I hope that not only will this new product of his be developed with "A pure vision of democratized, pleasant secure messaging", but also that he has matured significantly. I hope that Cryptocat v3 will come out after it has been thoroughly audited by several reputable third parties.
Most importantly, I hope their crypto is boring.
https://security.stackexchange.com/questions/6095/xkcd-936-s...
This is not true. Pasting the certificate of your friend in a field does not require intricate knowledge of GPG.
> Security at the expense of usability comes at the expense of security.
It got the usability part down, it just wasn't secure. And I wasn't claiming it was.
1. Go to the right site. So, tell them to check domain and HTTPS.
2. Type in information you and other person agreed to preferably in person.
3. Chat.
Very, very usable. That could've been implemented in a simple, secure-coded app communicating over a secure tunnel with another simple app on a robust server. The crypto to do that sort of thing right (outside a browser) is pretty basic. One could even run the deployment server and untrusted storage separately so complex TCB couldn't affect trusted app delivery or operation. Not past availability.
Cryptocat's design was actually simpler than some high assurance systems of the past. That tells me it could be done robustly with a different implementation and protocol. Is it the best idea? Hell no for all kinds of reasons that start with centralization then get worse from there. Its usability can be recreated, though, in a more secure solution.
Note: As I said to tptacek, even the original with its security issues kept users safer than fads like Facebook Chat that spy on them. A fun, usable solution with better than average privacy is still a step up if used by the right people. Just gotta be clear to use something stronger (less fun) to stop hackers.
Something like: "Usable secure systems are created by iterating from secure unusable systems, not by iterating from insecure usable systems." Someone must have said something like this before, and put it more eloquently.
That leads to other side: what is a secure messenger? Secure against WHO? If it's hackers, then Cryptocat is entirely inappropriate as it will be smashed. Yet, average person's threat model includes all kinds of snoops that might not have hacking skill not to mention the service host. Especially in high school & college. Cryptocat would protect them from many of those while its own problems would be found and improved over time. Widespread adoption of Cryptocat over services like Facebook Messenger stashing & analyzing the messages would be a win in privacy.
So, the question is use case. I gave it a positive review for potential to get insecure crowd on something a little better. It was also fun thanks to good art. I just said they should clearly indicate it's not for stopping hackers, governments, etc. Plus keep links to good products that are. If people want those, they'll use them. If not, Cryptocat wasn't a bad fallback compared to straight-up invasive apps they were likely using.
Let me put a bullet right in the head of this argument in favor of Cryptocat and things like it:
In June 2013, Cryptocat was used by journalist Glenn Greenwald while in Hong Kong to meet NSA whistleblower Edward Snowden for the first time, after other encryption software failed to work.
And, you know what else? Guess what happened right around June 2013? Decryptocat.
If a secure product could be as user-friendly as Cryptocat was while still being secure, then most peoples' communications would be more secure.
That's all I was saying. I'm not trying at all to hand-wave the proven insecurity. I'm saying that the only thing they got right was the one thing that secure products have consistently gotten wrong. (Barring Signal.)
That's my main claim. Usability and setup phase were between 90-100% of my positive remarks on it in my review. I just added it still has value for crowds without tech-savvy opponents if (a) they won't use truly secure stuff due to hassle and (b) they are clearly informed usable but weak tools can be breached. As one of a few interim solutions if nothing else.
"after other encryption software failed to work."
Nothing else worked because all your recommendations were unusable. It was using Cryptocat because it might be private or doing open communications that wouldn't be private. There was also a time window.
"Guess what happened right around June 2013?"
They completed the meeting without the NSA getting shit. Greenwald got the data. Snowden escaped. Comms remained private until an NSA analyst discovered both the intercepted data and Decryptocat. It worked.
Great story. Now, what app do you recommend for a future Greenwald that's so easy to correctly acquire and use that I could give my grandmother a 3-4 step flashcard and she get through it without help & minimum hassle? Cryptocat passed my granny test. Nothing else on a desktop did so far.
Script kiddies get their name because they only make use of easy-to-use tools written by knowledgable "hackers" that perform tasks that are vastly beyond the understanding of the kiddie. If your "secure communications" software doesn't stop a sophisticated passive adversary, it doesn't stop anyone, because a sophisticated adversary will inevitably release a point and drool tool that anyone can use to unscramble your data. [0]
> They completed the meeting without the NSA getting shit. ... Comms remained private until an NSA analyst discovered both the intercepted data and Decryptocat.
So, then the NSA did "get shit". They may not have gotten it in a timely manner, but they did get the plaintext of the conversation.
> Now, what app do you recommend for a future Greenwald...
TextSecure/Signal has been around since 2010. It walks you through the setup process, so no need for flashcards. Unlike Cryptocat, its crypto has stood up to scrutiny. It doesn't currently meet your "on a desktop" search criteria but:
1) It seems reasonable to expect that most journalists possess either an iOS or Android smartphone.
2) There is a Signal desktop client in development that's currently in population-limited beta testing. From what people tell me about how WhatsApp handles the interaction between its mobile clients and desktop client, Signal's desktop client is every bit as easy to use as WhatsApp's.
[0] Granted, Decryptocat likely has to be used by someone running code in the Cryptocat datacenters, but this does not invalidate my objection to your assertion.
So every non-technical person right now wanting others' conversations in various insecure apps are running full surveillance on them with control of their PC/phones because the NSA and other teams are? And NSA et al turned all that into script kiddie warez published openly with easy Google access? No they're not. Those that are make up a tiny, tiny few. So, you're argument is simply wrong.
Mediocre solutions stop people all the time despite pro's or talented people being able to defeat them. A subset of them get attack kits made by black hats or security professionals. A subset of that gets released into the wild. A tiny subset of laypersons find those and learn to wield them. Sometimes those tools require more access than they have, sometimes not. There's no all-or-nothing game with what happens using certain apps or security strategies. Lots of variation in risk. Your threat model, what software you're using, and how you're using it matters a LOT in determining what will actually happen.
Incidentally, this is why the Mac users felt immune to malware so long despite lots of popularity, business data up for grabs, and terrible security. If your argument was correct, they would've gotten owned massively and regularly in botnets that were on par with Windows if not worse. They didn't, though. The weakness and possibility of an attack didn't materialize into even large gains by hackers: just a little botnet or two in PPC days. Laypersons certainly didn't know about ways to own them all with easy tools. Actually, over all proprietary & FOSS in use, that appears to be an uncommon or rare event.
Note: I know people that to this day use PPC Mac's and old software in a hardened configuration with backups. No evidence that anyone has trashed their system so far. Plus, the laptop users would notice if lots of streaming was going on given the terrible battery usage of those. So your hypothesis is still failing for them going on over a decade.
"So, then the NSA did "get shit". They may not have gotten it in a timely manner, but they did get the plaintext of the conversation."
The requirement was that the NSA not be able to understand the content of those messages for a period of time that covers their activity. The NSA's goal is to spot stuff like this before it becomes a huge problem. Greenwald et al's requirement passed while NSA's failed. NSA didn't get shit in terms of their goals. They also lost a LOT. :)
"TextSecure/Signal has been around since 2010. "
I asked for a desktop app usable right now. I thought that was a mobile app. It's good that you...
"There is a Signal desktop client in development "
...brought me a red herring that wouldn't have helped Greenwald then or laypeople now. (sighs) Oh well. At least your counter might be true in a future case once that materializes. I look forward to its release.
Funny. I addressed this in my previous comment, but I guess you glossed over it:
> 1) It seems reasonable to expect that most journalists possess either an iOS or Android smartphone.
Your snark doesn't enhance the credibility of your objections.
> The requirement was that the NSA not be able to understand the content of those messages for a period of time that covers their activity.
Two things:
1) That's not what you said, though. You said "the NSA didn't get shit", when in fact, they did. In my reply to you, I even addressed the fact that it's possible they got the plaintext of the conversation long after the meeting. [0] Again, your snark doesn't do you credit.
2) Another goal of the NSA is storage of encrypted data for later decryption just in case a decryption method is found and the data is useful. The NSA does far more than just deal with information that has a very brief shelf life.
> Mediocre solutions stop people all the time despite pro's or talented people being able to defeat them.
Does a messaging system that XORs the message and addressing information with a hard-coded value meet your definition of "secure messenger" if its target audience is the everyday US citizen who communicates only to people within the US? Why or why not?
[0] But, in reality, we can't know that NSA wasn't aware of this vulnerability in CryptoCat at the time of the meeting. It's entirely possible that they had access to the plaintext of the conversation shortly after it happened.
No, I'm calling you on it. You're countering my claim that mediocre privacy is better than choosing no privacy if one is consciously aware that this is the choice. Your first counter...
"If your "secure communications" software doesn't stop a sophisticated passive adversary, it doesn't stop anyone, "
...was so ridiculous that you lost credibility instantly. I gave you the benefit of the doubt on the rest. The next part was a recommendation that basically confirmed my original claim that mediocre solutions were all that's you could think of barring a future release of Signal. Once again, there was no effective counter to people using Cryptocat or other mediocre solutions when they had nothing else available that was usable. And, again, knowing it wasn't guaranteed to stop hackers: just delay them or stop lay attackers.
"ou said "the NSA didn't get shit", when in fact, they did."
OK. I see you were just griping with a technicality in a secondary claim. I stand corrected: NSA did get shit way after they needed it. Remember that Snowden knew they would get found out. The after effect wasn't important. Just the delay. My argument still stands even with that point corrected given each party's goals.
"Does a messaging system that XORs the message and addressing information with a hard-coded value meet your definition of "secure messenger" if its target audience is the everyday US citizen who communicates only to people within the US? Why or why not?"
Yes if the threat model is jocks snooping on her phone and the code is custom. No most of the time because that's weaker than weak. A regular encryption algorithm people wouldn't know about with a solution that's not popular? Will stop most snoops unless they straight hack it. A modification of an existing one that preserves its security properties but obfuscates the change? Slows even nation state attackers.
Like I claimed: the threat model and security goals determine what level of security is appropriate. Wise engineers tell people to default on something really good. The userbase our post is discussing is incapable of or unwilling to put up with what's good by our standards. For them, it's no protection, methods that sell them out, or methods that offer some protection while not selling them out. The third option sounds better than the other two. This is where solutions like Cryptocat (not XOR lol) come in. They're easy, sometimes fun, enough for adoption to raise the baseline a bit. Or they remain niche which is even better in this threat model.
So, I drop the bar a bit to provide them some protection rather than none. Recommendations depend on the person and situation. Some w/ no malicious provider is still better than none + malicious host. The crux of my arguments.
"But, in reality, we can't know that NSA wasn't aware of this vulnerability in CryptoCat at the time of the meeting."
Even more support. If they weren't, the niche and barely functional thing did its job of showing them scrambled traffic they didn't auto-break and analyze. If they were, it bought the users time. Benefit either way over open communications despite this being outside my recommended use case. Some better than none.
I remember Moxie writing about intentionally using insecure messaging apps that have great UI for the purpose of learning what non-technical users want, and he then built stuff that was both secure and usable.
I think it's interesting how apps like Cryptocat (on one side) and those from e.g. Open Whisper Systems (on another) play off each other. Some secure messaging apps were pressured to up their UI game, and now some "usable" apps are pressured to up their security game or shut down. Whatsapp got X25519 via the TextSecure protocol, and now Cryptocat is shutting down. It sends a message that designers of new apps will be competing against successful deployments of messengers that are both secure and usable.
There are still things like Telegram that are apparently big, but I think the trend is clear.
By this logic, why even compete in the web/desktop space? Telegram has mobile, desktop and web clients.
What's hard is making it impossible for someone other than the intended recipient to decrypt the message. How do you get the key to the recipient? Using something like a secure chat? Oops, that's what you're trying to create.
Maybe DH key exchange? [1] It's not rocket science to implement, but mistakes are possible. Also, unless you're sure that you're talking directly to the person you think you are, a MITM could be performing the key exchange with each end, and again you have someone overhearing you. So in addition to a proper DH implementation you need some way for the people to verify that the tokens exchanged match.
tl;dr: Yes, it's really that hard.
[1] https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
The code's all on Github: https://github.com/Cryptodog/cryptodog. No signed extensions or apps yet, but you can clone and run locally for testing purposes, or use the hosted client linked there.
So far, we've been focusing on refactoring, fixing surface bugs, and making the UI more attractive and intuitive -- none of the underlying cryptography has been touched. It also performs slightly faster than stock Cryptocat. Since Nadim took down his XMPP server, we've had to create our own, but the backend is identical to his setup.
Of course, Cryptodog is by no means the best solution for E2E chat, just as Cryptocat wasn't. The best we can hope to achieve without a complete codebase overhaul is a reasonable level of security (https://leastauthority.com/static/publications/LeastAuthorit...). However, it's still a fairly usable app that can afford casual users protection against basic threats, like corporate data mining.
Issue postings, pull requests, and other miscellaneous contributions are all welcome.
I can't figure out why follow the path of fixing cryptocat instead of joining with a more promising project (take your pick, they're a ton). Anyway, I was about to tell tptacek that he fell for a troll, and the real new project was Cryptolion...
Cryptodog is very much a casual project, not an all-encompassing fix for inherent design flaws. I offer it here only as an alternative for former users of Cryptocat who were content with the app.
P.S. Your guess is inaccurate, I am not the GP. HN staff might be able to verify this if it concerns you.
I don't speak for Least Authority (and don't currently work for them).