Encryption Overview

Cryptocat uses a Double Ratchet-based encryption protocol that combines a forward-secure ratchet with a zero round-trip authenticated key exchange. As a transport layer for encrypted messages, Cryptocat adopts the OMEMO Multi-End Message and Object Encryption standard, which also gives Cryptocat multi-device support and allows for offline messaging. In terms of the transport layer, Cryptocat uses XMPP over a long-standing, TLS-encrypted WebSockets connection.

Every Cryptocat device owns a long-term identityKey pair which helps with the establishment of the initial authenticated key exchange. This key pair also serves to sign the device's signedPreKey, an ephemeral public key that also is mixed into the authenticated key exchange. The signedPreKey is also shipped with 100, unsigned, one-time-use preKeys, and is regenerated and re-signed every week.

Suppose Alice wanted to start a new session with Bob. Alice would then fetch Bob's current signedPreKey and his list of 100 preKeys from the Cryptocat network. Alice would then select a random preKey from the list. Alice then generates her own initKey pair, which is a keypair used only for the purposes of initializing a new session. Alice then performs the following computation in order to obtain the initial session secret S: S = SHA256( X25519(AliceIdentityKey, BobSignedPreKey) || X25519(AliceInitKey, BobIdentityKey) || X25519(AliceInitKey, BobSignedPreKey) || X25519(AliceInitKey, BobPreKey) ) ( AliceReceivingRootKey, AliceReceivingChainKey ) = HKDF(S, Constant1, Constant2)

Between messages, Cryptocat maintains a forward-secure ratcheting chain that creates a new ephemeral key pair for each message, and derives their chain of authenticity by mixing in a chain going back to S via a Hash-Based Key Derivation Function (HKDF). Here is an example occuring later in the conversation, after Bob had also derived a BobMessageEphemeralKey and other session state elements: AliceMessageEphemeralKey = X25519_NewKeyPair() AliceSharedKey = X25519( AliceMessageEphemeralKey, BobMessageEphemeralKey ) ( AliceSendingRootKey, AliceSendingChainKey ) = HKDF(S, AliceReceivingRootKey, Constant2) AliceMessageEncryptionKey = HKDF( HMAC(AliceSendingChainKey, Constant3), Constant1, Constant4 ) ( AliceEncryptedMessage, AliceEncryptedMessageTag ) = AESGCM256( Key:AliceMessageEncryptionKey, Plaintext:AliceMessagePlaintext, AddedData:( AliceMessageEphemeralKeyPublic || BobMessageEphemeralKeyPublic || AliceIdentityKeyPublic || BobIdentityKeyPublic ) ) Alice then sends (AliceMessageEphemeralKeyPublic, AliceEncryptedMessage, AliceEncryptedMessageTag). Constant1, Constant2 and Constant3 are some publicly known constant strings coded into the protocol implementation.


Threat Model

Cryptocat makes the following assumptions:

Security Goals

Given our threat model, Cryptocat aims to accomplish the following security goals:

Authentication Overview

Cryptocat offers users the ability to verify the authenticity of their buddies' devices. In that way, they can ensure that a malicious party (including, potentially, the Cryptocat network itself) is not masquerading as the device of another individual. Device fingeprints are calculated thus:

DeviceFingerprint = SHA256( deviceId || SHA256( username || deviceName || deviceIcon ) || deviceIdentityKeyPublic ).HexString().First32Characters()

In the above example, deviceId is a random 32-byte device identifier that is generated upon device registration and that never changes. deviceName is a name that the user assigns to the device that also cannot be later modified. deviceIcon is one of three icons (0, representing a laptop, 1, representing an all-in-one desktop and 2, representing a PC) and also cannot be modified.

File Sharing

Cryptocat software provides users with the ability to share documents, video recordings, photos and other such media. These are all threated as the same type of plaintext (a "file") and are all handled as follows:

Note that fileUrl cannot be just any HTTP URI but is specially restricted for the purposes of Cryptocat file sharing.

Miscellaneous Security Features

Aside of the message encryption protocol, Cryptocat adopts the following security features in order to provide a generally more robust experience across the client:

Reporting Security Issues

Note: a Bug Bounty Program is currently in effect.

Cryptocat is written with security in mind and uses state-of-the-art cryptography engineering to protect your privacy. However, in the event that a security vulnerability is discovered, the project operates under the principle of full disclosure. If you discover a critical security issue with Cryptocat software, report it. You will be helping safeguard the privacy of thousands of people. Depending on the severity of the issue, here is how we recommend you report your findings:

Bug Bounty Program

From December 20, 2016 and until December 31, 2017, Cryptocat is holding a Bug Bounty Program. The goal of this program is to invite independent analysis of Cryptocat's security, especially since its complete rewrite which was completed in April 2016.

Bug Bountry Program Prize

  1. $500 USD delivered via PayPal.
  2. A good book from chosen by us.
  3. Recognition on the Cryptocat website.
  4. A personal thank-you note.

Due to Cryptocat's limited funding as volunteer-run software, the bounty is held in a "contest" style: the first person to report a vulnerability will receive the prize, and the Bug Bounty Program will then be closed until further notice. Should we receive more than one bounty report simultaneously, we will award the prize to the report we judge to be more important.

However: Should you win the Bug Bounty Program prize but forfeit the $500 USD prize money, the Bug Bounty Program will remain open for a second potential winner, and you will still receive the other three elements of the prize.

Bug Bounty Program Criteria


  1. Your report must be submitted before December 31, 2017 (anywhere on Earth).
  2. A proof-of-concept must be included.
  3. You must be agree with full public disclosure of the bug you have discovered. You may choose to forfeit public credit.

Bug Eligibility

Your reported vulnerability must be, within reasonable judgement, a high-to-critical severity vulnerability. For example, it must allow remote account compromise, user or device impersonation, message decryption, arbirtrary code execution, or something along these lines. A simple denial of service, to give a counter-example, or a bug that is reliant on pre-existing control of the victim's device, is not eligible. We promise to be fair regarding the severity of your reported bug.

Any submitted report must involve a bug that is exploitable in the latest version of Cryptocat at the time of submission.

Bug Bounty Program Report Submission

Simply send a Cryptocat message to nadim on Cryptocat in order to submit your report. It's the personal account of the person responsible for writing the software.

Thank you for helping make Cryptocat safer for everyone. Good luck!

Follow Cryptocat on Twitter
English - Français - Català
"Cryptocat" and the Cryptocat logo are registered trademarks.
Copyright © 2018 Nadim Kobeissi, all rights reserved.