Ricochet - anonymous serverless instant messaging protocol
Translation of the introductory part and introduction to the technical description of the open source project Ricochet ( github ).
Ricochet is an alternative instant messaging experiment that doesn’t trust anyone — it doesn’t reveal your identity, contact list, or communication.
- you can communicate without revealing your identity or ip-address.
- no one can figure out with whom you are communicating or when you are communicating (no meta-data)
- no servers that could be hacked, or operators who could be forced to give out information about you
- cross-platform and easy even for regular users
')
Note: The project has recently been renamed from Torsion.
Ricochet is a peer-to-peer instant messaging system based on the use of hidden Tor 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 system of interaction is designed so that it is very difficult to establish your identity, based on your address.
Ricochet is not affiliated with or agreed with the developers of The Tor Project.
The project is experimental. No one conducted a formal code audit. Security and anonymity are complex topics, and you need to independently assess the risks of being revealed when using any software. We do not recommend relying on Ricochet in terms of security and not trusting Ricochet more than necessary. Although I, as a developer, am confident that my project gives you more privacy than any other similar.
Ricochet is available for Windows, OS X (10.7 and higher), there is also a generic Linux binary package. Release information and release logs are available on the relevant pages.
They are also available on the project website .
The binaries are signed with PGP 9032 CAE4 CBFA 933A 5A21 45D5 FF97 C53F 183C 045D.
Author's 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 on the Tor network before it can be joined. The service randomly selects repeaters, builds chains for them, and makes them its points of “acquaintance”, giving them its public key. In the pictures, the green lines are chains, not direct connections. When using full Tor chains it is very difficult to tie a 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.
Step two: the hidden service collects its descriptor containing the public key and brief information about each of the points of acquaintance, and signs it with the private key. It uploads a handle to a distributed hash table. Clients will find a handle at the request of XYZ.onion, where XYZ is a 16-character name created from the public key. After that, the hidden service is running.
Using the 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, the customers, can confirm that it is communicating with the desired hidden service. There is an opinion that out of three points - “decentralized, safe and meaningful for a person”, you can usually choose no more than two.
Step three: a client who wishes to connect to a hidden service should know his onion address. After that, he needs to download the handle from the distributed hash table. If there is a descriptor for XYZ.onion (and if the service is online, not abandoned and made no 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 repeater and makes it a meeting point, giving 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 connect the sending of the introductory message with the client's IP address, and he 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 welcome 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. Point simply transmits the encrypted message 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.
Create an instant messaging system with the following properties:
- users are not identified by contacts or addresses
- communication is authenticated and is private
- no one has access to the list of contacts, message history or other metadata
- resists censorship and tracing at the local network level
- resists using blacklists or DOS
- accessible and understandable for ordinary users
- reliability and interactivity is 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 an 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 bilateral anonymous connections, which are either identified as known contacts or used to receive requests for communication.
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, which states that the connection is established for the contact request and provides various information, including the sender's id. The sender, while online, periodically tries to establish a connection.
Request includes:
- the name of the hidden service recipient
- random cookie created at the beginning of the connection by the recipient
- random secret key that the recipient uses to confirm connections
- the full public key associated with the hidden service and confirming the identity of the sender
- perhaps a nickname and a short welcome message
- Signing this RSA information with the same public key
The recipient counts 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. You can add a rejected public key to the blacklist and automatically reject in the future
Being 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 confirmations - so the application protocol is very simple. The client part of the connection is confirmed by a previously 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 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 options (like XMPP).
The protocol includes the ability to check versions for future development.
The 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 to do to stay safe.
The Ricochet interface tries to be simple and straightforward for those who have used other instant messaging managers. Understanding Tor and network 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 specialists to expand the program
The protocol described here is close to the simplest option. More advanced protocols can allow file transfer or streaming audio and video. More advanced use of hidden services can reduce risks when opening a publicly accessible service. You can also use shared services or more sophisticated services to prevent attacks. Naturally, ideas and development assistance are welcome.
Anonymous serverless instant messaging system that just works
Ricochet is an alternative instant messaging experiment that doesn’t trust anyone — it doesn’t reveal your identity, contact list, or communication.
- you can communicate without revealing your identity or ip-address.
- no one can figure out with whom you are communicating or when you are communicating (no meta-data)
- no servers that could be hacked, or operators who could be forced to give out information about you
- cross-platform and easy 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 the use of hidden Tor 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 system of interaction is designed so that it is very difficult to establish your identity, based on your address.
Ricochet is not affiliated with or agreed with the developers of The Tor Project.
Experiment
The project is experimental. No one conducted a formal code audit. Security and anonymity are complex topics, and you need to independently assess the risks of being revealed when using any software. We do not recommend relying on Ricochet in terms of security and not trusting Ricochet more than necessary. Although I, as a developer, am confident that my project gives you more privacy than any other similar.
Download
Ricochet is available for Windows, OS X (10.7 and higher), there is also a generic Linux binary package. Release information and release logs are available on the relevant pages.
They are also available on the project website .
The binaries are signed with PGP 9032 CAE4 CBFA 933A 5A21 45D5 FF97 C53F 183C 045D.
Author's 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 on the Tor network before it can be joined. The service randomly selects repeaters, builds chains for them, and makes them its points of “acquaintance”, giving them its public key. In the pictures, the green lines are chains, not direct connections. When using full Tor chains it is very difficult to tie a 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.
Step two: the hidden service collects its descriptor containing the public key and brief information about each of the points of acquaintance, and signs it with the private key. It uploads a handle to a distributed hash table. Clients will find a handle at the request of XYZ.onion, where XYZ is a 16-character name created from the public key. After that, the hidden service is running.
Using the 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, the customers, can confirm that it is communicating with the desired hidden service. There is an opinion that out of three points - “decentralized, safe and meaningful for a person”, you can usually choose no more than two.
Step three: a client who wishes to connect to a hidden service should know his onion address. After that, he needs to download the handle from the distributed hash table. If there is a descriptor for XYZ.onion (and if the service is online, not abandoned and made no 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 repeater and makes it a meeting point, giving 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 connect the sending of the introductory message with the client's IP address, and he 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 welcome 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. Point simply transmits the encrypted message 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.
Ricochet Design Technical Notes
Project Goals
Create an instant messaging system with the following properties:
- users are not identified by contacts or addresses
- communication is authenticated and is private
- no one has access to the list of contacts, message history or other metadata
- resists censorship and tracing at the local network level
- resists using blacklists or DOS
- accessible and understandable for ordinary users
- reliability and interactivity is 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 an 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 bilateral anonymous connections, which are either identified as known contacts or used to receive requests for communication.
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, which states that the connection is established for the contact request and provides various information, including the sender's id. The sender, while online, periodically tries to establish a connection.
Request includes:
- the name of the hidden service recipient
- random cookie created at the beginning of the connection by the recipient
- random secret key that the recipient uses to confirm connections
- the full public key associated with the hidden service and confirming the identity of the sender
- perhaps a nickname and a short welcome message
- Signing this RSA information with the same public key
The recipient counts 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. You can add a rejected public key to the blacklist and automatically reject in the future
Connections between pins
Being 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 confirmations - so the application protocol is very simple. The client part of the connection is confirmed by a previously 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 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 options (like XMPP).
The protocol includes the ability to check versions for future development.
Interface and stability
The 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 to do to stay safe.
The Ricochet interface tries to be simple and straightforward for those who have used other instant messaging managers. Understanding Tor and network 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 specialists to expand the program
Future development
The protocol described here is close to the simplest option. More advanced protocols can allow file transfer or streaming audio and video. More advanced use of hidden services can reduce risks when opening a publicly accessible service. You can also use shared services or more sophisticated services to prevent attacks. Naturally, ideas and development assistance are welcome.
Source: https://habr.com/ru/post/242535/
All Articles