November 6, 2014 at 23:47Ricochet - Anonymous Serverless Instant Messaging Protocol
- Transfer
Translation of the introductory part and introduction to the technical description of the open source project Ricochet ( github ).
Ricochet is an experiment with an alternative method of instant messaging that does not trust anyone - does not reveal your identity, contact list or communication.
- You can communicate without revealing your identity or ip address.
- no one can find out with whom you are communicating or when you are communicating (no meta data)
- no servers that could be hacked, or operators that could be forced to give out information about you
- cross-platform and simple even for regular users
Note: the project has recently been renamed from Torsion.
Ricochet is a peer-to-peer instant messaging system based on Tor's hidden services. Your login is the address of your hidden service, and your contact connects to you (without the participation of intermediary servers) via Tor. The interaction system is designed so that it is very difficult to establish your identity based on your address.
Ricochet is not affiliated with or sponsored by The Tor Project developers.
The project is experimental. No one conducted a formal audit of the code. Security and anonymity are complex topics, and you need to independently assess the risks of being exposed when using any software. We do not recommend relying on Ricochet for security and do not trust Ricochet more than necessary. Although I, as a developer, are sure that my project gives you more privacy than any other similar one.
Ricochet is available for Windows, OS X (10.7 and higher), there is also a generic Linux binary package. Release information and release history are available on the respective pages.
They are also available on the project website .
Binaries are signed through PGP 9032 CAE4 CBFA 933A 5A21 45D5 FF97 C53F 183C 045D.
Author Address: ricochet: rs7ce36jsj24ogfw or john.brooks@dereferenced.net.
Tor gives users the ability to hide their location, while providing various types of services, from web publishing to instant messaging. Using 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 over the Tor network before being able to join it. The service randomly selects repeaters, builds chains for them, and makes them their “dating” points, providing them with their public key. In the pictures, the green lines are chains, not direct connections. When using full-fledged Tor chains, it is very difficult to bind the dating point to the IP address of a hidden service. Although the public key is accessible to many, the IP address of the hidden service should not be disclosed.
Step two: the hidden service collects its descriptor containing the public key and brief information about each of the meeting points, and signs this with a private key. It uploads a handle to a distributed hash table. Customers will find a handle for XYZ.onion, where XYZ is a 16-character name based on the 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 the points of acquaintance, the directory of the distributed hash table, and of course, customers, can confirm that he is communicating with the desired hidden service. It is believed that of the three points - “decentralized, safe and meaningful for humans”, you can usually choose no more than two.
Step three: a client who wishes to connect to a hidden service must find out 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, it is not abandoned and has not made typos 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, passing him a one-time secret key.
Step four: when the descriptor exists and the meeting point is prepared, the client collects an introductory message (encrypted with the public key of the hidden service), including the address of the meeting point and a one-time secret key. The client sends it to one of the points of acquaintance with a request to transfer it to a hidden service. Again, communication takes place through the Tor chain, no one can associate the sending of an introductory message with the client's IP address, and the client remains anonymous.
Step five: 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 the greeting message.
In the last step, the meeting point notifies the client of a successful connection. After that, the client and the hidden service use chains built up to the meeting point to communicate with each other. The point simply broadcasts encrypted messages back and forth.
In general, the full connection between the client and the hidden service consists of 6 relays: 3 are selected by the client (one of them is the meeting point), and the other three are selected by the hidden service.
Create an instant messaging system with the following properties:
- users are not identified by contacts or addresses
- communication is authenticated and takes place in private mode
- no one has access to the contact list, message history or other metadata
- resists censorship and tracking at the local network level
- resists the use of blacklists or DOS
- accessible and understandable for ordinary users
- reliability and interactivity comparable to traditional IM
The identity of each user is represented by a hidden service and its point of contact. 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.
While 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 communication requests.
Known contacts use a special protocol to send messages over established connections.
As in classic 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 the contact and various information is provided, including the id of the sender of the request. The sender, while online, periodically tries to establish a connection.
The request includes:
- the name of the recipient's hidden service
- a random cookie created at the beginning of the connection by the recipient
- a random secret key that the recipient uses to confirm the connections
- the full public key associated with the hidden service and confirming the identity of the sender
- possibly a nickname and a short greeting message
- signing this RSA information using the same public key The
recipient calculates the sender's id based on the public key and confirms it by verifying the signature of the request. This confirms the right of the sender to use the hidden service represented by his id. The
recipient can accept or reject the request. A rejected public key can be blacklisted and automatically rejected in the future
While online, the service periodically tries to communicate with each of the contacts. If successful, the connection remains open and the contact is considered to be online. For each of the contacts you need one connection, no matter which of the two contacts was its initiator.
The hidden service layer 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-distributed random key created immediately after the contact request.
For communication, a simple binary command-response protocol is used. He is trying to add reliability to unstable connections. For simplicity and full control over the process, in order to exclude the possibility of attacks on security and anonymity of communication, the original protocol is used, and not one of the ready-made options (like XMPP).
The protocol includes the ability to check versions for future development.
An interface is an important and often underestimated part of security and anonymity. Less technical savvy users should easily understand how to use the program and what needs to be done to stay safe.
The Ricochet interface tries to be simple and straightforward for those who have used other instant messaging managers. An understanding of Tor and network concepts is not required. It should be simple 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
The protocol described here is close to the simplest option. More advanced protocols may allow file transfers or streaming audio and video. A more advanced use of hidden services can reduce the risks of opening a service with public access. You can also use shared services or more complex services to prevent attacks. Naturally, ideas and assistance in the development of the project are welcome.
Anonymous serverless instant messaging system that just works
Ricochet is an experiment with an alternative method of instant messaging that does not trust anyone - does not reveal your identity, contact list or communication.
- You can communicate without revealing your identity or ip address.
- no one can find out with whom you are communicating or when you are communicating (no meta data)
- no servers that could be hacked, or operators that could be forced to give out information about you
- cross-platform and simple even for regular users
Note: the project has recently been renamed from Torsion.
How it works
Ricochet is a peer-to-peer instant messaging system based on Tor's hidden services. Your login is the address of your hidden service, and your contact connects to you (without the participation of intermediary servers) via Tor. The interaction system is designed so that it is very difficult to establish your identity based on your address.
Ricochet is not affiliated with or sponsored by The Tor Project developers.
Experiment
The project is experimental. No one conducted a formal audit of the code. Security and anonymity are complex topics, and you need to independently assess the risks of being exposed when using any software. We do not recommend relying on Ricochet for security and do not trust Ricochet more than necessary. Although I, as a developer, are sure that my project gives you more privacy than any other similar one.
Download
Ricochet is available for Windows, OS X (10.7 and higher), there is also a generic Linux binary package. Release information and release history are available on the respective pages.
They are also available on the project website .
Binaries are signed through PGP 9032 CAE4 CBFA 933A 5A21 45D5 FF97 C53F 183C 045D.
Author Address: ricochet: rs7ce36jsj24ogfw or john.brooks@dereferenced.net.
Tor: how the hidden services protocol works
Tor gives users the ability to hide their location, while providing various types of services, from web publishing to instant messaging. Using 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 over the Tor network before being able to join it. The service randomly selects repeaters, builds chains for them, and makes them their “dating” points, providing them with their public key. In the pictures, the green lines are chains, not direct connections. When using full-fledged Tor chains, it is very difficult to bind the dating point to the IP address of a hidden service. Although the public key is accessible to many, the IP address of the hidden service should not be disclosed.
Step two: the hidden service collects its descriptor containing the public key and brief information about each of the meeting points, and signs this with a private key. It uploads a handle to a distributed hash table. Customers will find a handle for XYZ.onion, where XYZ is a 16-character name based on the 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 the points of acquaintance, the directory of the distributed hash table, and of course, customers, can confirm that he is communicating with the desired hidden service. It is believed that of the three points - “decentralized, safe and meaningful for humans”, you can usually choose no more than two.
Step three: a client who wishes to connect to a hidden service must find out 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, it is not abandoned and has not made typos 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, passing him a one-time secret key.
Step four: when the descriptor exists and the meeting point is prepared, the client collects an introductory message (encrypted with the public key of the hidden service), including the address of the meeting point and a one-time secret key. The client sends it to one of the points of acquaintance with a request to transfer it to a hidden service. Again, communication takes place through the Tor chain, no one can associate the sending of an introductory message with the client's IP address, and the client remains anonymous.
Step five: 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 the greeting message.
In the last step, the meeting point notifies the client of a successful connection. After that, the client and the hidden service use chains built up to the meeting point to communicate with each other. The point simply broadcasts encrypted messages back and forth.
In general, the full connection between the client and the hidden service consists of 6 relays: 3 are selected by the client (one of them is the meeting point), and the other three are selected by the hidden service.
Ricochet Design Technical Notes
Project objectives
Create an instant messaging system with the following properties:
- users are not identified by contacts or addresses
- communication is authenticated and takes place in private mode
- no one has access to the contact list, message history or other metadata
- resists censorship and tracking at the local network level
- resists the use of blacklists or DOS
- accessible and understandable for ordinary users
- reliability and interactivity comparable to traditional IM
Introduction
The identity of each user is represented by a hidden service and its point of contact. 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.
While 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 communication requests.
Known contacts use a special protocol to send messages over established connections.
Contact Request
As in classic 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 the contact and various information is provided, including the id of the sender of the request. The sender, while online, periodically tries to establish a connection.
The request includes:
- the name of the recipient's hidden service
- a random cookie created at the beginning of the connection by the recipient
- a random secret key that the recipient uses to confirm the connections
- the full public key associated with the hidden service and confirming the identity of the sender
- possibly a nickname and a short greeting message
- signing this RSA information using the same public key The
recipient calculates the sender's id based on the public key and confirms it by verifying the signature of the request. This confirms the right of the sender to use the hidden service represented by his id. The
recipient can accept or reject the request. A rejected public key can be blacklisted and automatically rejected in the future
Connections between pins
While online, the service periodically tries to communicate with each of the contacts. If successful, the connection remains open and the contact is considered to be online. For each of the contacts you need one connection, no matter which of the two contacts was its initiator.
The hidden service layer 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-distributed random key created immediately after the contact request.
For communication, a simple binary command-response protocol is used. He is trying to add reliability to unstable connections. For simplicity and full control over the process, in order to exclude the possibility of attacks on security and anonymity of communication, the original protocol is used, and not one of the ready-made options (like XMPP).
The protocol includes the ability to check versions for future development.
Interface and stability
An interface is an important and often underestimated part of security and anonymity. Less technical savvy users should easily understand how to use the program and what needs to be done to stay safe.
The Ricochet interface tries to be simple and straightforward for those who have used other instant messaging managers. An understanding of Tor and network concepts is not required. It should be simple 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
Future development
The protocol described here is close to the simplest option. More advanced protocols may allow file transfers or streaming audio and video. A more advanced use of hidden services can reduce the risks of opening a service with public access. You can also use shared services or more complex services to prevent attacks. Naturally, ideas and assistance in the development of the project are welcome.