Cryptography and Security in Retroshare

Retroshare’s security relies heavily on cryptographic algorithms. We detail in this post what methods are used in which place and their parameters. In the end of the post, we present the limits of the security model, examining what an attacker can do with various levels of penetration of your system.

Cryptography in Retroshare

Connections between friends are encrypted using SSL, which is a protocol for secure communication, and a set of cryptographic functions. We use it with standard parameters, meaning 2048 bits RSA  keys in the following operations:

  • Encrypting communication between friends;
  • Encrypting configuration files (used by Retroshare modules for storing state and data);
  • Identifying friends locations. To each location corresponds a unique SSL certificate, that is stored encrypted on the hard-disk;
  • random number generation (For tunnel IDs, chat lobby IDs, etc).

Your identity is represented by your PGP key. PGP is a standard for encryption and authentication that provides a web of trust between friends. Your PGP key links together the various SSL certificates of your locations. We use PGP for:

  • Encrypting the SSL passphrase on disk (See login mechanism below);
  • Signing your location’s SSL certificate (See connecting to a friend);
  • Signing forum posts;
  • Optionally signing the keys of your friends.

Retroshare accepts existing PGP keys for creating identities (e.g. 4096 bits keys instead of 2048 bits), and also offers users to create a new PGP keypair if they haven’t got one. It however requires the following characteristics in the key:

  • it must be RSA for encryption and signing
  • it must have no sub-keys
  • it must be self-signed

PGP-Signed connections

When connecting to a friend, the SSL handshake protocol allows a callback that is used to validate the certificate sent by the connecting peer. In this callback, Retroshare verifies the PGP signature of the SSL certificate, using the PGP public key of the friend. If PGP keys (and therefore Retroshare certificates) are exchanged safely (e.g. hand-to-hand), SSL connections cannot be spied on using a so called man-in-the-middle attack.

PGP Web of trust

Signing your friend’s PGP key is not mandatory for connecting (Don’t mix that up with signing SSL certificates, which *is* mandatory). This is permitted by Retroshare in order to provide a Web-of-Trust mechanism to the network. A new identity being signed by some of your friends should be understood as being approved by your friends, and should garner a higher level of confidence with you. Retroshare is currently not using the full potential of the web of trust mechanism, and we would like to develop it further in the future.

Retroshare’s Certificates

Your Retroshare certificate contain the following information:

  • Your  PGP public key (i.e. your identity), and optionally the friend’s signatures;
  • Your Location ID (i.e. SSL certificate’s hash) and name;
  • Your IP and listening port;
  • Your DNS entry (optional).

Certificates are encoded in radix64 in two different formats: The old format, with text tags like –SSLID–; The new format: a single radix64 with internal sub-blocks. The later has definite advantages in terms of robustness, ease of parsing and cleaning. In the near future (Version 0.6), only the new format will be used to export certificates. The old format will still be parsed.

Identities can be exported/imported (From the Friends->profile->profile manager), in the form of a PGP key pair in ascii format. The private PGP key is in this case kept encrypted, with your usual password. Although it is therein protected, it can be brute-forced, especially if your passphrase is weak, so it’s recommended to keep identity files safe.

Login mechanism

At login, RetroShare reads the encrypted SSL certificate for your location, and the encryption passphrase from the hard disk. The SSL passphrase is chosen randomly when creating your location. It is currently a 64 character string, with an entropy of 418 bits. It is reasonably robust against brute-force attacks.

The SSL passphrase is encrypted using the owner’s PGP key, and stored in the file keys/ssl_passphrase.pgp. When logging in, RetroShare therefore asks the PGP passphrase in order to decrypt this file using the private PGP key. The unencrypted SSL passphrase and encrypted SSL certificate are both used to initialize the SSL session.

When using auto-login, RetroShare stores the un-encrypted SSL passphrase in the system’s password manager. This happens to be the Gnome keyring on Debian-based systems, and the password manager on Microsoft Windows. This feature should be used with care (See below).

Your PGP passphrase is never stored in the system, even with auto-login, and cannot be recovered by examining your hard-disk nor your working session, except using brute force attacks.

Data flow

The diagram below summarizes the flow of encrypted vs/unencrypted data in the software.

Map of encrypted data flow in RetroShare

PGP Implementation

To manage PGP keys, perform signatures (of friend PGP keys or documents like SSL certificates), we use OpenPGP-SDK. This library was originally developed by Ben Laurie and Rachel Willmer. The original implementation of OpenPGP-SDK being quite low-level, we improved it a little and implemented an abstraction layer above it to be able to manage keyrings, export keys, perform detached signatures, etc.

