From RetroShare
Jump to: navigation, search
This page contains changes which are not marked for translation.

Other languages:English 100% • ‎Italian 75%
This page is old, please see the article in the RetroShare Team Blog RetroShare’s anonymous routing model. (Nov. 24, 2012)

This page is in construction (Aug. 14, 2010).


Turtle Routing theory

Implementation in RetroShare

Turtle packets

  • generic items
  • search items
  • tunnel items

Tunnel management

  • tunnel life time, tunnel re-initializing,
  • tunnel identity: uniqueness issues.
  • tunnel architecture: maximum length, optimal path, path sharing
  • bandwidth management

Connexion to file transfer

  • turtle peers, multiplexer, datasend/datarecv

Anonymity issues

Basically: no. There's absolutely no way to know where turtle packets come from and where they go, for the simple reason that they are not associated to any long-distance address or peer name/hash.

Here's some details about how it works:

- When you ask for download, the turtle router manages tunnels for this hash.
- to open a tunnel, I send a hash to all my friends with a half-tunnel-id that is unique to the couple (source id,hash).
This id is produced by a non invertible hashing function, hence hiding the source.
This request is then forwarded to friends of friends,etc. A cache local to each peer remembers what hash was asked by what immediate friend.
When somebody can provide the hash, it responds and creates a tunnel id unique for the triplet (source,destination,hash).
Tunnel responses are forwarded back to their local source, with no idea of what could be the next hop.
This is because each turtle peer only knows the immediate source and destination of turtle packets (requests, results or tunnels).
- once a tunnel is opened, it always routes packets into the same direction, and is only used for the same triplet (source, destination, hash).
File request thus don't need to contain file infos such as size, name or hash which are only related to real file data at the source and destination of tunnels.
- tunnel ids are unique, and there's no way to recover where tunnels go (for the source) and where they come from (for the destination) from the id, because ids are forged from the (source id,hash), xored with the (dest,hash) half ids always generated locally.
- doing so, tunnel response that have the same id than existing tunnels can be discarded because they correspond to redundant tunnels (that have same hash, source and dest).
This is what I'm using to avoid digging multiple times the same tunnel.

So who knows what?
- at tunnel creation time, each peer could possibly record what file hash is used for what tunnel id, along the tunnel.
This could be avoided by replacing the file hash (in open tunnel packets) by a hashed version of it (we would have to modify the search function too); but honestly it's no big deal, because you absolutely can't tell who is asking or receiving the data beyond your immediate friends through which it's only transiting. Besides, if you know a file hash, there's no way to know what file it actually corresponds to, except if you already have it or if you manage to search for it.

One possible attack we can see now would be to perform global traffic correlation statistics among peers to be able to know which packets come from where across turtle hops. If we come to this, there is an easy solution: use a cache for turtle packets and delay them with some non uniform random bias.

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.
Personal tools

External websites