After a long time working on this release, we’re proud to finally announce the release of Retroshare 0.6 !
Note: additional information is available on the final release post here.
The network paradigm has changed a little bit: Retroshare still offers the possibility to securely connect nodes using SSL links, authenticated by PGP signatures. But now, in addition, the users have the possibility to create pseudo-anonymous identities which can be used to sign forum posts, talk in chat lobbies, send distant messages, etc. This decorrelates the identities from the actual nodes of the Retroshare network.
We also took the opportunity to change a lot of low level protocols, and pushed a significant number of long waiting changes. As a result, the new 0.6 version is not compatible with the 0.5 version. That means you will need to upgrade your friends too if you want to keep them. Of course, the PGP keyrings and signatures stay, so your web of trust stays intact. In order to make the transition easy, we made it possible to use both Retroshare 0.5 and 0.6 on the same computer simultaneously. Linux executables and packages being 100% independent (except for the keyrings)
What hasn’t changed a bit is the rule of thumb: all the data that comes or leaves your node get through your trusted friends.
Major new features
Version 0.6 brings some very cool features. A separate blog post will probably cover some of these topics in the near future.
When talking over the Retroshare network(s) you need to be able to consistently know who posted which information, whereas that person might not want to be tracked either.
We solved that problem by adding pseudo-anonymous identities. These are RSA key pairs that can be used to encrypt/sign/authenticate posts. They can be either signed by your PGP key (which makes them extremely hard to impersonate) or anonymous (quite impossible to trace).
The new “People” tab allows you to manage your own identities (you can have as many as you want) and also displays the identities relevant to your own local view of the network. Every time an identity is needed, it is asked to your friends, along the flow of data that also uses the same identities. Forum posts for instance are signed by these identities, and the public keys that allow to check the signatures can always be requested to whoever transmitted the post to you.
Pseudo identities can have avatars, Utf8 encoded names, etc. The only not-yet-activated thing is the ability to make groups out of them, and control access to data in the network based on these groups. But this is ongoing development.
Hidden Nodes using Tor
Retroshare now offers—as an option—the possibility to create nodes that are only visible through the Tor network, represented by an onion address. As such, users of a hidden node totally hide their IP address even from their own friends. Hidden nodes do not use the DHT, and only share .onion addresses through the network discovery system. Hidden nodes do not use “Tor exit nodes” either except when talking to non hidden nodes. Beyond anonymity, hidden nodes are an excellent way to bypass firewalls, at the cost of an insane amount of crypto (basically DHE-SSL over Tor 😉 ).
Connecting to a hidden node is also possible if running a normal node, as soon as you are also running Tor on your machine (without any further configuration). Just make sure the Tor proxy port is correctly given in config/server/Tor (9050 is the default). Each hidden node you connect to will appear with IP equal to 127.0.0.1.
In order to run your own hidden node, you need in addition to create a Tor hidden service: edit your Tor config file (e.g. /etc/tor/torrc on linux) and add:
HiddenServiceDir /var/lib/tor/retroshare/ HiddenServicePort 9023 127.0.0.1:5781
Now just launch Tor, and read the onion address (should look like uido4sbabwem5bq6.onion) that Tor created for your Retroshare node in
In the node creation manager at start, select “advanced” and then “Create a hidden node”. Supply your onion address and port:
Note that this can be changed afterwards in the server->Tor options. Also make sure to use the right port. In the node creation window, the port that is expected is the port in the Tor network (here 9023).
Integrated Web interface
Although we already had a web interface, we recently came up with a simpler and integrated web interface based on react.js and libmicrohttpd, thanks to the work of a new member of the team (thank you electron!). The web UI currently covers basic functions such as adding/removing friends, controlling file transfers and searching files. It is under heavy development at the time of writing this post.
The web UI works with both Retroshare-nogui and Retroshare. If enabled, it is basically accessible by pointing your web browser to localhost:9090 (or whatever port you chose for the web UI either in the config or using command line parameters of Retroshare-nogui):
/usr/bin/RetroShare06-nogui --webinterface 9090 \ --docroot /usr/share/RetroShare06/webui/
A clean and secure way to access the web UI from a distant machine is therefore to create a SSL tunnel to forward the local port: use Putty on Windows; on linux just do:
ssh firstname.lastname@example.org -L 1463:localhost:9090 -N
That command securely forwards port 9090 on server.com where Retroshare06-nogui runs, onto port 1463 on localhost (the machine from which you type the ssh command). From know on, you can access your web UI at localhost:1463.
Reshaped forums and channels, and new Posted service
Forum, Channels and Posted are 3 instances of services based on the new cache system (see below). They share the ability to post comments, vote over posts, and sign posts with pseudo-anonymous identities. From posts, you may send distant messages to forum posters, talk to them in the chat lobbies, or privately using a secured chat tunnel.
Non subscribed threads no not transfer anything more than the number of posts available and we also collect the number of friends who are advertising them, giving a reliable measure of popularity.
Posted is a new service which allows you to share html links and vote for them or comment them. It is not entirely finished yet, but still quite usable. So it is included in the RC of v0.6 as a way to get some feedback about how we may improve it.
Distant chat and distant messaging
The distant chat system now allows to talk to a Retroshare pseudo-anonymous identity using an encrypted tunnel. The tunnel is secured using DHE+AES and authenticated using the RSA key pairs that represent talking identities on both ends. A led indicates the status of the tunnel, which may be interrupted because of network topology changes. Nevertheless, tunnels soon reconfigure and you’re able to talk again. Nothing guaranties that a person is close enough to be reached that way, but the distant chat still offers the possibility to privately talk to a lot of people.
The distant messaging system also connects pseudo-anonymous identities using a multi-hop e-mail system, that is asynchronous (mails can be received after the source has disconnected). Messages are encrypted and signed using the identity RSA keys. The system also includes a signed receipt mechanism which is used to remove the message sent from the outbox. So when that happens, you can be sure that the destination got the email.
Fine service-based tuning
It is possible to disable services manually using a dedicated widget in the configuration window. The widget displays both your own enabling status and your friends enabling status. Only when both are ok does the data flow for each particular service.
Network statistics window
We did a bit of graphical work there. You can get from that window all sorts of statistics about what’s going on: bandwidth, tunnels, routing matrix, etc. with cool graphs to look at 😉
New certificate format
We got rid of the old ascii certificate format. The certs now look like a blind block of text, which—at the expense of ease of read—provides a lot more robustness and compactness. It’s quite impossible now to accidentally mis-cut or mis-copy one part of the certificate. We also improved the UI so that tooltips show the user the actual content of the certificate.
Improved file transfer
File transfer now supports multi-tunneling, which means that multiple tunnels can link the same (source, destination, hash) triplet. As a consequence the data flows more efficiently into the best tunnels at every moment during a transfer. The speed of transfers has also been improved. It is of course limited by the upload capacity of every link along a tunnel, but we drastically improved the handling of data which makes it possible to transfer along single links at up to 10MB/s, if the connection bandwidth allows it.
VOIP plugin now does video
Although not entirely satisfactory, we have already all the building blocks for a real Video chat system. The UI has been improved as well, so as to give a reasonable experience to the user. The codec we’re using currently is however extremely basic and therefore does not allow much control yet.
Retroshare has recently been “attacked” by what we think are network profiling actors who basically used the DHT to impersonate your friends and blindly relay the traffic between peers, without the ability to decrypt it. Still, such an attack would allow to progressively map the network and measure bandwidth. We contacted the abuse service of the related internet ranges but got no answer. So we implemented multiple measures to efficiently get rid of this problem:
- A black list system automatically collects suspicious IPs from multiple sources. (1) the DHT reports masquerading IPs when the same DHT peer claims to have multiple IPs at once; (2) friends exchange suspicious IPs using a dedicated service; (3) you might enter IP ranges to ban manually. In the interface, you can then choose how drastically you want to use the blacklist: ban everything or just ranges automatically created for you. The default settings should keep you reasonably safe.
- A white list allows to override the blacklist. The white list is totally controlled by you, and is quite useful to remove false alarms raised when using the most drastic options from the blacklist system
- Optionally, you may request some friends to be white-listed before connection. This is a very secure option, but it is painful to use for friends who do not have a static IP. So this option can be switched for each friend independently.
- Once connected using a secure authenticated channel, friends exchange their effective address of connection. If a friend reports to you a contact address that is different than what your Retroshare node thinks its own external address is, a warning is raised in the news feed. This very efficiently detects traffic forwarding. However, false positive warnings will be raised when your IP is changing and a friend connects before Retroshare has figured it outs. Just keep an eye on them.
When many IPs in the same range are reported as suspicious by the DHT, Retroshare automatically creates banning rules for them in the black list. When you’re sure of them, the safe move is to make them permanent (by selecting them, adding a comment and submit them to the black list). To avoid traffic forwarding with 100% efficiency, either require all peers to be in the white list, or use a TOR hidden node.
Under the Hood – New Back-end
The GXS cache system
Forums, channels, posted and identities are all handled by a common back-end system called GXS (General eXchange System), which replaces the old—inefficient—cache system based on file transfer. GXS improves over the old cache system in many ways:
- cache metadata is stored encrypted, using the sqlcipher library.
- the cache uses a differential update system which only transfers what’s needed. As a result the network load due to cache exchanges is limited to the bare minimum.
- cache storage is much more efficient than in v0.5 and shouldn’t be a problem any longer.
The basic brick of the GXS system is Groups, which is used to represent all actors: forums, identities, channels, etc. It’s quite a complex system which will require a blog post in itself.
The global router
The global router is a passive decentralised data routing system, which securely brings data from one Retroshare Identity to another. It is asynchronous and redundant, which means that you do not need the source and destination of a data packet to be simultaneously online.
The routing mechanism mixes two redundant system: tunnels provided by the anonymous tunnel system (also shared with distant chat and file transfer) and friend-to-friend routing, based on the so called “routing matrix” that encodes for each peer the best friends to which a packet to a given Identity should be sent. The construction of the routing matrix is achieved as forum/channel post signers get known: a friend sending a signature from a given identity will be more likely to be used as a route toward that particular identity.
The global router is currently used to send distant messages between Retroshare Identities. It can also be used by new services installed by plugins, since only the source and destination of a packet need to be able to handle its real content. The global router ensures authentication and encryption of the data that is sent.
Our workplan is the following:
- implement identity circles. This is actually almost done. Retroshare still needs a way to encrypt the data that is restricted to a circle of identities in a reliable way. The rest of the software already has what’s needed to manage access rights based on groups. This is currently all hidden in the GUI to avoid confusion with unfinished stuff.
- implement new differential file list system and get rid of the old cache system. The current file list system is the last bit of Retroshare that uses the old cache system. We would like to get rid of it, and take that opportunity to re-design the file list exchange in a way that is more responsive and more efficient. Basically we’re aiming at a differential update using a priority list that would ensure that when you’re browsing friends’ files, they get updated first.
- IPv6 support. This is almost done and preliminary experiments are very encouraging. We still need to make the whitelist/blacklist system compatible with IPv6.
- add a serious video codec to VOIP. Our video codec now is based on encoding each frame in JPEG, which is quite a shame. We need to plug in a x264 codec. If anyone wants to help us with this, we would be eternally grateful. This is not a difficult task since it will not require to understand the Retroshare back end. It needs some knowledge on how to use the codecs and good programming skills. If you feel like doing it, contact us!
- use our own DHT, where we can add a bit more authentication between peers, so that it is not possible to perform large scale traffic forwarding attacks.
As you can see, we have been quite busy. I would like to thank the many contributors to this great project for this step. Beyond the official developers who devote a significant part of their life making the things happen (coding, packaging, debugging, etc) we are constantly encouraged and given very useful feedback by many devoted testers (Special mention to Jolavillette, ASmith), some of which submitted very good patches (Special thanks to Cave, Chozabu, G10H4ck, Henry, Phenom, Sehraf, … please forgive me if I forgot any of you!). Many thanks also to Beluga for the new web site!
We provide builds for windows and all supported Ubuntu. Still missing are builds for Debian (Will be very soon hopefully) and some special distribution-architecture combinations such as debian+arm. Unfortunately we don’t have MacOS builds at this time either, but we’re working on it.
Since this release contains many new features, and we obviously cannot test all configurations, we partly rely on you to send us as much feedback as needed to improve this release candidate 1. We’ll publish an improved version soon based on what feedback we get.
We hope that Retroshare-0.6 will be a step forward to our ultimate goal: providing a social network that can avoid surveillance. It is designed to be powerful and safe, but we cannot ensure you that it is perfectly secure either. So use it wisely!
Plenty of great stuff (even if a couple of them were already available in 0.5, like the multipath file transfers). It’s good to finally see 0.6 released.
– I think a guide on how we can restore our 0.5 network of friends in 0.6 securely, if we have no other way than Retroshare to communicate with them, would be useful to many people.
– what about finally dropping sourceforge (a slow and confusing web site that does not use HTTPS and hacks into FOSS projects to install their adware), and switching for example to github, and really using the bugtracker? You say you want feedback and a bugtracker that developers actually read and maintain seems like the best way to get it.
To restore friends, you just need to re-accept all their PGP keys (which you will e.g. find in the PGP keyring in Network) and re-add one or two locations. The discovery system will exchange other locations for you. It all depends on how much your network is connected.
We’re currently considering the possibility to leave SF very seriously.
Any reason why creation of hidden service was not automated? Ricochet does this transparently
Really like 0.6. Thanks for the hard work.
My real life friends and I have been using it since it was released and it’s great. We’re having difficulty adding other friends, though, via joining chat servers. I can’t figure out how to export my key with signatures and location.
So two questions – how do I export my key with signatures and location, and are there any public 0.6 chat servers out there where we can find friends?
You can export your RS certificate in two ways: either from Options->node->certificate, or by launching the “Add friend” wizard and copying your key from the top panel above the place where you paste your friend’s key. Please note that the PGP key itself is not enough to connect. You need a full cert.
I’m not aware of v0.6 chat servers yet. You might find some using google? The chat servers are generally not provided by the dev team, so I don’t even know whether there’s ongoing work to get them up or not.
To get started on Retroshare 0.6 you’ll want to optionally exchange your RS public key with this RS06 chatserver
You and your friends are also welcome to visit the Retroshare IRC Chat Help Room: At irc.freenode.net/6697 SSL Channel #retroshare
Once you gain access thru established friends caching to the regular Retroshare 0.6.0 chat lobbys then new users can subscribe to and join the Retroshare 0.6 Key Exchange and/or the Key Exchange chat lobbys to find new RS06 friends and post/share your public key links internally in those chat lobbys.
Often RS06 users also do the same in language specific chat lobbys (English,German,French,Russian,Chinese et al) to gain a subcore of global multi-national friends or of a specific spoken/native language group.
New Retroshare 0.6 users also are encouraged to post their public key links and request for new friends in the Retroshare Key Exchange and 06er key exchange Forums.
A new Retroshare 0.6 Forum has also been recently added to make full use of the still being developed Circles Tool which focuses on helping new RS06 users gain a core group of friends based on alike categorys or desires. Retroshare Circles forum
For Brand New Retroshare 0.6.0 users, you might want to optionally add one or more of these public RS06 Chat Servers to help you build up your contacts and friends lists thru their extensive Retroshare 0.6.0 Chat Lobby caches which transfer and updates yours shortly after adding your public key to each/any of the following 4 Retroshare 0.6.0 chat servers.
Retroshare 0.6.0 Public Chat Servers
Pirate Party https://retrochat.piratenpartei.at/
I have been waiting for the new release for a long time. I actually made a post on the feature request years ago and was now trying to setup the LAN type config again, but now I can’t event follow the suggestions that were given back then.
How can we try and configure this on basically a distributes Wifi LAN that doesn’t have internet access?
Thanks for the great work btw.
On LAN, the DHT will not help, but Discovery is going to do a good job exchanging IPs between common friends. It’s likely that in some cases you’ll have to manually bootstrap the network by exchanging IP between a few couple of friends (just show “Details” on each friend node, and you’ll find a place to enter a LAN IP there if needed).
We had plans to implement zeroconf for RS but it’s not done yet.
RS becomes the ultimate LAN party tool if it has excellent local peer discovery.
Also I bet it would be great at coffee shops and amazing on large LANs like college campuses.
The next trick would be a streamlined friend key exchange if you’re on the same local network – The friends come over, have a LAN party, and when we all leave, we’re all still on RS together.
Thanks for the tip. We are tried that today, but we have some obstacles:
1. each node on our wireless network has their own subnet. The discovery doesn’t seem to actually try and look outside it’s own local subnet?
2. Some users use NAT. E.g. 192.168.x.x range internally and the NAT ip of the “external” range is 172.18.x.x. When creating your Identity/local node, you can’t specify which IP to use and when running later only the internal IPs are detected and I assume used for the discovery.
3. We have tried to enter the 172.18.x.x. Ips on friend nodes, but we don’t even see traffic going to them when we run RS. We do see traffic arrive on the other side if you try and telnet to the port (using the 172.18.x.x) IP.
We have added the 172.18.x.x/16 range to the whitelist. We tried adding the 172.18.x.x IPs as our internal and external IPs. We added the BDBoot.txt files.
Most software that we use, you can override the reported IP to allow it to communicate with the 172.18.x.x range.
Two features I wish for:
– Elliptic Curves (and/or option to choose keys used)
– Perfect Forward Secrecy
ECC is not currently planned, but I agree it would make smaller certificates 😉
PFS is implemented and works. See the connection details on each friend, and you’ll see “DHE”, which stands for Efemeral Diffie-Hellman.
Saw it. Amazing! 🙂
Retroshare 0.6.0 raises the private,encrypted,secure P2P,Friend-Friend decentralized global network bar considerably with its Hidden Node, Darknet Modes and Tor Hidden Service options built directly into its multi-computer platform. Retroshare 0.6.0’s across the board GPG key encryption is built directly into the coding. Retroshare 0.6.0’x wide use of C++,QT also makes this application far more appealing than the resource hungry JAVA based decentralized networks that popup now and then like mushrooms but lack many of the features Retroshare 0.6.0 users now take for granted.
There is a little bug in version 0.6 which was also in version 0.5.
If you right-click on a new friend and choose details. Then you select Trust level and sets it to a value, that could be full. If I then choose “Sign this PGP key” then RS freezes and shuts down.
If you choose Trust level and sets it to a value that could be full, and then choose the OK button. And then opened up again and select “Sign this PGP key” then everything is working as it should.
It is a error that apparently has survived to the new version.
Am I right?
A lot of changes since I last checked RetroShare. I see you implemented some tor functionality. Now you need to implement I2P functionality and RetroShare would be excellent. I2P is a great network and could really use RetroShare. I see no reason it could not be made to work, just have to make it happen. Tor is great and all, but so is I2P. However, I must say thank you all for such a great piece of software. Welp, back to testing. 🙂
I have made a very detailed documented post on the developer form regarding the issues with the Windows compiling of Retroshare. I have been able to get it compiled finally after hours or struggling. But it doesn’t work because of DLL issues.
I have not been able to find anyone in the IRC channel So I thought i would try here again.
Hope someone can assist. would really like to get this up and running.
Great work. I’ve been a fan for a long time, and I’m glad the renewed interest in private communication tools has stirred development up here.
One thing I wish for: bring back the integration with the system’s PGP keyring.
Is Retroshare vulnerable to CVE-2015-1793?
Not on ubuntu (http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-1793.html)
On windows, the RC2 is using 1.0.2b, which means potentially yes (we have no proof that this vulnerability actually affects RS’s handshake, but that is possible). So it’s wise to change the two openssl dll’s yourself asap. We’ll update them in the website as well.
thx for mentioning this.
Pingback: Version 0.6 is out! | RetroShare Team - thierrylaurion.methierrylaurion.me
Pingback: Release notes for final 0.6.0 | RetroShare Team
This info is worth everyone’s attention. Where can I find out more?
Thanks for finally writing about >Version 0.6 is out!
(RC2) | RetroShare Team <Liked it!
Helpful info. Fortunate me I discovered your
web site by accident, and I’m surprised why this accident didn’t happened earlier!
I bookmarked it.
An impressive share! I’ve just forwarded this onto a colleague who
was doing a little research on this. And he in fact bought
me breakfast because I found it for him… lol.
So let me reword this…. Thank YOU for the meal!!
But yeah, thanx for spending some time to talk about this subject here on your blog.
Woh I like your blog posts, saved to bookmarks!
Hi there to every body, it’s my first visit of this blog; this blog carries amazing and in fact good information in support of visitors.
Hi I cannot get VOIP audio working on Mac Yosemite. VOIP Video is perfect. Any ideas.