3.2 HSDir (Hidden Service Directory) Cryptographic Workflows

3.2 HSDir (Hidden Service Directory) Cryptographic Workflows

Hidden Service Directories (HSDirs) are one of the least understood yet most critical components of Tor’s onion service infrastructure.
They act as temporary, distributed lookup points that allow clients to find onion services without revealing the service’s location or identity.

This chapter explains what HSDirs are, how cryptography governs their behavior, and what trust assumptions Tor makes when using them.


A. What Is an HSDir? (Conceptual Definition)

An HSDir is a Tor relay that is eligible to store onion service descriptors.

A service descriptor contains:

  • encrypted introduction point information

  • cryptographic parameters needed to establish contact

  • time-bounded metadata (not identity data)

HSDirs do not host websites, do not see service traffic, and cannot decrypt descriptors.

Their sole purpose is secure, temporary indexing.


B. Why Onion Services Need HSDirs

Onion services face a unique problem:

How can a client find a service whose location must remain hidden?

Traditional systems use:

  • DNS

  • centralized registries

  • certificate authorities

These are incompatible with anonymity.

HSDirs solve this by:

  • distributing encrypted descriptors

  • rotating storage locations daily

  • eliminating central authority

They are discovery points, not communication endpoints.


C. HSDir Eligibility & Relay Selection

Not every Tor relay can become an HSDir.

Eligibility Requirements

A relay must:

  1. Be running for a minimum uptime (historically ~25 hours)

  2. Be flagged as stable by directory authorities

  3. Meet bandwidth and reliability thresholds

This reduces:

  • churn attacks

  • malicious short-lived relays

  • descriptor harvesting attempts

HSDir roles are earned, not assigned.


D. Descriptor Placement: Cryptographic Hash Ring

HSDirs are selected using a distributed hash ring based on:

  • the onion service’s public key

  • the current time period

  • a shared network consensus

High-Level Process

  1. Onion service derives a blinded public key for the day

  2. A descriptor ID is computed via cryptographic hashing

  3. That ID maps to a position on the Tor hash ring

  4. A small set of HSDirs “near” that position store the descriptor

This ensures:

  • predictability for clients

  • unpredictability for adversaries

No single HSDir controls discovery.


E. Cryptographic Protections in v3 Onion Services

Tor v3 introduced major HSDir security upgrades.


1. Blinded Keys (Forward Security for Discovery)

Instead of publishing its real public key:

  • the service derives a daily blinded key

  • HSDirs never see the long-term identity key

Benefits:

  • prevents long-term tracking

  • limits damage from HSDir compromise

  • enables forward secrecy at the discovery layer


2. Encrypted Service Descriptors

Descriptors stored at HSDirs are:

  • encrypted

  • authenticated

  • readable only by clients who know the onion address

HSDirs cannot:

  • identify which service they store

  • read introduction point details

  • determine service behavior

This is critical to minimizing trust.


3. Replicated Storage

Each descriptor is stored on:

  • multiple HSDirs (typically 6)

Replication ensures:

  • availability

  • resilience to node failure

  • resistance to targeted takedowns

No quorum can censor the service easily.


F. Trust Assumptions Behind HSDirs

Tor’s trust model assumes:

  1. Some relays may be malicious

  2. Most relays are honest

  3. No global adversary controls a large fraction of HSDirs consistently

Tor does not assume HSDirs are trustworthy.
It assumes they are observable, replaceable, and limited in power.

This is known as minimized trust by cryptographic constraint.


G. Known Academic Attacks & Mitigations

Research has shown HSDirs can be abused under certain conditions.


1. Descriptor Harvesting (v2-era)

Attackers attempted to:

  • position malicious relays as HSDirs

  • collect descriptors over time

Mitigation:
v3 blinded keys and encrypted descriptors.


2. Targeted HSDir Placement

Adversaries tried to:

  • manipulate relay identity keys

  • control hash-ring positions

Mitigation:
Stricter HSDir eligibility rules and randomized selection.


3. Denial-of-Service via Descriptor Flooding

Attempts to:

  • overload HSDirs with descriptors

Mitigation:
Rate limits, validation rules, and improved descriptor formats.


H. HSDirs vs Traditional Directories

FeatureTraditional DirectoryHSDir
Central authorityYesNo
Stores plaintext dataOftenNever
Long-term recordsYesNo
Trust modelInstitutionalCryptographic
Censorship resistanceLowHigh

HSDirs are deliberately ephemeral and blind.


I. Why HSDirs Are a “Necessary Weak Point”

HSDirs are sometimes criticized because:

  • they are lookup points

  • they introduce partial centralization

However:

  • discovery without directories is impractical

  • HSDirs minimize information leakage

  • cryptography limits their power

They represent a trade-off between usability and anonymity, carefully tuned by years of research.

docs