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)
Section titled “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
Section titled “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
Section titled “C. HSDir Eligibility & Relay Selection”Not every Tor relay can become an HSDir.
Eligibility Requirements
Section titled “Eligibility Requirements”A relay must:
-
Be running for a minimum uptime (historically ~25 hours)
-
Be flagged as stable by directory authorities
-
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
Section titled “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
Section titled “High-Level Process”-
Onion service derives a blinded public key for the day
-
A descriptor ID is computed via cryptographic hashing
-
That ID maps to a position on the Tor hash ring
-
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
Section titled “E. Cryptographic Protections in v3 Onion Services”Tor v3 introduced major HSDir security upgrades.
1. Blinded Keys (Forward Security for Discovery)
Section titled “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
Section titled “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
Section titled “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
Section titled “F. Trust Assumptions Behind HSDirs”Tor’s trust model assumes:
-
Some relays may be malicious
-
Most relays are honest
-
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
Section titled “G. Known Academic Attacks & Mitigations”Research has shown HSDirs can be abused under certain conditions.
1. Descriptor Harvesting (v2-era)
Section titled “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
Section titled “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
Section titled “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
Section titled “H. HSDirs vs Traditional Directories”| Feature | Traditional Directory | HSDir |
|---|---|---|
| Central authority | Yes | No |
| Stores plaintext data | Often | Never |
| Long-term records | Yes | No |
| Trust model | Institutional | Cryptographic |
| Censorship resistance | Low | High |
HSDirs are deliberately ephemeral and blind.
I. Why HSDirs Are a “Necessary Weak Point”
Section titled “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.