Is there any way to reduce the length of a hidden service's path to the rendezvous point?

  1. Bob's hidden service <---> Introduction Point
  2. Alice <---> Introduction Point tell Bob to contact me at Rendezvous Point
  3. Bob <-> Rendezvous point

Sometimes, Bob's hidden service does not need anonymity, but wants to be accessible via Tor anyways. (For example, ahmia.fi is also accessible as msydqstlz2kzerdg.onion). In such a case, it might be beneficial to limit the length of Bob's circuit to 1 (as indicated by the length of the arrow in step 3). Is that possible?

This is similar to How to decrease number of Tor hops?. and Accessing Tor hidden services over a single hop circuit, but those wanted to limit the number of client hops. This question is about the number of server hops.

2 Answers 2


There are several amendments to Tor being researched to enable this functionality; the functionality does reduce/remove the anonymity of the server but sometimes that is okay, e.g. if (like Facebook) you run a publicly attested, non-hidden "onion service".*

The amendments are:

None of these are (at time of writing, January 2016) yet sedimented into the main Tor codebase, but they should be in the next few weeks/months.

As the above commenter almost suggests: you should consider carefully before enabling these features. From my experience running a publicly attested Onion, reduced server hop count does improve latency and makes Onion Services as performant, possibly a fraction more performant, than normal Tor. Your mileage may vary.

*Disclosure: I led the team which built the Facebook Onion Service

  • Great answer. Seems like proposal 260 is what I explicitly asked for and 252 preceded it by another design which fulfills it just as well. Which one is used at facebook, if you may tell?
    – serv-inc
    Commented Jan 19, 2016 at 9:20
  • 1
    We ran totally stock, unmodified Tor code for the first year of operation to prove the concept. It worked fine, and was a simple introduction. We are now (Jan 2016) experimenting with RSOS (prop 260) and OnionBalance to scale the aggregate / net bandwidth available for people who want to use our Onion Service. Commented Jan 19, 2016 at 17:07
  • 3
    ps: you didn't ask this, but another relevant proposal is prop 255 "Controller features to allow for load-balancing hidden services" gitweb.torproject.org/torspec.git/tree/proposals/… - which is relevant to high-throughput load balancing of onions Commented Jan 19, 2016 at 17:13
  • Curious if anyone knows the current status of these proposals?
    – DylanYoung
    Commented Dec 19, 2020 at 22:06
  • Single Onion Services work and are supported. Commented Dec 20, 2020 at 23:17

Never decrease the hop length, because it's a purpose of having Tor entry point : to be censorship-resistant. If you will decrease your hidden service behaviour, you will not just decrease it's anonymity, but also make connections to it "fingerprintable"=detectable, and - as a consecuence - censorable

  • 1
    Could you elaborate on how they are made detectable?
    – serv-inc
    Commented Jan 18, 2016 at 19:16
  • 1
    @user do you need a whitepaper or what exactly?
    – Alexey Vesnin
    Commented Jan 19, 2016 at 15:35
  • 2
    It's clear that this can deanonymize the hidden service. If you implied that it can deanonymize the client, what is your reasoning?
    – serv-inc
    Commented Jan 19, 2016 at 17:38
  • 1
    @user I suggest you better start reading here
    – Alexey Vesnin
    Commented Jan 19, 2016 at 17:41
  • I don't see anything about hidden services in that paper. On face your claim seems absurd since tor regularly routes traffic to non hidden services in only four hops. Why would changing the last hop from internet to tor reduce the security guaratees of the client?
    – DylanYoung
    Commented Dec 19, 2020 at 21:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .