Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

Cryptocat: What is the measure…

What is the measure of a man; what makes one great, and another lesser? What separates success from failure? We all recognize light from dark, but at which point does it go from one to another? If we ask if a person (or company, or product) is successful – do we measure them against their closest competitor, their nearest neighbor, or perhaps the most successful person we know? Where, and how, do you set that bar to measure against?

Yesterday I talked to Nadim Kobeissi for about an hour about Cryptocat, its policies, practices, successes, failures, and goals. The topic of goals led to an interesting discussion – to what standard is Cryptocat being held? Perhaps, just perhaps – the unforgivable security failures of Cryptocat are only so unforgivable because of the bar it’s being measured against.

[this] is a crucible; in it we burn away irrelevancies until we are left with a pure product: the truth, for all time.

So, what it the true goal? Here is a snippet of their readme, which (kinda) lays out the goal:

Cryptocat is an experimental browser-based chat client for easy to use, encrypted conversations. It aims to make encrypted, private chat easy to use and accessible. We want to break down the barrier that prevents the general public from having an accessible privacy alternative that they already know how to use. Cryptocat is currently available for Chrome, Firefox and Safari.

The second sentence is the one that I find interesting, in light of the conversation I had yesterday; primarily this part: an accessible privacy alternative that they already know how to use. I asked Nadim at one point what his goal was, he responded without hesitation: to provide a safer alternative to Facebook Chat, Google Talk, etc..

When I asked about Cryptocat’s reputation as a tool for activists, he was clearly agitated and made his position on the matter very clear. That isn’t the intention, and he acknowledged that it’s not safe for that use. He then pointed me to a quote on their blog:

We have realized that due to some (perhaps well-meaning) media coverage of the Cryptocat Project, our work has been labeled by the media as something that can aid activists in overthrowing governments or help save someone’s life. This is not what Cryptocat is, it is wrong for the media to say that, and we have never said anything to that effect ourselves.

Though I will note, the initial feeling seemed to be a bit different:

So, where does this leave us?

The most recent flaw was bad, very, very bad. If you understand encryption, the protection afforded was far less than expected. Let’s look at it from another perspective though: Compared to Facebook Chat. While the bug was bad, how does it compare to other consumer chat systems, even with that flaw in mind? From what I’ve seen, it’s still a better option than Facebook.

First, let’s ignore encryption and just look at what we get from SSL/TLS:

Facebook:

Cryptocat:

First thing that I can point out is the use of forward secrecy – something Facebook isn’t using (yet). So, if you just look at SSL/TLS, Cryptocat is better – assuming nobody else has access to the ciphertext, which happened (at least) when they used Cloudflare.

How about data retention? While in the past Facebook has said messages are cleared after 90 days, it’s not clear how long they retain the information today, or how much could be produced under subpoena – it’s clearly more than what Cryptocat can produce (as Facebook produces a lot). Just looking at what Facebook can provide, versus what Cryptocat can says a lot from a privacy perspective.

I could go through more details, or compare it in more detail to other services, but the basic point should remain.

From that perspective, I think Cryptocat has accomplished something – it may not be ideal, and has clearly been far from it; it’s still a better choice for casual communication than most (all?) of the major IM/chat players.

‘I thought you said don’t use it?’

In an article I was quoted as saying something like this:

He went on to recommend people not rely on Cryptocat to keep their conversations private until the code and the cryptography in it are thoroughly audited by professional penetration testers and cryptographers.

I stand by that statement. If you need security, Cryptocat isn’t what you should be using, period. If you want privacy, it’s not a bad option. In a discussion on Twitter, the agreement was that there are no real competitors that provide secure multi-party chat – for those that want that feature, Cryptocat seems to be the only option.

It’s worth pointing out though, if you’re reading this, you probably know how to use PGP – and can use that to get around Cryptocat’s use-case. I’m not an apologist, and I’m not trying to excuse serious mistakes – I’m trying to present the issue, and the system itself in a fair light for the intended use-case, as Nadim explained it. In that light, the system still achieves its basic goal.

Adam Caudill

Related Posts

  • Worried about the NSA? Try AES-512!

    …or, The Cost of Wild Speculation. “We need to boost our security – I think the NSA has broken everything we use. AES-256 is too weak, I don’t trust it. Find a way to implement AES-512.” Double-AES-256! It’d be easy, and double encrypting has never bitten us before. So, let’s write some code! def encrypt(msg, iv, key) return e(e(msg, iv, key.slice(0..31)), iv, key.slice(32..63)) end def decrypt(cipher, iv, key) return d(d(cipher, iv, key.

  • Crypto, the NSA, and Broken Trust

    Even as a child I was fascinated by cryptography – and often left the local librarians with puzzled looks thanks to the books I would check out. It’s so elegantly simple, and yet massively complex. There is one very unusual property of crypto though – it’s not about math or modes, it’s about trust. Cryptography, especially as used today, has the most wonderful dichotomy of trust; on one hand crypto, by its very nature, is used in situations lacking trust.

  • Hash Storage: Make Attackers Work

    So you hash your passwords? Good. Do you salt? That’s good. Do you use a strong hashing algorithm (PBKDF2/bcrypt/scrypt)? Great! But how do you store the hashes? What happens when you get hit with a SQL injection attack? I’m a big believer in defense in-depth – not that marketing garbage about stacking layers of blinky-light boxes, but using techniques to add extra work for an attacker. You might not be able to stop every attack, but the more work they have to do, the better the odds they won’t get everything they want.

  • Do one thing right…

    Everybody’s favorite whipping boy, Cryptocat is back in the news today – and it’s bad. Really bad. Steve Thomas has found a major flaw in the way Cryptocat generated ECC keys. Due to this flaw, the keyspace was only $2^{54.15}$, well below a secure level. Add a meet in the middle attack, and this is further reduced to $2^{27.08}$ – which based on my rough estimates, is just slightly more secure than a paper bag.

  • Password Hashing: No Silver Bullets

    In the dark days of the web, if a service hashed your password instead of storing it in plain text, they were doing good. As sites were hacked, and credentials stolen, a silver bullet emerged: always hash and salt passwords when storing them. Many, many services were built with this design – LivingSocial is a great example. SHA1 hashing with a 40 byte salt – once upon a time, that was considered reasonable protection.