New Critical Vulnerability in Cryptocat: Details

In the unlikely event that you are using a version of Cryptocat older than 2.0.42, please update to the latest version immediately to fix a critical security bug in group chat. We recommend updating to the 2.1.* branch, which at time of writing is the latest version. We apologize unreservedly for this situation. (Post last updated Sunday July 7, 2:00PM UTC)

What happened?

A few weeks ago, a volunteer named Steve Thomas pointed out a vulnerability in the way key pairs were generated for Cryptocat’s group chat. The vulnerability was quickly resolved and an update was pushed. We sincerely thank Steve for his invaluable effort.

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. The period between 2.0 and 2.0.42 covered approximately seven months. Group conversations that were had during those seven months were likely vulnerable to being significantly easier to crack.

Once Steve reported the vulnerability, it was fixed immediately and the update was pushed. We’ve thanked Steve and added his name on our Cryptocat Bughunt page’s wall of fame.

In our update log for Cryptocat 2.0.42, we had noted that the update fixed a security bug:

  • IMPORTANT: Due to changes to multiparty key generation (in order to be compatible with the upcoming mobile apps), this version of Cryptocat cannot have multiparty conversations with previous versions. However private conversations still work.
  • Fixed a bug found in the encryption libraries that could partially weaken the security of multiparty Cryptocat messages. (This is Steve’s bug.)

The first item, which made some changes in how keys were generated, did break compatibility with previous versions. But unlike what Steve has written in his blog post on the matter, this has nothing at all to do with the vulnerability he reported, which we were able to fix without breaking compatibility.

Due to Steve’s publishing of his blog post, we felt it would be useful to publish an additional blog post clarifying the matter. While the blog post published by Steve does indeed point to a significant vulnerability, we want to make sure it does not also cause inaccuracies to be reported.

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.

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. Of course, it does not in any way save from the fact that due to our blunder, seven months of conversations were easier to crack. This is still a real mistake. We should also note that our SSL setup has implemented forward secrecy since the past couple of weeks. We’ve rotated our SSL keys as a precaution.

One more small note: Much has been said about a line of code in our XMPP library that supposedly is a sign of bad practice — this line is not used for anything security-sensitive. It is not a security weakness. It came as part of the third-party XMPP library that Cryptocat uses.

Finally, an apology: Bad bugs happen all the time in all projects. At Cryptocat, we’ve undertaken the difficult mission of trying to bridge the gap between accessibility and security. This will never be easy. We will always make mistakes, even ten years from now. 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. Bugs will continue to happen in Cryptocat, and they will continue to happen in other projects as well. This is how open source security works. We’ve added a bigger warning to our website about Cryptocat’s experimental status.

Every time there has been a security issue with Cryptocat, we have been fully transparent, fully accountable and have taken full responsibility for our mistakes. We will commit failures dozens, if not hundreds of times more in the coming years, and we only ask you to be vigilant and careful. This is the process of open source security. On behalf of the Cryptocat project, team members and volunteers, I apologize unreservedly for this vulnerability, and sincerely and deeply thank Steve Thomas for pointing it out. Without him, we would have been a lot worse off, and so would our users.

We are continuing in the process of auditing all aspects of Cryptocat’s development, and we assure our users that security remains something we are constantly focused on.