Latest posts.

Recent Audits and Coming Improvements

We’re excited to announce that Cryptocat has received two more audits of its codebase. Maintaining our responsibility of making encrypted chat not only fun, cute, and more fuzzy, but also transparently secure and dependable, we were able to solicit two more code audits from the experts at Least Authority and iSec Partners.

The audits covered Cryptocat’s web client, and also an early, pre-release (therefore buggy) version of Cryptocat for iPhone. These audits would have not been possible without the crucial support of the Open Technology Fund. We were capable of fixing bugs in the pre-release iPhone version before release thanks in large parts to these audits. The Open Technology Fund has released a statement about this audit on their website.

 

Main Issues Identified

While the audits identified a variety of issues that needed to be fixed or that could be improved upon, there were two main issues that pertained to Cryptocat on a wider scope: authentication and file transfer.

Necessary Improvements to Authentication

A prevalent theme in both audits was that Cryptocat’s authentication mechanism, while not broken outright, was severely lacking. This was due to the following factors:

Ephemeral Key Identity: Cryptocat relies on completely ephemeral keys. This means that no keys are ever stored permanently, and therefore there is no permanent key identity. This provides many positive properties: no permanent identity that can be traced back to an individual, perfect forward secrecy, and the negation of the risk of physically-stored key compromise. However, this also translates into Cryptocat users having to re-authenticate every time, which can be especially taxing on group conversations with multiple participants. In the audits, it is argued that depending users to re-authenticate every time is unrealistic, and therefore a bigger risk than storing permanent keys.

No Re-Key Warning for Private Conversations: For private conversations (OTR,) the authentication interface does not warn users when an authenticated key exchange occurs resulting in a different key fingerprint. This lack of warning could effectively override a previous successful authentication, and could therefore allow a successful man in the middle attack to occur. This is a problem that can be exploited in some real-world scenarios and needs to be addressed with appropriate authentication warnings. Thanks to these audits, this issue was caught in Cryptocat for iPhone before it was released. Therefore, unlike the desktop version, Cryptocat for iPhone was never affected by this issue.

Insufficient Authentication UI: Cryptocat’s authentication interface provides access to a user’s key fingerprints and a dialog for question-based SMP authentication. While in theory this does allow users to fully authenticate, the authentication interface remains lacking in the following ways:

  1. No deeper integration into the user interface. Users can easily ignore the necessity of authentication due to the lack of visual cues and reminders regarding the current authentication status of a conversation. Since Cryptocat targets users with no prior experience in encryption, this is a particularly relevant concern.
  2. The importance and significance of authentication is not emphasized. We have no guarantee that Cryptocat’s users understand that authentication is important, or even what it means to authenticate a contact.

The combination of these issues, the minimal authentication UI, and some shortcomings in how nicknames were handled in Cryptocat can lead to the easier deception of Cryptocat users when it comes to an attacker assuming the identity of another Cryptocat conversation participant. This was demonstrated by the audits (and the discussions were also posted on GitHub here, here and here). Fixing code-layer bugs can only go so far — how are we going to address the interaction aspect involved with these authentication issues?

Cryptocat’s New Authentication Interface

In the upcoming update slated for next week, Cryptocat will show authentication icons next to every message from every users. Users that are not authenticated will have a red “!” next to their messages. Hovering over that icon will prompt a user to authenticate. Clicking it opens the new authentication dialog:

In this update, the question-based (SMP) authentication method now authenticates users for both group and private conversations. In the past, question-based authentication only affected private conversations, and the audits revealed that this could be confusing to users. The new authentication dialog also offers a “Learn more about authentication” button. Clicking it displays our new authentication tutorial, a fun cartoon slideshow explaining authentication and translated into Cryptocat’s 38 languages.

The slideshow was designed by the wonderful Ingrid Burrington, who has previously collaborated with Cryptocat on design. Finally, we also added warnings to address exceptions such as a suspicious re-keying:

While we’re very excited to roll out Cryptocat’s new authentication interface, and while we feel it helps address many of the shortcomings of authentication in Cryptocat, we’re aware that it still does not address the issue of ephemeral key identities. This is something that is still being discussed and is complicated by the open questions of secure key storage in the browser.

The relevant GitHub issues are #475, #580 and #594, with relevant commits also spread around in the commit history.

File Transfer: CTR Mode, There and Back Again

Cryptocat was the first project to have an implementation of OTR that used OTR’s extra symmetric key for encrypted file transfer. While our proposed file transfer specification was internally reviewed and was deemed likely sound, we found that implementation issues existed in Cryptocat’s file transfer features. We were hinted towards the existence of these issues many months ago, and therefore file transfer has been disabled in Cryptocat since last year.

