Design and Functionality - Gordin/cryptocat GitHub Wiki

Cryptocat focuses more on ephemeral encryption keys and ease of use than other encrypted XMPP chat solutions.

Table of Contents

  1. High-level overview
  2. Detailed overview
    1. Client-specific notes
    2. Server-specific notes

Needs more elaboration everywhere!
Contribute your thoughts!


High-level overview

From a user perspective, Cryptocat 2 will function similarly to previous Cryptocat versions:

  1. A chat room visitor provides the Cryptocat service with a room name and a personal nickname.
  2. Cryptocat either creates a virtual chat room or locates an existing one. In the latter case, it lists the room's occupants to the new visitor.
  3. The visitor may then chat inside the room with all occupants, or have private, one-to-one conversations with individual occupants.
  4. All conversations are end-to-end client-side encrypted with [OTR](Off The Record) (http://www.cypherpunks.ca/otr/) or mpOTR (multi-party OTR).

Detailed overview

Connecting: Chronological Overview

  1. A chat room visitor provides the Cryptocat service with a room name and a personal nickname.
  2. Cryptocat generates an OTR key pair (a public key and a private key).
  3. Cryptocat generates both an XMPP (Extensible Messaging and Presence Protocol) username and password (both are random alphanumeric 256 bytes long). These are used to register a new user on the XMPP server using XEP-0077.
  4. Visitor's public OTR key is sent to the XMPP server.
  5. The XMPP server offers a challenge to the Cryptocat OTR key in order to prove that Cryptocat owns the private key to the offered public key.
  6. If the challenge is answered successfully, the XMPP server assigns an XMPP identity to the user based on the user's public key.
  7. The user/visitor joins the chat room. Chat rooms are XMPP MUC (Multi User Conference) instances (XEP-0045).
  8. mpOTR key exchange occurs. Visitors communicate their nicknames to each other through this key exchange, so that their nicknames remain invisible to the XMPP server.

Client-specific notes

  1. It is not possible to disable OTR/mpOTR. Unencrypted messages are rejected.
  2. UI (User Interface) elements may be used to signify certain OTR/mpOTR properties. For example, each mpOTR message may be accompanied with a progress bar that shows the authentication progress for the message.

Server-specific notes

  1. XMPP servers will need to be modified to support authenticating through OTR public/private key pair verification. Backwards compatibility with existing XMPP servers is worth investigating.