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.

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):

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 😉