Since Cryptocat’s file transfer specification depended on AES in CTR mode, re-keying between every file transfer is essential. While the implementation is indeed programmed to re-key between every file transfer, it was possible to circumvent the re-keying process, thereby exposing some files to the classic same-key-same-nonce vulnerability that CTR mode is known for. This could be done in several ways: sending multiple files in succession without messages in between, or by operating a malicious server that selectively dropped messages in such a way that prevented re-keying.

We’ve previously had security issues with CTR nonce re-use, as have many projects — this is a tricky vulnerability that is likely to pop up when deploying complex cryptographic systems using AES-CTR. Therefore, we’re happy to have been able to catch it early on and disable file transfer in Cryptocat at an early stage. Currently, we are moving towards implementing the OTRDATA specification in Cryptocat as an alternative that may prove more resistant to attacks. The relevant GitHub discussions for vulnerabilities in file transfer are at #575 and #576.

 

Smaller-Scope Issues Identified

In addition to the above issues, which involve Cryptocat in a general scope, many localized, smaller-scope issues were identified:

  1. iOS Saves Screenshots on Backgrounding: By default, iOS saves screenshots of apps on disk before switching to another app. This allows iOS to show a preview of the backgrounded app when switching back, but also means that screenshots of your private chats could be saved locally on disk. We were very glad to be alerted of this issue and fixed it before Cryptocat for iPhone was released.
  2. XMPP Connection Issues: Cryptocat for iPhone was vulnerable to StartTLS stripping, which could prevent the correct initiation of a TLS connection. Thanks to these audits, we were able to fix this issue before release.
  3. XMPP Configuration Issues: Cryptocat’s default server configuration had some suboptimal settings, such as storing a conversation’s ciphertext for a short period of time. These issues were fixed.
  4. Crashes and Miscellaneous: Malformed Cryptocat messages could sometimes cause crashes, and malformed nicknames could allow attackers to crash clients or silently view conversation ciphertext (only ciphertext, which is already accessible to the server.) The most severe of these crashes were fixed before release, while the less severe ones are being currently worked on.
  5. Other issues: The audits were quite thorough, and other, smaller issues were identified and fixed.

Since the audit concerning Cryptocat for iPhone was performed on an early, pre-release version, many of the bugs it found are overly silly (leftover debug logging of messages and keys, for example). Still, while the iPhone audit concerns a pre-release version with many typical pre-release bugs, many of the bugs described above did affect Cryptocat for iPhone, and it was thanks to these audits that we were able to catch them and fix them before Cryptocat for iPhone was released. We owe immense thanks to iSec Partners, Least Authority and the Open Technology Fund for arranging and providing this amazing opportunity to Cryptocat and its users.

 

On the Significance of Audits

For the past two years, Cryptocat has been open regarding security and audits to the degree that we may very well be the most transparently developed encryption project in the world. We are proud of this. We believe that there is a general reticence in the field to openly publish audits or to openly discuss fixing vulnerabilities or improving encryption and security. This reticence is damaging to the opportunity for honest evaluation, cooperation and the establishment of a realistic perception of encryption software. It also misleads users.

Since Cryptocat carries out its specification, development and auditing in an unusually transparent degree, the impression may be that since Cryptocat is the only project publishing audits and discussing vulnerabilities, Cryptocat must be the only project with vulnerabilities in the first place. However, if other encryption projects followed our lead and fully published all audits, made all cryptographic decisions and specifications fully available for open discussion, and fully elaborated on vulnerabilities and how to fix them, users can benefit from a more honest and true perception of how encryption software is really developed, and what to expect, even if it comes at the expense of the prestige and competitive marketing potential of the software itself. Honesty is important.

There is also the danger of the false belief that if encryption software is audited by experts once, then that is enough for it to be considered reliable. Programming encryption software is a highly complex human endeavour, and deploying a piece of software to a hundred thousand users with a hundred thousand different use-cases further contributes to this complexity. We believe that the best progress towards reliable security can only be achieved via open review, stringent repeat audits, and a transparent, inclusive development process.

Download the full audit documents here.

Aside from the improvements mentioned in this post, we are still working on our mpOTR project, which aims to provide a truly global encryption protocol for group messaging. We’re looking forward to rolling out many updates to help make encryption more fun, accessible and useful for everyone in the world who expects the Internet to offer them a trustworthy feline friend for their private conversations.

Cryptocat, Now on iPhone

Cryptocat is ready for iPhone. After a year of collaborative development, testing and tweaking, we’re finally ready to bring the world’s most privacy-loving cat to your pocket! Download Cryptocat for iPhone for free from the App Store.

We’re currently at RightsCon Silicon Valley, where we’re giving a demo and discussion regarding the new iPhone app to an audience of hundreds of technologists and civil society members. If you’re there, come find us at the Demo Room. We want to answer your questions, hear your stories, and give you Cryptocat stickers.

