Dear users, Retroshare has recently gained some popularity (as can be guessed from the DHT statistics). We have spent a significant part of our time on improving the user experience both in terms of security and design, for this 0.5.5 release.
We’re now turning toward heavy non backward compatible developments that will soon lead to version 0.6, which will bring some important new features.
The goal of this post is therefore to give some info about our roadmap.
So what’s new in this release 0.5.5 ?
We can’t describe all specific changed we’ve made. In particular, the GUI has been improved in various ways, and we let you discover it. We still want to mention the following bits:
The help panels can be popped up from various places, and are all consistently presented using buttons. They show basic help about the software components which we found necessary for new users.
Distant chat & Distant messages
It is now possible to chat and send messages to non friends, using the tunnel system that has been extended to support arbitrary services. Distant messages can be sent to non friends by using their PGP key ID as a destination address. In order to receive such messages, make sure to enable it in the config/messages page:
Distant chat works with invitations. In the config/chat page, you can create personal invites for a given peer from his/her PGP key. You can afterwards paste the invite into a forum post, or in the chat lobbies. Only that peer can decipher the invite and use it to chat with you using a secured tunnel.
See our blog post related to that subject for more information.
The connection status window pops up if you click on “attempt to connect” for a friend, or each time you make a new friend (e.g. by exchanging keys). It reports common issues that can prevent you from connecting, and helps understanding the whole operation:
Entropy collection system
When creating a new identity, it is now required that the user collects some entropy by randomly moving the mouse in the screen for some seconds. A progress indicator gives an idea of how much movement is required. Some systems (e.g. linux) already do an excellent job at collecting system-based entropy but we felt necessary to add this feature for other operating systems:
Taking inspiration from what truecrypt does, we used a Qt timer to grab mouse coordinates every 20ms while detecting changes, and convert them into pseudo-random bits that we feed into the RAND_seed() method of the OpenSSL library.
In the core
We fixed a bug in the cleanupDirectory() function that is called at start to remove dead cache items. This bug was the cause of the prohibitive starting up time that Retroshare users would experience after several weeks of use. So it’s worth mentioning!
Up to now, only a single anonymous tunnel was allowed by design between a given source and destination for a given file hash. Using a little change in the code (2 lines, actually!), we allowed an arbitrary number of tunnels for a given (source,hash,destination) triplet. The file transfer system automatically balances the load of the different tunnels according to available bandwidth. This removes the typical behaviour of tunnels that would previously appear to oscillate between slow and high speeds because they where simply changing routes. Now the old routes are kept as long as they can provide data.
Perfect Forward Secrecy (0.5.5b)
Lots has been said recently about the security of SSL. In particular, if an attacker records the traffic and stores it for later use, he can take some time cracking the SSL key (or much more easily obtaining it by hacking into your computer), and use it to unroll the handshake to obtain the AES key that is used to encrypt a particular session. The use of PFS (for Perfect Forward Secrecy) removes this threat (See for instance this).
To enable PFS, we use the following cipher list, in combination with Ephemeral Diffie-Hellman handshake based on a hard-coded 4096-bit safe prime:
In summary, you can check for a particular peer that you’re using EDH, by looking into the Peer Details window:
ECDHE is not used because we haven’t configured it. This has nothing to do with the recent doubts on Dual_EC_DRBG random generator also based on elliptic curves, that is not used by default in OpenSSL, and will be removed in the near future anyway.
Although DHE is more costly than ECDHE, this extra cost will not impact Retroshare users, since the cost difference shows up at the time of the SSL handshake, which for a web server—contrarily to Retroshare—has a major impact.
Security against bombing (0.5.5b)
We figured out that we needed to protect our users from malicious code including enormous images, and billion laugh bombs. A very kind anonymous user of the Retroshare network has warned us against this threat by trying all sorts of nasty combinations. We would like to thank him/her for that ;-). We also included an option to load images in forum posts on user request.
Upcoming developments (version 0.6)
We’re currently heading toward v0.6, taking that opportunity to make some long pending non backward compatible changes, but also adding cool new features.
Current development heads toward an abstract network access interface, which will allow us to support IPv6, IPv4, and potentially onion addresses over the TOR network.
The new cache system called GXS, will bring a major improvement over the existing cache system: it is based on a pull model, rather than a push model, so it transmits only the missing information. It will offer a feedback and reputation system, and circles to group together—possibly non friends—peers into cryptographically controlled sets of people. We’re currently experimenting new services such as photo sharing, a twitter clone, and a system to share links. The development of GXS is nearly finished!
The core library also will get deeply improved: the serialisation has been reworked, and file lists from friends will be compressed. Both cause a significant gain in bandwidth. Last but not least, the RTT between peers has already been drastically reduced thanks to a new queuing system.
V0.6 will be out in late 2013, or early 2014.
We would like to thank all the Retroshare users who sent us bug reports, suggestions, test experience, on an daily basis. We especially received very valuable patches from many users, and lots of testing reports, some of which have been critical for sorting out difficult bugs.
Files for 0.5.5b: https://sourceforge.net/projects/retroshare/files/RetroShare/0.5.5b/
great to see retroshare’s fast progress – thanks for the heads-up, cyril!
when will 0.5.5b start being distrubuted (through the downloads section on the website and through the linux repositories)?
Only the website is not yet updated. The ubuntu repository already has the latest version.
Still missing source tarballs for 0.5.5b;
Also, is there a “load embedded images” option for chat lobbies?
Instead of giving up ECDHE and suffering a 3x performance penalty with DHE, why not use Dan Bernstein’s Curve25519 instead of the stock NIST curves? Adam Langley from Google is a big fan of it, too:
He also had a post on PFS:
You might also want to look into the SCIMP protocol for chatting, but wait until Silent Circle and Lavabit release the source code for the DarkMail protocol (early 2014), because I think they may have improved it, and aren’t using NIST’s curves anymore, but also another one made by Dan Bernstein. Just something to keep an eye on, if they can be useful for Retroshare.
Click to access SCIMP%20paper.pdf
Thanks for all the links! Your suggestion makes sense.
Anyway, the 3x extra cost is only experienced when a friend connects.
Most of the time, your friends stay connected and DH is not called. Also, we
certainly took this conservative measure in a hurry, and we will improve over it
just want to second john – the gnunet guys are also planning to use curve25519: https://gnunet.org/content/project-status-august-2013
Some consistent naming scheme for the source tarball would be useful. For 0.5.5a there was a corrupted zip, which was eventually fixed. For 0.5.5b there is no tarball with “0.5.5b” in its name.
Also, is there a “load embedded images” option for chat lobbies? Since the anti-bombing feature went in, I can’t view images in chat lobbies and there doesn’t appear to be an option to turn this on (as there is for forums and messages).
Please add “One time Use Secret Key” feature for “File sharing and Chatting” as used in “Bittorrent Sync”. I like RatroShare.
This is pretty much what PFS does. The main problem is to authenticate the connexion. And openSSL does it out of the box.
additionally to the cipher discussion some helpful links and information:
TLS 1.2 Speccs
How often is the TLS Handshake done in RetroShare? Once a connection is established? Every X Minutes renewed? Or every X MByte transferred Data to a peer? Only each reconnect with a peer?
Is it possible a connection lasts more than 24 hours without a new TLS Handshake?
Is it Possible to Force a TLS Handshake every X Minutes/ every X Megabyte?
Well, all that would be possible. Still, given the parameters used in the DHE key exchange, you can probably stay connected forever without any risk. We figured out though that the 4096 bits safe prime that is used causes a hit of CPU at each connexion handshake. So the fewer handshakes, the better.
Awesome work and awesome plans!
But will GXS help with very large shares? I have a friend who has over 10.000 files in one directory, and so far no RetroShare version was capable of browsing through that.
The browsing thing is a pure Qt issue. We need to implement some kind of on-the-fly widget to browse large lists. Wt does that already.
As far as file lists are concerned, they will ship zipped in v0.6. This is already implemented.
Guys you do amazing job, the RS already has interesting features. Anyway it is still hard to novice use it, as when you download client you don’t have any of friend and have to create connection with CHATSERVER and find “friends” to infiltrate to network :). I suggest to make some starting point for such a people. It can be default forum with links to content, or special botchat to connect novice people in order to they will not be alone in new system. Of course it will switched off by default to not reveal people who want to chat only with themselves friends.
I compare RS with other systems:
i2p you install router and after some time can visit sites and download content, visit forums etc
TOR the same way, you have content already without needing to establish connections
as for RS even if we know that it is F2F network it need some public content to newcomers, like public forum with certificate already added to each RS client. thanks for attention and efforts to make this system better. good luck.
I’m not sure if you’ve already seen this or not, but here are some of the improvements done to the TextSecure protocol for asynchronous messaging. I’m not sure how useful it will be for Retroshare though, since TextSecure implies using servers for matching contacts (and I think keeping the message, too), but perhaps you can replace the “central” server in that configuration with some DHT configuration?
Anyway something to look into:
There’s also Moxie’s idea for funding privacy-focused open source software with Bitcoins, that you should check out:
This just in. Take a look at what Bittorent is doing with encrypted DHT:
Was Retroshare already doing this?
According to this http://www2.clustrmaps.com/ru/counter/maps.php?url=http://retroshare.sf.net, Russia about in the top ten who visiting your site but you don’t have translation, I would like to start doing it to spread the word, as I consider your system like gybrid to bittorrent and DC++ and skype to some extent. Contact me by email please.
BTW didn’t find any finance support for you, how I can send you money :)?
Best way to get in contact with the core-dev-team is to add one of the chatservers and find them in the community.
There are several Chatrooms always up with lots of idle and active users. If you add some friends, you will be able to join to other rooms where the dev team is available. You can send them mails inside RetroShare with distant-mail functionality or talk to them directly via IM or in the devel chatlobby when they are around.
If you still want to mail: http://retroshare.sourceforge.net/team.html
There is also a Chat lobby “Chatserver RU” active. I dunno what they talk, because it is Kyrilian 😛
The retroshareteam does not accept any money or donation at the moment to be totally independent and free.
Other ways of contributung by writing HowTo’s, Tutorials, writing Plugins and submitting Code-Patches, Bug-Reports is highly appreciated.
If you want to help with Translation please have a look at the Translation Project on Transifex.
Russian translation seems to be stuck at ~~50% and needs your attention urgently.
If you have more questions, please show up at one of the chatservers and talk to the folks there.
Chatserver HowTo: https://retrochat.piratenpartei.at/w2c/howto.html
Hi : I would like to know what did happen to the forum…; The forum was great. Thank You. PS : I tried with little sucess to bring people to retroshare. The first problem was the endless key that people had to type. Problem 2 : Often we were unable to connect.
The for the feedback. Sourceforge admins are currently looking into forum/wiki to see what’s going on.
In v0.6, we will have a simplified certificate format. More robust, easier to copy/paste without errors.
Connectivity is always a limitation for F2F systems. v0.6 will accept to work with TOR proxy, which also increases connectivity.
Thanks for your reply. Actually I love the retroshare idea. I had it installed for years in my computer despite the fact I had not a single contact. Finaly one day I found out retroshare chatroom and there I found people that I did add. After that I tried to lure more than 12 people to retroshare. I was not sucesseful. The first main stumbling block was the never ending key. Both users had to add the key..,and sometimes we would have to try once..,twice..,a third time. Such process should be much easier or at least retroshare should have 2 modes , a simpler mode with a 20 character key.., and a more secure one with a more secure key.
The second stumbling block , and usually the ” coup de grace ” , (final blow ) was the fact that people could not connect.
After the efford of installing the software, placing the long key.., not being able to connect was the last straw that broke camel back.
Retroshare should have volunteers or whatever that work as bridges in order to facilitate connection between newbies.
In order to be embraced by people software must be very very intuitive.
And it should work.
I know I am sounding a bit negative..,but I really loved Retroshare but i was unable to convince one single user to keep it in its computer.
Recently I have tried bit torrent sync.., and that software does work.
In order to share files one of the users has to insert just one key of around 20 characters.., connection was immediately made.., it works.
As I wrote I love retroshare idea…, but in order to become more widely accepted.., the software must be made simpler.
The forum was awesome. It had lots of useful information .
Its very necessary.
Thanks for reading.
BTW, where is the public package signing key for retroshare ?
Can’t find it on the retroshare website.
Can’t find it on sf.net.
This should be presented in a prominent place.
Otherwise users will check against unverified checksums.
Thank you for the good work.
Our checksums are signed with this key: 794B 423E EAC9 D97D B321 2F2D EFD1 9E9D C737 CA98
Anxiously awaiting a new blog post from you guys: How is deleopment of 0.6 version going? Any roadmap for releasing it? New features/plugins planned? Please, give us a heads-up 🙂
> V0.6 will be out in late 2013, or early 2014.
aaaand it’s late 2014
Seems that developement has been stopped. No news from the devs and the last released version is older than 7 months. The start of RS seemed promising… 😦
Development has never been so active. That’s why we don’t tweet/blog much. Just have a look at the commits on sourceforge… We are finalizing stuff for v0.6 now.
_V0.6 will be out in late 2013, or early 2014._
How do you want that we do not assume that RS is dying ?
There’s no new blog post for 18 months. You should really communicate _and_ officialize RS0.6 because RS community is very small, it’s a real danger to split this community between two incompatible versions.
(I use RS0.6 daily, seems to work very fine)
Have a look at:
I also miss Updates at the DevBlog and switch to GIT/GitHub/GitLab and other whishes which seem to be not prio. Hopefully Cyril takes some time to change this and give some updates on the blog.
Retroshare Development is very active.
IPv6 support is started by $nickname,
Tor Support to run RS as hidden service and also MacOSX support is increasing.
RS-Socialnet is in heavy development https://gitorious.org/rssocialnet and is merged to branch http://sourceforge.net/p/retroshare/code/HEAD/tree/branches/v0.6-rssocialnet/
RetroShare needs a Web Developer for RS-Socialnet: http://blog.freifunk.net/tillmann-gansky
dear RS-Team, dear cyril,
lot of topics which are not fitting to a single post, but a little official update on some of them would be neat!
# open todos and milestones which are addressed for v0.6 release
# tor hidden service
# MacOSX install package
# openSSL cipherlist (TLS1.2 and hardened ciphers only)
# openSSL version for OSX (static or dynamic)
# GXS status
# new Discovery and how it is working now
# ipv6 functionality
# RS-Social Plugin status
# SVN -> GIT; SF -> GitHub/GitLab/Gitorious migration
# message and distant messages
# MIME for Messages
# distant chat
# GXS – id’s
# unfinished GXS features like wiki
# general status of v0.6 and outlook
# other unknown stuff
so i hope you can push an update post with some topics
i (think i) am aware of the project status and what is going on, but lot of others do not have the chance to follow the devel-room and internal forums so closely.
thanks in advance