This choice was a significant improvement over the previous library we used: GPGME. That library requires forking to gnupg for every PGP-related operation which proved very costly in the end. On the back side, we lost the support for DSA keys, which needs sub-key support. The later is not yet implemented in OpenPGP-SDK. Since RetroShare has always generated RSA keys, this is not a big issue, except for a small number of users who used a DSA PGP key generated with another software to create a RetroShare identity.

File hashing

All files in RetroShare are hashed using SHA1. Although SHA1 is known for collisions, it is reasonably difficult to modify a file to match a given hash. The computational complexity of a full collision (i.e. crafting a file to match a given hash) is in the order of 2^61 operations. A modern powerful computer can perform 10^12 hashes per second, thus forging a file, losely speaking, would take approximately 26 days.

The ability of forging a file with a target hash can be a security threat, since it is a way to inject trojans in the network, or corrupt transferred files in general. However, because large files are checked on a 1MB chunk basis with respect to multiple sources, it is quite difficult to perform a harmful and consistent modification of a file.

Channels and forums

Channels use their own key system to manage posting rights. That will be explained in a following post. Basically, publishing and access rights are handled using RSA key pairs, stored in the SSL-encrypted config files of the cache system.

Forum posts are optionally signed by the owner’s PGP key. Authenticated forums require this for posting on the forum. For each signature, your PGP passphrase is needed. It is however never stored, even in memory, for more than the time necessary to decrypt the private PGP key.

Forensics and Hacking

Depending on how far an attacker can get into your system, he/she may gain access to different levels of information and represent different levels of potential threat to you and your friends. The table below summarizes it (See the notes):



  • Cells that remain blank do not need an answer;
  • the first four rows are independent. The last two rows suppose gained access to the previous rows;
  • a connection attempt in itself is not a security threat. You still have to manually accept the connection. Still, an attacker can forge an identity which name looks familiar to you, and wait for you to respond to the connecion notification;
  • an attacker knowing your SSL passphrase and a copy of your Retroshare directory is a serious threat: that attacker could (1) modify Retroshare’s code to load the passphrase from the command line, and launch your own Retroshare instance without the need of the GPG passphrase, then connect to your friends. (2) the attacker can decrypt your config files and access the publish keys of your channels.Using auto-login is therefore a problem if an attacker can read your system keyring in clear (e.g. See this on ubuntu) and is able to remember the 64-char passphrase.
  • Retroshare never stores your PGP passphrase on the disk, nor in memory unless for the time necessary to decrypt your PGP key when signing / loging in. Consequently, if you keep your PGP passphrase secured (in your head only!) you should be safe enough.

Security advice

  • Don’t use Auto-Login, unless your working session is eyes-view protected;
  • Use a strong PGP passphrase (at least 96 bits of entropy). Part of your security depends on this. See the wikipedia page on password strength;
  • Encrypt your home directory, so that if you lose your computer, your SSL certificate and PGP keys cannot be brute-forced.

Although all of these measures might correspond to an over-paranoid behaviour, they should keep you safe 😉

About Cyril

I'm sharing the lead of the RetroShare project with G10H4CK. I've been working on RetroShare for four years now.
This entry was posted in Misc and tagged , , . Bookmark the permalink.

