How Do You Find a Site That Does Not Publish Its IP Address?

First: The Participants and Documents

An onion service is a service reachable entirely through Tor. The Tor client is the software component that wants to reach it. Both build circuits: logical paths through multiple relays in the Tor network.

A relay is a node that forwards traffic for other participants. Some relays can also act as an HSDir, short for hidden service directory: they temporarily store documents published by onion services.

One such document is the onion descriptor. It describes the points through which a client can ask to be introduced to the service. It is neither the network consensus nor the web page offered by the service.

The consensus, by contrast, is the signed map of the Tor network. It lists usable relays and provides shared parameters. Client and service start from the same map.

An Onion Name Identifies Someone, Not Somewhere

A version 3 onion service has an identity key pair. The private key remains with the service. The corresponding public key lets others verify operations tied to that identity.

The onion address is derived from three elements:

• the service’s Ed25519 identity public key;
• a checksum, a short check against errors and invalid combinations;
• one byte indicating the format version.

These 35 bytes are represented in Base32, a textual alphabet suitable for turning binary data into copyable characters, and receive the .onion suffix.

The name contains neither the server’s IP address nor the relays the service is using at that moment.

Instead, it contains the public identity needed to tie subsequent steps to the same service. This is why it is called self-authenticating: the name carries the public material from which the client can cryptographically verify the identity, rather than relying on an external mapping between name and owner.

The Service Prepares Entrances That Are Not Its Location

Before any particular client arrives, the service selects several relays as introduction points and builds circuits to them.

An introduction point is a delivery point. It can forward a future introduction request to the service through an already active circuit. That circuit crosses other relays, so the introduction point’s direct neighbor is a relay, not the service’s server.

The service keeps these circuits available and puts the following in the descriptor:

• the usable introduction points;
• the cryptographic material needed to address a request to the service;
• the protocol information needed to interpret the document.

The descriptor does not contain the future rendezvous point. The client chooses that only after discovery. Nor does it contain the site’s application data.

Why Not Always Publish Under the Same Identity?

The onion address must remain stable; otherwise nobody could save or share it. Why, then, does Tor not always publish the descriptor directly under that same identity?

Because the key used to sign and index directory information must be able to change over time without changing the public identity users retain. Tor thus avoids using the long-term identity key directly for every publication and can distribute descriptors across positions that rotate between periods.

Tor therefore introduces a blinded key, a public key derived for a specific period. The term blinding refers to this transformation: the stable identity produces a temporary identifier, but the service gives its private key to nobody.

The client can derive the same blinded key. It has the public key embedded in the onion address and knows the period and the network’s shared parameters. The name therefore remains stable while the key used for publication changes over time.

How HSDirs Are Chosen

The consensus lets everyone order HSDirs in a circular identifier space. We can picture it as a ring, provided we remember that it is not physical geography: relays adjacent on the ring can be in different countries.

For the current period, the blinded key, the period, and the replica number determine the descriptor indexes. Separately, each HSDir’s identity, a shared random value, and the same period determine that relay’s position on the ring. The shared random value is published in the directory information and makes it harder to predict far in advance which HSDirs will be responsible.

Consensus parameters determine how many replicas and HSDirs to use. By comparing descriptor indexes with relay positions, the client and service identify the responsible HSDirs, which become the document’s temporary custodians.

There is therefore no central server that receives the question “where is this onion?” The service calculates where to publish. The client repeats the calculation to know where to look.

Nor is it a random search among all relays. Given the same inputs, both converge on the same positions.

The Service Publishes Without Using the Future Data Path

The service builds dedicated circuits to the responsible HSDirs and uploads the descriptor. Publication happens through Tor, so the HSDir does not directly receive a connection from the service’s original IP address.

The HSDir’s role ends here: it stores and distributes the document. It does not become an introduction point or rendezvous point, and it does not enter the future application-data path. Introduction points maintain circuits to the service; the HSDir stores protected contact information. These are different functions.

The Client Repeats the Same Calculation

When it receives the .onion address, the client checks its format and checksum, then extracts the public key and version. It uses the current period and its copy of the consensus to derive the same blinded key and indexes.

The client builds a dedicated circuit to a responsible HSDir and requests the descriptor. This download also remains separate from the circuits that will be used for introduction and rendezvous.

The descriptor uses two encryption layers with different purposes.

The first protects contact information from an HSDir that stores the document but does not already know the onion address. This does not make association impossible in every case: an HSDir that learns the name from another source can derive the protocol-defined material and try to access this layer.

The second layer supports restricted discovery, an optional mode in which only authorized clients possess the required credentials. Without this mode, it does not add a separate list of authorized visitors.

After decrypting a valid descriptor, the client obtains the introduction points and the cryptographic material required for the next phase.

It does not obtain the service’s IP address.

Positions Change Without Changing the Name

When the period changes, the blinded key changes too. The indexes and group of responsible HSDirs therefore change, while the onion address remains the same.

The transition cannot be abrupt. Different clients may hold consensuses referring to slightly different times. The service therefore maintains overlapping descriptors across adjacent periods, so both temporal views can still find valid information.

Duration and distribution are governed by protocol parameters. The mechanism to remember is coordinated rotation with an overlap window.

Discovery Does Not Yet Mean Connection

At the end of this phase, the client knows an onion identity, several introduction points, and the material needed to formulate a request. It does not directly know the service’s network location, has not yet chosen the relay on which to meet it, and has not yet opened an application stream.

Discovery has found a door to knock on without turning it into the house’s public address. The client must now choose a rendezvous point and communicate that choice to the service: the next article follows the meeting of the two circuits.