Onion Routing Technical Architecture: How Tor Works in 2026

Tor's network knowledge is coordinated by directory authorities (dirauths) - a small set (currently 9) of trusted servers that collect relay information and produce a consensus document. The consensus lists all relays, their flags (Guard, Exit, Fast, Stable, etc.), bandwidth weights, and cryptographic information. Clients download the consensus to know which relays exist and their properties. Consensus is produced by a Byzantine fault-tolerant voting process: each dirauth independently gathers relay information, votes on the consensus, and the result requires a majority of dirauths to agree. This design means no single dirauth can unilaterally control the relay list. Fallback directory mirrors (hundreds of relays) distribute consensus to clients so they do not all contact dirauths directly. Clients update consensus periodically (default 1 hour). Bridge relays are not listed in the public consensus (by design); their information is distributed by the BridgeDB.

Tor cells are 514-byte fixed-size chunks. The fixed size prevents traffic analysis based on packet size. Tor circuits (paths through the network) are built incrementally. Circuit construction: client contacts entry guard, establishes TLS connection, performs CREATE handshake (ntor handshake, using X25519 ephemeral keys). The entry guard returns a CREATED cell with a shared secret. Client extends the circuit to a middle relay by sending an EXTEND cell to the entry guard encrypted so only the middle relay can process it. Same EXTEND/CREATED handshake with the middle relay. Circuit extended to exit relay with another EXTEND step. Result: a three-hop circuit where the client shares separate symmetric keys with each relay. Each relay can only decrypt its own layer of encryption. Traffic is sequentially encrypted with the exit key, middle key, and entry key before sending. Each relay removes its layer, routing the remaining layers toward the destination.

Onion service discovery and connection uses a rendezvous protocol. Service side: the onion service generates a long-term Ed25519 key pair. The .onion address is derived from this key (32-character base32 encoding of the public key). The service selects introduction points (relays) and uploads encrypted introduction point information to the Tor distributed hash table (HSDir relays store the information). Client side: client decodes the .onion address to get the service's public key, queries HSDir relays for introduction point information, verifies the information signature using the service's public key, generates a rendezvous point (another relay the client selects), sends a rendezvous cookie and half of a DH key exchange to an introduction point (encrypted to the service's public key). Service side (continued): receives the introduction request at its introduction point, decrypts using its private key, builds a circuit to the rendezvous point, completes the DH key exchange. Result: a 6-hop circuit (client guard + client middle + rendezvous point + service middle + service middle + service guard) with end-to-end encryption. Neither the client nor the service reveals its IP address to the other.

Tor uses modern cryptography throughout. Key exchange: ntor handshake using X25519 (Curve25519) ECDH for circuit construction. Identity signing: Ed25519 for relay identity keys, onion service identity keys. Symmetric encryption: AES-128-CTR for cell encryption (each relay uses a different key). Authentication: HMAC-SHA256 for message authentication. Cell relay encryption: each relay in a circuit uses a unique AES key, and cells are encrypted in layers (like an onion). Hash function: SHA-256 and SHA-3 for various digest operations. Hidden service descriptor encryption (v3 onion services): the service descriptor is encrypted using a key derived from the blinded Ed25519 key for the current time period. This means only clients with the .onion address can decrypt the descriptor, providing an additional layer of authorization. Onion service Proof of Work (added for DDoS resistance): client puzzle uses EQUIX algorithm (memory-hard, CPU-scalable) to prove computational work before a connection is accepted.

Applications integrating Tor should use Stem (Python Tor controller library) or Txtorcon (Twisted-based) for programmatic control. Key API capabilities: creating SOCKS5 connections through Tor, creating ephemeral onion services (ADD_ONION control command), monitoring circuit status, and requesting new circuits. SOCKS5 proxy: Tor exposes a SOCKS5 interface (default 127.0.0.1:9050 for Tor daemon, 127.0.0.1:9150 for Tor Browser). Applications can proxy connections through this SOCKS5 port. DNS isolation: use .onion addresses directly via SOCKS5 (DNS is resolved over Tor, not locally). Use RESOLVE control command for DNS via Tor. Onion service creation via control protocol: ADD_ONION command creates an ephemeral .onion service without requiring torrc configuration. Useful for applications that dynamically create hidden services. Security consideration: applications running over Tor must not leak identifying information (IP addresses, user-agent strings, timing information) through application-layer content. Tor protects the transport, not the application layer.