Distant chat and messaging, using generic tunnels

• Component: distant chat and messaging
• Development: March 2013 – July. 2013
• Status: released (trunk > 6567)

Intro

The life of the Retroshare network is all about communication. People keep using it because they can talk to each other, exchange data, and broadcast some useful information to others. Chat and messages with friends are certainly useful in that matter.

Still, the number of friends one can have in the network is limited. Trust issues, for a start, might prevent you from making friends with many peers. Another issue is that it is advised to limit the number of direct friends so that broadcasting services (such as the tunnel requesting system for file transfer) only take an acceptable part of the bandwidth. A rule of thumb for an asymmetric DSL connexion is to have at most 30-40 online friends at a given time.

Forums certainly offer a way to exchange information, but they are not private (everyone can read) and do not provide means to an interactive conversation.

Distant chat and messages certainly fill a gap, by allowing authenticated and private messages to travel between non friends using tunnels. They can be used in particular for contacting peers that try to connect to you, or for establishing a secured chat between two people who otherwise meet in a chat lobby.

Extension of the tunnelling service

To allow services to interact with distant peers anonymously, we have extended the tunnelling service to be used by any other service in the Retroshare network. That means:

• services can ask to open tunnels, based on a sha1 hash;
• once tunnels are opened, the tunnelling service warns the client service that new virtual peers are “online”;
• the client service can send data to the virtual peer;
• tunnels can route arbitrary data, using a generic data type. That makes it possible to two distant peers sharing a service that is unknown to intermediate peers to exchange data (a plugin service for instance).

The main client of the tunnelling service is of course the anonymous file transfer system. But now additional services may use tunnels, in particular the chat and messaging services. The figure below shows the data flow between the tunnelling service and an arbitrary client service (e.g file transfer):

The tunnelling service does not ensure the data integrity, nor its confidentiality. It’s the service’s responsibility to do that. We made that choice for robustness reasons, since tunnels can die unpredictably (e.g. when a peer in the middle disconnects).

File transfer, for instance manages multiple tunnels per hash, and asks chunks again if they cannot be obtained or got corrupted after the previous request. Since the file transfer uses anonymous sources, it’s not possible to perform end-to-end encryption of the traffic along a tunnel in a way that can resist a man-in-the-middle attack.  Each peer in the middle can therefore “spy” file chunks. For file transfer, that is not an issue of course.

Messaging and chat however need confidentiality. Therefore messages are end-to-end encrypted. This is made possible by two different mechanisms: distant chat uses a pre-shared symmetric AES key, that is known only from the two chatting peers. Distant messages are encrypted using the PGP public key of the destination and possibly signed by the source.

Distant Chat

The distant chat system provides additional peers to talk to, making it quite transparent for the chat service. The chat service only needs to route packets which destination is not recognised as a real friend, to the distant chat.

Distant chat packets are encrypted using AES256 (OpenSSL implementation). The encryption key for each packet is created from a pre-shared key (16 random bytes) and a random 8-bytes initialization vector. Each packet to be sent is first serialized, then encrypted, then turned into a GenericTunnelDataItem, that gets sent into the tunnel.

The way it is designed, the distant Chat offers the same services as classical private chat. In particular, avatar exchange and “peer is typing” notifications work out of the box. We had to add a few additional information exchange items to warn the peers that the tunnel has been closed/re-opened and keep-alive packets to allow maintaining the tunnel even if the peers are not sending any message.

Distant messages

Distant messages are received by the messaging system as normal messages, with a flag indicating that they are encrypted. The user decrypts them using his/her private PGP key. Then the message is stored in clear in place of the encrypted message, with the same message ID.

The structure of a distant message packet is the following:

• all the data is encrypted. Therefore, it is not possible for an intermediate peer to know the source nor the destination of a message. However, the destination can be guessed by brute-forcing the known key IDs.
• the source of the message (Key ID, in the diagram) is not known.
• the message can possibly be signed.

Only when the message is received, can it be decrypted by the destination peer. Then the message will be turned into a clear message, the signature will be checked, and the source key ID will be known. This system needs the user to decrypt a message in order to know anything about it, but it prevents any replacement of any part of the data by intermediate peers in the tunnel.

The Invite system

The invite system allows Retroshare users to exchange invitations for messages and chat through tunnels. This is made possible using the Retroshare http Links mechanism. Invite links  encode the information that a user needs in order to send a message or chat to some other peer who invites him to. Some of that information is encrypted, some is not, depending on the type of link. This is summarized in the table below:

Links can be copied/pasted and exchanged in any other service of Retroshare, which makes it quite convenient to send invites to other people. A private chat invite will look like:

retroshare://private_chat?time_stamp=1373738860&gpgid=660FB771727CE286&encrypted_data=wcen[…]ymhU=

The encrypted data contains a hash (for the chat service to ask tunnels to), a 16-bytes shared key, both signed by the PGP key of the issuer of the link.

For distant messages, we have 3 levels that correspond to a different compromise between confidentiality and how easily one can be reached:

1. Universal: the peer can be reached by anyone, and will accept all messages.
2. Open: the peer can be reached by anyone who knows the hash, for the time the hash is valid
3. Private: the peer can only be contacted by the destination of the invite.

Note: At the time of writing this post, we only have implemented method 1 for distant messages. Distant message invites are implicit, since the hash to reach a given peer is the SHA1 hash of its PGP id. Distant chat invites are collected in the GUI. See for instance config->chat->Distant chat.

GUI

The changes in the GUI are quite limited. Basically:

• In Config->Chat->Distant chat, the user can collect/forge distant chat invites;
• the Chat dialog that normally handles chat has been improved to display tunnel state;
• distant messages now accept PGP keys for a destination, rather than location ID;
• users need to enable the reception of distant message in config -> Messages.
• it is possible to contact a peer who tries to connect to you, as soon as his PGP key is known.

Distant chat invites can be pasted anywhere in the software as retroshare links. Only the destination of the invite will be able to use it, which he will do by clicking on it. On this action, the software asks for the PGP passphrase to decrypt the link, and then stores the decrypted link in the list of distant chat invites.

Security

Obviously tunnels can be used to find whether you are online or not. This is not a big threat, since the DHT provides the same “feature”. Distant chat and messaging are both resistant to spying by intermediate peers: man in the middle attacks are not possible.

Malicious peers can accept tunnel requests that they would normally reject, in order to establish a chat or a messaging tunnel. This will lead to collecting gibberish information in both cases, since the incoming data will be encrypted with an unknown key.

Malicious peers along a tunnel can block the data, or corrupt it. In both cases the distant peer won’t receive the data, or will not be able to decipher it. They cannot however modify the message inside the encrypted layer in a consistent way. Returning the message back, or delaying it, from in the middle of a tunnel is also a possibility, although it’s not a terrible threat per se.

Finally, it is not possible to replace a distant message signature by the signature of another key, since the signature is encrypted with the PGP key of the destination peer.

Limitations

Although distant chat makes your chatting partner appear like a normal peer, information about chat lobbies are not allowed into distant chat tunnels. This would make possible to subscribe a chat lobby that is not shared by direct friends, and therefore make your connexion to the chat lobby very sensitive to disconnections.

Distant messages need both peers to be online at the same time. This might be a limitation in some situations.

Future developments

In the future, it will be possible to send distant messages to other peers than GPG key owners. Since we’re currently working on the possibility to manage multiple anonymous identities, peers will be able to send messages to these identities as well. This will be a great way to anonymously exchange messages.

We’re also currently thinking of a “global routing matrix”, that will make it possible to up-stream route data packets in the direction where pseudo identities have previously flowed.