28 Responses to Cryptography and Security in Retroshare

  1. john says:

    Can you implement OTR in this, too, or is it not necessary for Retroshare’s P2P model of communications? Are you also planning to add video-calls, too, with ZRTP – maybe in a distant future?

    I like Jitsi as a secure IM project. If you can copy some of the features from Jitsi, that would be great:

    • Cyril says:

      OTR is already provided by Retroshare chat: chat items sent/received from your friends go through the SSL-encrypted connexions to your friends.

      I didn’t know Jitsi ! It looks quite complete. Maybe we can grab the video handling code from there. All the communication being handled by the VOIP plugin service, we just need to grab a video stream, and serialise/deserialize it.

  2. john says:

    I was reading your anonymity post, and I was wondering have you heard or looked into the Phantom Protocol? It has something called “AP” as in Anonymous Protocol, instead of IP, but works exactly like the IP protocol. The difference is sending data through the network can be completely anonymous, and you wouldn’t have a problem such as Tor’s “exit node” weakness…which from what I understand Retroshare also kind of has? Isn’t that how they caught that guy in Germany?

    I don’t understand all the technical stuff myself, but I’m quite interested in researching about such projects, and so far I found the Phantom Protocol to be the most “ideal” secure and anonymized network. Don’t know how practical it is, though, since it doesn’t actually exist in the real world, like others out there, although its design principles have been implemented in code.

    Anyway, I thought that perhaps you might find something useful in the Phantom Protocol that you can use in Retroshare, so throwing the idea out there.

  3. Cyril says:

    Thanks for the reference. That’s an interesting paper I’m going to read.
    There’s one major difference between RS and TOR: With the later, you being an exit node make you transfer packets in the clear from the internet (to anonymous clients). So websites acting as bait can catch you as an exit node. With Retroshare, if you can trust your friends, you can’t be spied because all the traffic passes through them, and no one else.
    About the guy being caught in Germany, looking at the IPs of the guy (someone friend of this guy sent me a screenshot of the guy’s details) shows inconsistencies that make me believe that it was a fake case.

  4. AnonUKIre says:

    Excellent blogpost. Wll review and come back to you.

  5. Distro says:

    Very interesting. When you say that wifi sniffing lets an attacker know about your friends, does it work if the wireless network is encrypted?

    • Cyril says:

      If it’s encrypted, you can still see to which IP the traffic is directed, although you can’t know for sure whether it is Retroshare’s traffic or not. So you can’t figure out e.g. what’s the SSL id of your friends. If it’s un-encrypted, you can sniff the SSL handshake, and it’s possible to find out what’s the SSL id of your friends.

  6. finder says:

    I don’t know whether it’s just me or if everybody else encountering problems with your website.
    It appears as if some of the written text within your content are running off the screen.
    Can somebody else please provide feedback and let me know if this is happening to them
    too? This might be a issue with my web browser because I’ve had this happen previously. Thanks

    • Cyril says:

      Sorry for that.
      Are you talking about the verbatim text we use sometimes for code? That one can’t be scaled by your browser. Are you using a very small screen resolution?

  7. RS says:

    now lest assume a fellow retrosharer ends up highly in the “order of ass kicked”. what’s next ?

  8. ASmith says:

    Retroshare should add the user option of a Proxy and add TLSv1.2 PFS encryption protocals to the SSL ciphers that are compiled and availiable to be used for any Retroshare connected peer to use. I’d appreciate the point and source code module/file where a optional Proxy coding section could be added if you have a moment to point that area out.

  9. Nick P says:

    Great blog post. Keep up the good work. Due to endpoint risks, I suggest porting the software to TAILS or putting anonymity system on hardened device that forces all traffic through RS. Btw, in case readers haven’t seen it, here’s a nice list of papers to give people more ideas for RS anonymity:

  10. Jonathan Wint says:

    SSLID missing from my key how do I get it? on my key?

    • Cyril says:

      you probably figured it out already, just in case: when making friends you need to exchange certificates, not just your PGP key. You cert contains your PGP key, your SSL ID, and some optional info. You get it from the “+” (Add) button in graphical interface (just lick next, and you’ll see your own cert and a place to paste your future friend’s cert).

    • Cyril says:

      The “make friend” wizard has some old text that may let you think it expects a PGP key. It’s not. You need a full Retroshare certificate there. We just fixed the GUI. Thx for reporting this.

  11. Joye Sabi says:

    Iím impressed, I must say. Very rarely do I come across a blog thatís both informative and entertaining, and let me tell you, youíve hit the nail on the head. Your blog is important, the issue is something that not enough people are talking intelligently about

  12. Anon says:

    “All files in RetroShare are hashed using SHA1… A modern powerful computer can perform 10^12 hashes per second, thus forging a file, losely speaking, would take approximately 26 days.”
    This seems to be out-of-date. Firstly, apparently SHA256 and SHA512 are now also options.
    Secondly, according to the Wikipedia article, in 2008 it was possible to collide SHA1 in less than an hour on an average PC.

    • Cyril says:

      There are multiple questions at once in your comment:

      First of all sha1 is used in two different places in RS: (1) to have a unique identifier for files, and (2) to validate PGP signatures during the TLS handshake.

      (1) I suppose that for files, you consider the attack where someone forges a file that has the hash of another file. This is the so called “pre-image attack”, which requires bruteforcing the hash function. Brute-forcing 2^160 bits of hash to match a given specific hash at 10^12 hashes per second should take 10^(160 / (log(10)/log(2))) / 10^12 secs, so approximately 10^36 secs, which counts to 10^28 years. Is it the calculation (and attack) that you’re considering?

      (2) for signatures, we’re talking about forging a certificate that matches the signature of a given key (which SHA1 hash is therefore pre-determined in the copied signature) so that the attacker can connect to someone using his own PGP/SSL pair. That means being able to generate a SSL certificate (e.g. a RSA 2048 public key) which sha1 hash matches a given hash. So you’re here again considering a pre-image attack (furthermore on a non trivial set of data—the set of 2048 bits RSA public keys), which means the 10^28 years still apply.

      Anyhow, RS is also capable of handling handshakes with SHA512 and 256 hashes. It refuses handshakes with other hashes (such as MD5 for which pre-image attacks are easier). For backward compatibility we wait for the next release to make the software switch to these hashes for handshakes.

      I just derived these arguments on a quick analysis. I’d be glad to hear more about it of course if you think I missed something.

  13. N/A says:

    Could you please link to a response to the more general criticisms made here:

    Conscientious transparency about errors is really reassuring in a security context.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s