3

One of the reasons for not using the introduction circuit for actuall communication is that no single relay should apppear to be responsible for a given hidden service. This is why rendezvous points never learns about the hidden services identity.
from https://www.torproject.org/docs/hidden-services.html.en

This doesn't make sense to me since the location of the different introductory points is published to distributed databases. So naturally, won't said introductory points become tied to the hidden service regardless? Furthermore, if this was such a great concern, couldn't the hidden service simply change its introduction points periodically? Lastly, presumably the circuits that lead from the hidden service to the introductory point must not be static, since there's only a finite amount of relays that can fit the bill to make this possible (stable/high uptime), so if the circuits leading to the introductory point are constantly changing, doesn't that itself hide the hidden service's identity as well as the use of rendezvous point does?

3

Rendezvous Points(RPs) are responsible for facilitating the actual data transfer between a hidden service and a client and its main goal is to provide a randomized path for communications. The Introduction Points(IPs) on the other hand only facilitate the key material exchange and have a known, stored location. This was designed to address:

Performance: If an IP was responsible for also exchanging data to the HS, there would be a DoS condition. But as it is, the IP only sends a small amount of data and relies on the vast pool other random nodes for RP creating an attempt at load balancing.

Security: Making the IP responsible for communications AND data transfer would mean that you are hitting the sames circuit path over and over because the IP needs to be long-lived. This makes the HS more likely to be fingerprintable via data correlation attack. Splitting them up means that all communications between a client and a server are randomized making it harder to fingerprint.

Functionality: In the current design, there isn't a way for a HSDir to tell a client how to connect to a hidden service (by design). Therefore to figure out how to connect to a HS, another service would need to provide this and that's why IPs were created. If there was a redesign making the HSDir responsible for facilitating the path to the hidden service, it would make the HSDir very powerful and at increased risk of attack (more than it is now).

0

Tor uses different circuits for communicating with IP and actual HS traffic. If an IP handles actual traffic, it can correlate the introductory circuit with your rendezvous circuit, thus a malicious IP may make you always choose it, seeing what you do and fingerprinting you.

I2P has a design like what you said, but its leases are short-lived.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.