Privacy on the Retroshare Network

Introduction

We are seeing the gradual erosion of personal privacy on the Internet. Like the boiling frog metaphor, it might be too late by the time the world wakes up. Retroshare is our attempt at providing privacy for the world.

Retroshare allows you to communicate privately with you friends and family. It is designed to minimise the amount of information shared with people that do no know or trust.

Retroshare is a completely decentralised system, which means that we (the developers) know nothing about how you choose to use Retroshare. However, because it is decentralised some information must be shared publicly to enable the Network to function.

This blog post explains what information is exposed by Retroshare. There is normally a good reason why particular information is shared, and often an option to disable this sharing – if you don’t want to.

Connecting you with your Friends

One of the most challenging parts of Retroshare is connecting you and your friends. To do this we have to find your internet address (which can change every 24 hours with some ISPs) and bypass Firewalls before we can even communicate.

The table below demonstrates the options for finding your friends, and the privacy implications:

IP_grid

Notes:

  1. If your DHT Key is known (this requires your location ID), your RS usage and external IP address can be tracked.
  2. if you DynDNS address is known your external IP address can be tracked

By default the DHT and Discovery are enabled, but each of these services can be switched on or off. It is important that you have at least one of these services switched on, otherwise you will not be able to connect to your friends if you and your friends change IPs and/or live behind a firewall.

DHT: A Public Phonebook.

Retroshare uses a Distributed Hash Table (DHT) to locate your friends. When you run Retroshare, it becomes part of the DHT network which allows people to find and connect to you.

The DHT uses a One Way Hash Function: Hash( RS ID ) => as the Key on the DHT. A person (Friend or Foe) that knows your RS ID, can use it to find your IP address, and *try* to connect to you.

This is every similar to a Phonebook. It provides enough information to allow them to “Call” You, but that cannot talk to you unless you “answer the phone”, which is Retroshare means you have added them as a Friend.

Discovery: Getting to know your Neighbourhood

Retroshare shares your Friends List with other Friends. This means you know about many of the Friends of Friends,

This is similar to the “Add Friends” features that are present on Social Networks like Facebook. It allows you to see the Local social network around you, and potentially add friends of friends that you might know.

The discovery system is also especially useful at providing friend IP addresses if either of you have the DHT service switched off. Turning discovery off, makes you invisible to the friends of your friends since your friend’s Retroshare will respect this setting.

DynamicDNS: The Alternative

If you do not want to use the DHT and Discovery service, the best alternative is setting up a free dynamic DNS service (e.g: http://dnslookup.me/dynamic-dns/). This DNS name should be added to your certificate, so that friends can use it to look up your IP address.

This is a bit more effort than using the DHT and Discovery Services, and is probably only suitable for advanced users.

Retroshare Communication Services

Retroshare provides a range of services to communicate with friends:

  • Direct Chat and Messages and VoIP are private, no-one is able to listen into the communications.
  • The Chat Lobby, Forums and Channels are network wide services, and should be considered public.
  • Public group chat is visible from all connected friends, so it is understood as not publicly visible from the rest of the network.

Except for Authenticated Forums, forum messages are not associated with the creator. Messages are passed from friend to friend, throughout the network, consequentially nodes know which peers among friends are subscribed to a particular forum or channel, but not the original source of the message. Analysis of message timing could potentially be used to help identify the source of a message. However once the message has travelled over several hops this analysis will yield little. Once again, another reason to only add friends you trust into Retroshare.

This is summarized in the table below:

public_grid

The network-wide information you send into the network should be considered public, as retroshare users that you do not know will potentially have access to the messages. However these messages are only communicated to subscribed users, that are directly connected to you via a chain of friends, and are not accessible from outside of the Retroshare network.

Conclusions

Retroshare is designed to protect the content you consume and create. This is achieved by transmitting all communication via your friends.

This means:

  • Behaviour is untrackable by Advertisers and Corporations.
  • Protects you from mass surveillance from Governments and ISPs.
  • Uncensorable content as no-one controls the network.

To make this decentralised network it is necessary to share some information publicly. The default setting of Retroshare are designed to achieve a good balance between connectivity and privacy.

This entry was posted in Networking. Bookmark the permalink.

3 Responses to Privacy on the Retroshare Network

  1. Victor says:

    Good information!
    Thanks for the article! 😀

  2. Waleed says:

    Hello,

    Thanks for the informative article! I have some questions and a suggestion.

    I guess that the RS ID is one’s PGP public key or something else sent to friends with one’s public key. If so, it might be easy for it to be discovered. In that case I have the following suggestion.

    How about avoiding having one’s IP address be known to anyone who knows one’s RS ID by keeping the RS ID secret? Is it possible for someone to retrieve the entire distributed hash table and search it (with a linear search–even though exact match is the usual rule for hashing) for all RS users (even though if the RS ID is not known, they would be anonymous RS users)?

    About keeping one’s RS ID secret, one could send it to one’s friends encrypted (even if it is not considered to be secret in ordinary usage). Even though I could do this manually by setting up PGP in advance, making a separate key-pair for RS, then sending that to my friends as encrypted email, RS could make this easier by having two RS IDs, one permanent and one transitory. Send the transitory one to friends in clear text. Then after establishing the connection send the permanent one (which would therefore have been sent encrypted). Delete the transitory one from the distributed hash table (or modify it to the same effect, if delete is not directly supported).

    In that way, I only have to have my publicly discoverable Hash( RS ID ) in the DHT during the time when I am connecting with new friends, possibly a very short time, yet I can keep my permanent ID in the DHT until the size of my friends network becomes sufficiently large to make DHT unnecessary (and that while my IP address remains anonymous).

Leave a comment