How Ricochet IM works

Ricochet is instant messaging software that communicates over Tor, authenticates peers by their Tor onion address, and communicates directly peer-to-peer (via Tor hidden services) without any centralised servers involved.

Using Tor has lots of benefits over raw TCP:

• Doesn't leak metadata (all an observer can see is that you're using Tor)
• Built-in peer authentication (peers are identified by a hash of their public key)
• Direct peer-to-peer communication with no NAT traversal tricks required

If you want to try out Ricochet, you can get it from ricochet.im, or from your Linux distro package manager. In Ubuntu:

$ sudo apt install ricochet-im

Protocol overview

The software is dead easy to use. You just add a contact by their Ricochet ID, and when they're online you can chat. All of the underlying complexity is abstracted away. But we're here to discuss the underlying complexity:

When you want to speak to someone who is using Ricochet, you connect to the hidden service described by their Ricochet ID on port 9878 (so ricochet:it2j3z6t6ksumpzd is equivalent to what would be called it2j3z6t6ksumpzd.onion:9878 in usual parlance). You then have to authenticate yourself to prove who you are (see "Peer authentication" below). Having authenticated, you can now use this connection to send messages which will be delivered to the remote user, and the remote user can send messages to be delivered to you. It's basically as simple as that.

You can read a more thorough description in the Ricochet protocol documentation. Almost all of the heavy lifting is palmed off to Tor. This is a good design and I think many other protocols could benefit from it. For example, Bitcoin's Lightning Network would be more private and easier to configure if it always used Tor hidden services instead of IP addresses (i.e. you wouldn't have to write your IP address in the config file, or care if your IP address changes, or configure port forwarding on a home router, or worry that your ISP can see that you're using Lightning, etc.). The only downside of Tor-by-default is that it has high latency and low bandwidth, but for most applications that is not a problem and the privacy and ease-of-use wins more than make up for it. There is certainly low-hanging fruit to be eaten here.

Peer authentication

Most of the protocol is symmetrical, which means it doesn't matter which side of the connection is the "server" and which side is the "client": both sides can send messages just the same. Peer authentication is the only part that is not symmetrical.

When you connect to a Tor hidden service, you know you're talking to the right place. The onion address is a hash of the hidden service's public key, so it is impossible for anybody who does not hold the corresponding private key to decrypt the messages you're sending.

But when someone connects to your Tor hidden service, you have no idea who they are! Ricochet's answer to this is to have both client and server generate a (one-time, random) 16-byte authentication cookie, and then have the client compute a SHA256 HMAC of the concatenation of the client's and server's onion addresses, using the concatenation of the client's and server's cookies as a key, and then sign this HMAC using the client's hidden service private key. The signature is then passed to the server, who computes the same HMAC using the same parameters, and then verifies the signature. If the signature checks out, then the client holds the private key that corresponds to the public key it presented.

The purpose of having the server generate a random cookie is to prevent replay attacks (i.e. even if you manage to observe the unencrypted communication stream of a client authenticating with a server once, you can't reuse that yourself to impersonate that client as the server will present a different cookie next time, and you will need to produce a signature for the new HMAC). The client's cookie would not appear to serve any security purpose.

Practical attacks

I briefly looked through the Ricochet source to see if there were any obvious mistakes in obvious places and could not find any. It has also been audited by NCC Group.

A friend who is more of an expert on Tor than I am told me, after I asserted that Ricochet is as good as it is possible for it to be, that he likes Ricochet but would like it more if it used V3 hidden services. This is a less-trivial fix than it sounds because the peer authentication leverages the underlying cryptography, but it would be possible to do and hopefully somebody will implement it one day.

What can a man-in-the-middle see?

A man-in-the-middle of your internet connection (say, your ISP) would be able to see that you're using Tor, but not know anything else. In particular, they wouldn't even be able to find out whether you're using Ricochet, other than by guessing based on inbound and outbound bandwidth usage. This is substantially better than approximately all other instant messaging software. The reason for this is that the underlying protocol is obscured (because Tor), and there are no instant messaging servers to give the game away (because Tor hidden services; but even if there were Tor-based servers, the ISP still wouldn't know you were using them, because Tor).

Checking if someone is online

If you know someone's Ricochet ID, then you can tell whether they are online even if they do not accept your contact request. Simply try to initiate a connection to their hidden service and see if it is available. If it is, they're online. If it's not, they're not.

There is unfortunately no obvious way to solve this problem as there is no way to know who is connecting to your hidden service until after they've gone through peer authentication. But by the time they've gone through peer authentication, they already know that you're online.

Traffic correlation

If you can observe somebody's internet traffic (say, you're their ISP) and you know a bunch of Ricochet IDs that they might be using, you can repeatedly initiate connections to the Ricochet IDs and watch for corresponding Tor activity on their internet connection. If it's reliably quiet while you're doing nothing, and busy while you're doing something, for a certain Ricochet ID, then you can be quite sure that you have worked out their Ricochet ID.

Malicious hidden service directories

Tor hidden service directories are ordinary Tor relays that have been stable for long enough to get trusted as hidden service directories. Hidden service directories get to find out onion addresses. Given an onion address, you need only connect to that hidden service and try to speak the Ricochet protocol to find out whether it is a Ricochet ID (and the same applies for any other application). For this reason, there are unfortunately a lot of malicious hidden service directories which are set up for the express purpose of surveilling the Tor network.

There's not a lot you can do about this. And there's not too much reason to worry about it, as long as you remember that just receiving a contact request from someone doesn't mean that the person who sent the request found out your Ricochet ID through some legitimate means.

Conclusion

Ricochet IM is almost as good as it is possible for it to be. It doesn't leak any information at all about who you're talking to or what you're saying. It only leaks a bare minimum of information about the fact that you're using Tor. Even if somebody finds out your Ricochet ID, it is impossible to link it to a physical-world identity without either tricking you into clicking a URL (thereby discovering your IP address, or implanting malware), or privileged access to your internet connection with which to conduct some traffic analysis. The worst part about Ricochet is that hardly anybody is using it, and I want to change that.