

Critical Vulnerability in Cryptocat - amouat
https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/

======
tptacek
_Cryptocat is not any different from any of the other notable privacy,
encryption and security projects, in which vulnerabilities get pointed out on
a regular basis and are fixed._

I feel bad for the team that worked on this (although I stand by my belief
that they shouldn't _be_ working on it), but this is an extremely aggravating
statement. When was the last cryptographic vulnerability discovered in any
mainstream implementation of PGP?

Vulnerabilities are found semi-routinely in TLS, which was designed by several
of the smartest crypto people in the world. But there's a key difference
between TLS and Cryptocat: the whole world is working on TLS security.
Vulnerabilities in TLS that are far less critical than this one are career-
making. Vulnerabilities that devastate the security of Cryptocat earn a blog
post.

I'm also a little confused: if the team put Steve Thomas on their thank-you
page, why did Steve Thomas write a blog post linking directly to that page
saying he wasn't on it?

I bring this up because it's a valuable lesson for startups. You _should_ have
a thank-you page. But you should also err on the side of quickly adding
people's names to it when they report things. It looks (from the pull request)
like much of this was reported over a month ago. Don't wait a month to thank
people who report vulnerabilities in your code.

~~~
a_bonobo
>I'm also a little confused: if the team put Steve Thomas on their thank-you
page, why did Steve Thomas write a blog post linking directly to that page
saying he wasn't on it?

The thanks on the cryptocat page wasn't there about 4-5 hours ago (last time I
checked).

~~~
tptacek
Either you and Steve Thomas are right, or this release is right. Both can't be
true.

~~~
pathy
The Google cache [1] from 26th of June does not show Steve Thomas' name on
that page, so it seems that Steve is right and CryptoCat are not telling the
truth. That said, 26th is quite a few days ago so it might have changed
between then and now.

[1]
[http://webcache.googleusercontent.com/search?q=cache%3Ahttps...](http://webcache.googleusercontent.com/search?q=cache%3Ahttps%3A%2F%2Fcrypto.cat%2Fbughunt%2F&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-
US:official&client=firefox-a)

~~~
makomk
Technically they're not lying since they have put his name on their thank-you
page now, they're just deceiving us with the truth.

------
joeyh
Steve Thomas:

 _Yes this is scary but I believe everything is /was over https. So this just
means that it was host based security. Meaning we have to trust that Cryptocat
didn't store/transfer encrypted messages or leak their SSL private key. They
should generate a new private key, to prevent someone from breaking into their
server and stealing it. Which might let them decrypt old captured messages._

Cryptocat response:

 _Our SSL keys are safe: For some reason, there are rumors that our SSL keys
were compromised. To the best of our knowledge, this is not the case. All
Cryptocat data still passed over SSL, and that offers a small layer of
protection that may help with this issue._

whoosh

~~~
graue

        $ curl -vI https://crypto.cat
        * About to connect() to crypto.cat port 443 (#0)
        *   Trying 94.254.0.157...
        * connected
        * Connected to crypto.cat (94.254.0.157) port 443 (#0)
        * successfully set certificate verify locations:
        [ ... snip ... ]
        * SSLv3, TLS handshake, Finished (20):
        * SSL connection using ECDHE-RSA-RC4-SHA
    

If my understanding is correct, ECDHE offers "perfect forward secrecy", as
discussed on HN a few days ago — each session uses an ephemeral key created
for just that session. So past sessions are already protected against an SSL
private key compromise, and changing the key wouldn't add protection.

Of course, only the Cryptocat folks could clarify what percentage (all?) of
their users actually connect over an SSL method that offers PFS.

~~~
Spittie
As this blog post says, ECDHE got implemented only "in the past couple of
weeks", which mean that there are still about six months of conversations that
didn't use ECDHE and can be easily cracked in case someone leaks their SSL
keys.

------
makomk
"The vulnerability was so that any conversations had over Cryptocat’s group
chat function, between versions 2.0 and 2.0.42 (2.0.42 not included), were
easier to crack via brute force."

That's quite an understatement - and they helpfully don't link to Steve
Thomas's blog post so readers can't easily discover just how weak the
encryption actually was. (See
[https://news.ycombinator.com/item?id=5989707](https://news.ycombinator.com/item?id=5989707)
if it's dropped off the front page by the time you're reading this comment.)

------
raverbashing
" At Cryptocat, we’ve undertaken the difficult mission of trying to bridge the
gap between accessibility and security. This will never be easy."

Really, Cryptocat should be commended for this

Because the crypto people usually don't care and in some cases makes extra-
hard for regular people (or even non experts) to have security. Like the ECB
fiasco. [http://www.codinghorror.com/blog/2009/05/why-isnt-my-
encrypt...](http://www.codinghorror.com/blog/2009/05/why-isnt-my-encryption-
encrypting.html) At least the documentation warns it's really a bad choice.

Making technology accessible to everybody is _very important_

~~~
tptacek
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.

~~~
raverbashing
> 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.

~~~
tptacek
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.

~~~
raverbashing
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)

~~~
tptacek
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".

~~~
tbirdz
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.

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

------
hnolable
Does anyone know if there are any issues with the javascript OTR library they
use ([https://github.com/arlolra/otr](https://github.com/arlolra/otr))? Or are
all the issues only with their custom multi party chat encryption system?

------
tete
> Private chats are not affected: Private queries (1-on-1) are handled over
> the OTR protocol, and are therefore completely unaffected by this bug. Their
> security was not weakened.

Hey, that sounds great to me.

Also wouldn't it be possible to talk to multiple parties, by simply doing the
OTR-Jazz to every party? Would kinda be hack, but would make sure you can use
that cool OTR protocol that is secure or am I wrong somewhere?

~~~
whackedspinach
I would be careful before trying this. I don't know much about crypto, but you
might be able to do some interesting statistical attacks if you are encrypting
the same plaintext with multiple keys.

------
X4
The man in the "black suits" that were folloing Nadim Kobeissi, didn't have
anything todo with these bugs right?

However I'm sure that the NSA can crack SSL/TLS in a matter of minutes, not
because they have such powerfull secret hardware, but because they probably
have agents that spotted or added bugs here and there in different software.

Wouldn't that mean that even when you invented a perfectly secure super
encryption, they could wiretap your OS and get the message in cleartext
without your consent. Thanks to backdoors, bugs and incompetence.