A new goal for accessibility.

At Cryptocat, we know that our software has made encrypted chat fun for journalists, coworkers, advocacy groups, teachers and even activists around the world who otherwise would have been stuck with Facebook, Skype or some other insecure medium. Our mission has always been on making encrypted chat fun and easy to use, first and foremost.

Over the past two years, we’ve contributed some significant improvements to client-side encryption in the browser, as part of the research that makes Cryptocat possible. Now, we’re porting our experience in fun and easy to use encrypted chat to the mobile platform, to create a client that encrypts your conversations with groups of friends without getting in your way.

Notably, Cryptocat for iPhone is a native application, and depends on native iOS APIs instead of web cryptography as is the case in other Cryptocat clients. We’re making the Cryptocat experience accessible across platforms, and porting our experience to different languages and APIs. The upcoming Cryptocat for Android will also be a fully native Android experience.

Cryptocat for iPhone uses the OTR protocol for private conversations, and our solidly maturing multiparty protocol for group conversations. With our current research into mpOTR, we hope to soon offer an upgraded global standard that brings Cryptocat’s encryption system to other platforms as well.

Simple, compatible, usable.

Cryptocat is different from other encrypted chat tools in that it doesn’t require usernames or accounts. Users enter a conversation using a one-time nickname. There are no buddy lists or account activity or account history to link back to the user. This way, Cryptocat offers a unique ephemerality that makes setting up encrypted conversations immediate and without any lasting history that can be traced back to users.

Cryptocat for iPhone works seamlessly with the existing Cryptocat clients for Chrome, Firefox, Safari and Opera. Chat with friends and continue the conversation on the go. Join a Cryptocat conversation just by reaching into your pocket. Your friends can follow from their browser. It’s the simple, friendly, colourful and cat-filled interface that makes Cryptocat a popular and accessible choice for those who need quick access to privacy. And every message sent or received in Cryptocat is encrypted with open, tested and verifiable cryptographic standards.

An honest, experienced focus on security.

Cryptocat has developed a reputation for being one of the most transparently developed encryption projects out there. By transparent, we mean that the community is involved and allowed to review and participate in every part of our development process. Cryptocat for iPhone’s codebase solicited public review from security enthusiasts months before release. We’ve also solicited independent audits and have incorporated feedback. This helped us address many important issues before release, and is the magic of transparent, open source, free software.

We’re working on fine-tuning as more and more users report feedback. For future updates, we are looking to:

  • Redo Cryptocat’s authentication interface to make it easier for new users to understand how authentication works and why it’s important.
  • Implement long-term key storage on Cryptocat platforms to facilitate authentication and not make it required every time.
  • Focus on incremental security improvements (certificate pinning!) and soliciting feedback from users. We benefitted greatly from our UI/UX hackathon with OpenITP.

Innovate with us.

Cryptocat for iPhone’s codebase is on GitHub, completely open source, open to your ideas and open to changes and additions. Come help us create encrypted chat that is ephemeral, fun, accessible and works on every platform that can crunch two numbers together. We regularly reward developers as part of our Bug Hunt initiative, and we’re more than happy to include your contributions. Be part of a friendly community and help improve an app ecosystem already in use by more than 100,000 people.

Get an encrypted cat in your pocket!

Yes. Cats in your pocket. Doing your crypto. I mean ultimately this is what the big idea is. Cats with 100% end-to-end encryption.

Finally, please file bugs. We expect there to be at least a couple of weird bugs that we missed, and we need you to file them if we’re going to fix them. There are three known usability bugs in the 1.0 release, and we’ve already submitted an update that we hope Apple will review for release later this week/early next week. We need your help to find more bugs and to incorporate your suggestions!

A community effort.

These folks were very helpful in making Cryptocat’s first mobile foray a reality. In no particular order, they deserve our thanks:

  • Thomas Balthazar: Thomas joined Cryptocat to lead the mobile development effort, and his contributions have been central to the establishment of a mobile codebase and necessary libraries.
  • Disasterpeace: The renowned 8bit musician designed Cryptocat’s iconic audio notifications and sounds. Thanks, Rich!
  • EFF: The Electronic Frontier Foundation helped us invaluably, heroically and skillfully with dealing with some potential problems with being able to release Cryptocat for iPhone.
  • OpenITP: Helped with support, organizing meetings, and with organizing a productive UI/UX hackathon which provided a lot of research and testing material for Cryptocat for iPhone.
  • OTF: The Open Technology Fund provided vital resources for making this app possible.
  • RightsCon: Sponsored Cryptocat for iPhone’s launch and invited us to come give a demo presentation at their conference.
  • Our community of testers and contributors: Thanks to the awesome folks going through our codebase on Github and submitting over 50 contributions during the testing period.