A short introduction to PGP
Since RetroShare makes heavy use of PGP, we want to make a (very) short introduction to asymmetric encryption here. If you know about PGP already, you can skip this chapter.
PGP uses asymmetric encryption.
This means, that every participant creates a public and a corresponding private key.
The public key is spread to all friends and allows them to encrypt messages for you.
If a message is encrypted with a public key, only persons with the private key can decrypt this message.
But the only person who has the private key belonging to your public key is you, and so only you can read the message.
This is the idea behind asymmetric encryption.
You can use asymmetric encryption to ensure the authenticity of messages, which is called signing.
In fact, you can compare it to a handmade signature in real life, as only you with your private key are able to create it.
Everyone, who owns the public key, can check the signature then.
Web of Trust
A basic problem is the initial exchange of keys between two friends: if Alice and Bob want to use asymmetric encryption, they will have to send the public key to each other's public key first.
A malicious third party can intercept this exchange - this is called the Man-In-The-Middle-Attack.
To prevent such attacks, PGP allows users to sign other keys.
If you transferred the key manually or you checked it via a safe channel like telephone, you should sign your friends key.
The more signatures a key has, the more you can be sure that it is the actual key and not a key created by an attacker.
This whole process of signing other keys is called the Web of Trust.
RetroShare does not differ between signed keys and unsigned keys, all friends are treated equal.
RetroShare uses PGP certificates to authenticate your friends.
It supports two forms of certificates, the old one (default PGP certificates) and a new format.
A RetroShare certificate in the old format looks like this:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: OpenPGP:SDK v0.9 xsBNBFC7TisBCACv2ArHtkC98bX2le34yME7wwxxia3+giC8UUil2JIoCKnrD53U j7AeqROyDnct490CNmPRJaBaz99dSPT5o7ZVWQixS+cg8a2MUK8C4P/to0KF3U0A 68mt1aJYxOuiDvD3Srz/cccaUqXslZI+Dg/9fXr9e85mKfeejqbWjayMWxXtnJr2 /SisaNOwlzdH0vIrHD7bSKnO4AhZ/DgIA0AzWDshMdwL1gJGXls3rm33Q9ZhwAg3 nI5UM9f5X29x8pC+2ITjiOKX9OO4z5xSEW0SQO6Pf4/fgzznhPxUyqaCXqHycEn+ JsCSGj78J7uzJ6NiETFrPvoU/jckIvoT1yXBABEBAAHNLnNvbWUgbmljayAoR2Vu ZXJhdGVkIGJ5IFJldHJvU2hhcmUpIDxubyBlbWFpbD7CwF8EEwECABMFAlC7TisJ ENfaJ5Bculk3AhkBAACoXQgAjIFM2KsRct2Mh2/yrbRxvwOrPUOKvGJYWUTALXO+ fLE+5z6AIJacqwQSKRd/BT9/yPa6pWGuw/XB58Ue9fC2U5QoazBG/xtqc4P9/z2K jXLJupFLOHUvq1QhpU8tLB9a7hze41/9FpnwgmMySibMhz1wgCdVUG2bgMtJYSTz nEbZrnIpgu454EIFEZTI4leYZhp3/KxzydVQ+JSsWPK5ruoYBYBj92w/D9/mDF3Q lJE90n0bmCWrMaiT6zLA/o1irUXhilVmYig0SpwYv/cQAbIcoX520+qpTejVQrj7 iYUVewaiJr9R18x7C+3OJOP2JimGk9xjL/JwXamSxAsRVQ== =uOXr -----END PGP PUBLIC KEY BLOCK----- --SSLID--89c13eae231c5dc6b245765b20f4e29e;--LOCATION--some place; --LOCAL--192.168.1.1:7812;--EXT--10.142.125.245:7812; --DYNDNS--mysubdomain.example.com;
The new format looks like this:
Af8AZXVbxsBNBFBq+SABCADfBXgKPDeC4Q6gnOaywnx9XTRcdQQYGvbWAOcygGDx P7UC9FJ2v8LxtXd6QOjxsexXjGCrey78pPxDgm+iRCG0FGBeLpGBTouamvwQ7uUz hLY8IGyjy4oDxwXgvVF/0x0WBi1i/haYJi8qXk9/Ll9cDXTSBKfqH2ACFzWum4mt 7klubMhsL80QZVeAeaeI2r6zbgYqaw7Xc1kNhYQDbfUU2m1urzaJ9gOT+MzVi97h ukjUrE9SuIfrEoqIyL67sflfQyBwYEJm+X2N7pW4CwcnJWsHPI+Fe4POLgrH17bM dZkIFdN5EJl/1MT3FYLj/zx5c4Fgocmhi3s1xUWz5mbJABEBAAHNJ3Rlc3QxIChH ZW5lcmF0ZWQgYnkgUmV0cm9TaGFyZSkgPHRlc3QxPsLAXwQTAQIAEwUCUGr5IAkQ 4XzDoqr5prgCGQEAAJ7HCADeRHF2AIUpT0w9/W6+r3e8HiCHaXNsFMcUgrarWl7h MS0HfmLgVtaku2q17zcj+yS6QbDBGP2j/3+/OpJyQ19ZTBnvhEE3pbUm8Aoe4ZjI jZofcyGA8fR9ICsCVXGqZE7IiNLuklNcwzIbpWt4+tmgQDO5x9D27ch2QEYisbT9 WZHAxfgW4QPzdKTJiqLxW3xIJqI/tP/y6XByOX/NR57HTXSYcCwE2JTDfuaO2Ki8 RROqu8XXQj/0xPf8QI8osxl2rH3LRx/c2CooPIQIcX64vqaVaol4P7FnTC7czUq+ xdlS/d9gBPkqsbl0j16P56wBmu02NfEBQlxEgwAXiJHKAgZP0FxzBP4DBsCoAncE /gQABgh0ZXN0MWxvYwUQCCw1pLwJuX1PTasINX94pQ==
Both certificate formats contain the same information, for example, the second format also contains the IP address.
In a future version of RetroShare the new format will become the default. It is easier to parse and more robust than the old format.
Content of the certificate:
- The first part of the certificate is simply a PGP public key.
- The second part contains specific extra information needed by RetroShare.
- The certificate must contain the SSLID and the LOCATION, to make your friends able to find and connect to your installation.
- The internal/external IP and the (DYN)DNS-adress are optional because RetroShare can exchange this information with your friend on your first connection.
- The external IP is only helpful, if it is still valid. In most cases (home setup), the external IP change every 24h (according the ISPs), but this doesn't matter, as RetroShare can figure this out by itself by using the DHT or the Discovery system.
If you export your key to a *.rsc file, you can email it, put it on an USB-stick etc. without getting bothered by encoding issues.
RetroShare has some config data, where e.g. the friend list, the forum posts etc. are saved on your harddisk.
RetroShare encrypts all his config data saved onto your computer with your public key.
If RetroShare is not running, someone with physical access (like family members, room mates, the police on a house search, etc.) can get a copy of your encrypted private key and try to decrypt your config data.
But as your private key is encrypted with your password, the attacker is still stuck without it.
So don't use a bad password as 12345, if you are worried about this scenario.
RetroShare makes it very hard for an outside attacker to decrypt, what data (chat, files, forums) you and your friend are transferring.
The only possible attacks (listed from likely ones to unlikely ones) are:
- Your computer is infected. If your computer is infected with a trojan horse, the attacker could intercept all data (e.g keystrokes) before it is encrypted and leaves your PC. This is a possible attack on every encryption program, not only on RetroShare. Counter-measures are the usual ones, as don't visit dubious sites, install updates etc.
- RetroShare has a bug in the encryption parts. As RetroShare does use the OpenSSL library (industry standard and often reviewed code) for encryption, this is possible, but not very likely, too.
- You are using a wrong certificate and are subject to a Man-In-The-Middle-Attack. As explained above, you have to verify, that the initial public certificate exchange between you and your friend wasn't intercepted. If you don't do this, there might be an active attacker, which can decrypt everything then. The attacker would have to be able to intercept and modify your complete internet traffic. But if you exchanged the PGP key via USB stick or e.g. per telephone, you can be very safe against this form of attack, and you need to do it only once.
- The cryptographic primitives are broken. This is very, very unlikely, as even the NSA uses e.g AES for top secret documents. RSA 2048 bits is far from being broken, too. Nothing to worry about here, even Edward Snowden - the NSA whistleblower about PRISM - said, that encryption works.
In conclusion, doing the initial key exchange with caution, and having a not-infected computer, RetroShare is a very safe form of communication.
|This page is part of RetroShare Documentation|
|Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.|