Ricochet is an experiment with an alternative instant messaging method that does not trust anyone - it does not reveal your identity, contact list or communication. Ricochet is an experiment originally developed by John Brooksom and later adopted as the official instant messaging client project of the Invisible.im group. The purpose of the Invisible.im group is to help people maintain privacy by developing a client with "free metadata" for instant messaging.

From the functional features can be noted:

- You can communicate without disclosing the identity or ip-address.
- no one can find out with whom you are communicating or when you communicate (no meta-data)
- no servers that could be hacked, or operators that could be forced to give information about you
- cross-platform and simple even for ordinary users

How does Ricochet work? The instant messaging system peer-to-peer, based on the use of hidden services Tor. Your login is the address of your hidden service, and your contact is connected to you (without the participation of mediation servers) via Tor. The system of interaction is arranged in such a way that it is very difficult to establish your identity based on your address. (Ricochet is not connected and not coordinated with the developers of The Tor Project.)

How the hidden services protocol works

1 Tor allows users to hide their location, while providing various types of services, from web publications to instant messaging. Using the Tor meeting points ("rendezvous points"), other users can join hidden services, and none of them will know the identity of the other. A hidden service must report its existence on the Tor network before it can join. Service randomly selects repeaters, builds chains to them, and makes them their own "dating" points, giving them their public key. In the pictures, green lines are chains, not direct connections. When using full-fledged Tor chains, it's very difficult to tie the dating point to the ip-address of the hidden service. Although the public key is available to many, the ip-address of the hidden service should not be disclosed.

2 The hidden service collects its descriptor containing the public key and brief information about each of the dating points, and signs it with a private key. It uploads the descriptor into a distributed hash table. Clients will find the descriptor on XYZ.onion, where XYZ is a 16-character name created from a public key. After that, the hidden service is started.
Using an auto-generated service name may seem impractical, but it serves an important purpose: everyone, including dating points, a distributed hash table directory, and of course clients, can confirm that it communicates with the desired hidden service. There is an opinion that of three points - "decentralized, safe and meaningful for a person", you can usually choose no more than two.

3 A client who wishes to connect to a hidden service should learn his onion address. After that, he needs to download the descriptor from the distributed hash table. If there is a descriptor for XYZ.onion (and if the service is online, not abandoned and did not make a typo in its name), the client becomes aware of the set of dating points and the correct public key. At this time, the client also creates a chain to another randomly selected relay and makes it a meeting point, giving him a one-time secret key.

4 When the descriptor exists and the meeting point is prepared, the client collects an introductory message (encrypted with a public key of the hidden service), including the meeting point address and a one-time secret key. The client sends it to one of the points of acquaintance with the request to transfer it to the hidden service. Again, communication occurs through the Tor chain, no one can connect the sending of the introductory message with the client's ip-address, and it remains anonymous.

5 The hidden service decrypts the introductory message and finds out the address of the meeting point and the secret key. He creates a chain to the meeting point and sends a one-time secret key in a welcome message.

At the last step, the meeting point notifies the client of the successful connection. After that, the client and the hidden service use the chains built up to the meeting point to communicate with each other. The point simply translates encrypted messages back and forth. In general, the full connection between the client and the hidden service consists of 6 repeaters: 3 are selected by the client (one of them is the meeting point), and the other three are selected by the hidden service.

The goals of the project are to create an instant messaging system with the following properties:

- Users are not identified by their contacts or addresses
- communication has authentication and passes in private mode
- no one has access to the contact list, message history or other metadata
- Resists censorship and tracking at the LAN level
- Resists the use of black lists or DOS
- accessible and understandable for ordinary users
- Reliability and interactivity are comparable to traditional IM

The identity of each user is represented by the hidden service and its communication point. This information is distributed as id for communication in the form of ricochet: qjj5g7bxwcvs3d7i. In this form, it is unique and sufficient to connect to the service. Being online, the user distributes information about his hidden service in the form of an id containing an onion address, and accepts two-way anonymous connections that are either identified as known contacts or used to receive requests for communication.
Known contacts use a special protocol to transfer messages through established connections.
Like in classical instant messaging systems, you can send a request to add a user to your contact list using his id. Before you can send or receive messages, this request must be accepted. The request is sent by connecting to the service, in which it is reported that the connection is established to request a contact and different information is provided, including the sender's id. The sender, while online, periodically tries to establish a connection.

The request includes:

- the name of the hidden service of the recipient
- a random cookie created at the beginning of the connection by the recipient
- a random secret key that the recipient uses to confirm connections
- full public key associated with the hidden service and confirming the identity of the sender
- possibly a nickname and a short welcome message
- the signature of this RSA information with the same public key

The receiver counts the sender's id based on the public key, and confirms it by verifying the request signature. This confirms the sender's right to use the hidden service represented by his id.
The recipient can accept or reject the request. The rejected public key can be added to the black list and in the future rejected automatically

Being on-line, the service periodically tries to communicate with each of the contacts. If successful, the connection remains open and the contact is considered online. On each of the contacts you need one connection, it does not matter which of the two contacts was its initiator. The layer of hidden service is convenient in that it provides confidentiality, ephemerality, and confirmation - so the application protocol is very simple. The client part of the connection is confirmed by a pre-shared random key created immediately after the contact request.
For communication, a simple binary command-response protocol is used. He tries to add reliability to unstable connections. For simplicity and complete control over the process, to exclude the possibility of attacks on the security and anonymity of communication, the original protocol is used, and not one of the ready-made versions (XMPP). The protocol includes the ability to verify versions for future development.
The interface is an important and often underestimated part of security and anonymity. Less technically savvy users need to understand how to use the program and what to do in order to stay safe.
The Ricochet interface tries to be simple and straightforward for those who use other IM managers. Understanding Tor and networking concepts is not required. It should be easy to use it in the right way, it is difficult to violate security rules, and it is possible for IT professionals to expand the program's capabilities.

Introduction to the technical description of an open source project Ricochet (github)

Project site https://ricochet.im/releases/

Author's address: ricochet:rs7ce36jsj24ogfw или john.brooks@dereferenced.net