The remainder of the message consists of an encrypted payload. Message cells always start with a circuit_id, which is required to identify to which circuit a particular message belongs. For the introduction point it will always be necessary to be connectible to the outside world. This will only work for the rendezvous point because there is already an existing circuit around. Solving the connectability problem for the introduction and rendezvous points is not essentially the same: the introduction point always needs to be connectible for strangers, but an unconnectable rendezvous point can be punctured by letting the hop that needs to connect to the rendezvous point propagate its identity back to the seeder, via the circuit to the introduction point relayed to the downloader, then propagated to the rendezvous-point which on its turn sends a IPv8 puncture to the last hop. This also solves the connectability problem for the rendezvous point, as the rendezvous point is in fact an exit-node of a circuit initiated by the downloader. In this case, there is no doubt about the connectability of the introduction point, as the introduction point itself is in fact an exit-node of a circuit initiated by the seeder. The current approach in the tunnel community is to require every exit-node in the network to be connectible. The introduction points and rendezvous point for downloading over hidden seeding services should always be connectible, to allow a downloader to build a circuit and connect to the introduction point of the seeder, and to allow the seeder to build a circuit to the rendezvous-point of the downloader.
This is a known weakness in the protocol, but is to be solved later on in future work, when opportunistic encryption in a web of trust is reality. The fields that are marked "VL" have a variable length and use the first 2 bytes to indicate the length.īoth the seeder and downloader use circuits while accessing the DHT, but with the current implementation the introduction point on itself knows which info hash is shared and what the rendezvous point will be. See the figure below for which information is stored in the DHT. Our solution for retrieving the essential information to connect to a hidden seeding service is by storing all required information in our built-in DHT. In a peer-to-peer environment such a central server does not exist, the protocol works in a fully decentralized network of BitTorrent peers. In the original Tor design, central directory servers called HSDirs are used for retrieving information about a hidden service, like the service-key and public keys of the introduction points. Our approach uses the UDP protocol and does not rely on central directory servers. Tor also depends on a number of 'trusted' central directory servers. Tor Hidden services are the leading solution for anonymous webhosting, but unsuitable for video streaming - like YouTube, because it is too slow. The design specification described is mostly based on the ideas and excellent work of the people behind the Tor Project.