Security

Note: Cryptocat is currently Beta software.
The Security page is currently incomplete and will be elaborated once the software is considered stable.

Encryption Overview

Cryptocat uses a TextSecure-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.

Every Cryptocat device owns a long-term identityKeyPair 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.

Between messages, Cryptocat maintains a forward-secure ratcheting chain that derives new ephemeral key pairs that keep their chain of authenticity by mixing in with the authenticated key exchanged via a Hash-Based Key Derivation Function (HKDF).

Primitives

• AES is used in Galois Counter Mode (GCM) for authenticated symmetric encryption with added data.
• X25519 is used for all Elliptic-Curve Diffie-Hellman (ECDH) operations. A four-way ECDH handshake is used for the initial authenticated key exchange and further ECDH operations are routinely performed for preKey generation and message ratcheting.
• ED25519 is used for generating identityKeyPair and for signing and verifying the signedPreKey, but is otherwise unused throughout the protocol.
• SHA256 is used as the standard hashing function and as the underlying hash function for the HKDF.

Threat Model

Cryptocat makes the following assumptions:

• Untrusted network: We assume that an attacker controls the network and so can intercept, tamper with and inject network messages.
• Long-term key compromise: We assume that an attacker may at some point compromise the long-term identityKeyPair of a participant.

Security Goals

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

• Secrecy: A message sent between buddies can only be decrypted between these buddies.
• Authenticity: If Alice receive an apparently valid message from Bob, then Bob must have sent this message to Alice.
• Indistinguishability: If Alice randomly chooses between two messages of the same size and sends only one to Bob, an attacker cannot determine which message was sent.
• Forward secrecy: If Alice sends a message to Bob and Alice's key state at the time of this message is susbsequently compromised, all previous messages retain their Secrecy property.
• Future secrecy: If Alice sends a first message to Bob, receives a reply from Bob, and then sends a second message to Bob, Alice's second message remains secret even if her key state for the first message is compromised.

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:

• Authenticated installers: Cryptocat client installation packages are authenticated using Authenticode on Windows, gpg2 on Linux and Apple code signing on Mac.
• Signed updates: In addition to installer authentication, Cryptocat's built-in update downloader will run an independent signature verification on all downloads.
• Certificate pinning: Cryptocat will check for a "known-good" TLS certificate before initiating a connection to the Cryptocat XMPP server.
• Device management: Users are given the option of independently verifying their buddies' device lists and are notified when a buddy's device list is modified.