About these specifications
    Introduction
    1. A short introduction to Tor
        1.1. Notation and conventions
    The core Tor protocol
    2. Tor Protocol Specification
        2.1. Preliminaries
        2.2. Relay keys and identities
        2.3. Channels
            2.3.1. Negotiating and initializing channels
                2.3.1.1. Obsolete channel negotiation handshakes
            2.3.2. Cells (messages on channels)
        2.4. Circuit management
            2.4.1. CREATE and CREATED cells
            2.4.2. Setting circuit keys
            2.4.3. Creating circuits
            2.4.4. Tearing down circuits
            2.4.5. Routing relay cells
            2.4.6. Handling relay_early cells
        2.5. Application connections and stream management
            2.5.1. Relay cells
            2.5.2. Opening streams and transferring data
            2.5.3. Closing streams
            2.5.4. Remote hostname lookup
        2.6. Flow control
        2.7. Subprotocol versioning
        2.8. Certificates in Tor
    3. Tor directory protocol, version 3
        3.1. Outline
        3.2. netdoc document meta-format
        3.3. Router operation and formats
            3.3.1. Uploading server descriptors and extra-info documents
            3.3.2. Server descriptor format
            3.3.3. Extra-info document format
            3.3.4. Nonterminals in server descriptors
        3.4. Directory authority operation and formats
            3.4.1. Creating key certificates
            3.4.2. Accepting server descriptor and extra-info document uploads
            3.4.3. Computing microdescriptors
            3.4.4. Exchanging votes
                3.4.4.1. Vote and consensus status document formats
                3.4.4.2. Assigning flags in a vote
                3.4.4.3. Serving bandwidth list files
            3.4.5. Downloading information from other directory authorities
            3.4.6. Computing a consensus from a set of votes
            3.4.7. Exchanging detached signatures
            3.4.8. Publishing the signed consensus
        3.5. Directory cache operation
        3.6. Client operation
        3.7. Standards compliance
        3.8. Consensus-negotiation timeline.
        3.9. General-use HTTP URLs
        3.10. Converting a curve25519 public key to an ed25519 public key
        3.11. Inferring missing proto lines.
        3.12. Limited ed diff format
        3.13. Tor Shared Random Subsystem Specification
            3.13.1. Introduction
            3.13.2. Overview
            3.13.3. Protocol
            3.13.4. Specification [SPEC]
            3.13.5. Security Analysis
            3.13.6. Discussion
            3.13.7. Acknowledgements
    4. Tor Path Specification
        4.1. General operation
        4.2. Building circuits
            4.2.1. When we build
            4.2.2. Path selection and constraints
            4.2.3. Cannibalizing circuits
            4.2.4. Learning when to give up ("timeout") on circuit construction
            4.2.5. Handling failure
        4.3. Attaching streams to circuits
        4.4. Hidden-service related circuits
        4.5. Guard nodes
        4.6. Server descriptor purposes
        4.7. Detecting route manipulation by Guard nodes (Path Bias)
    5. Tor Guard Specification
        5.1. State instances
        5.2. Circuit Creation, Entry Guard Selection (1000 foot view)
        5.3. The algorithm.
        5.4. Appendices
    6. Tor Vanguards Specification
        6.1. Full Vanguards
        6.2. Vanguards-Lite
        6.3. Path Construction
        6.4. Statistical Analysis
    7. Tor Padding Specification
        7.1. Overview
        7.2. Connection-level padding
        7.3. Circuit-level padding
        7.4. Acknowledgments
    8. Preventing Denial-Of-Service
        8.1. Overview
        8.2. Memory exhaustion
    Additional behaviors for clients
    9. Tor's extensions to the SOCKS protocol
    10. Special Hostnames in Tor
    Onion services
    11. Tor Rendezvous Specification - Version 3
        11.1. Hidden services: overview and preliminaries.
        11.2. Protocol overview
        11.3. Generating and publishing hidden service descriptors [HSDIR]
            11.3.1. Deriving blinded keys and subcredentials [SUBCRED]
            11.3.2. Publishing shared random values [PUB-SHAREDRANDOM]
            11.3.3. Hidden service descriptors: outer wrapper [DESC-OUTER]
            11.3.4. Hidden service descriptors: encryption format [HS-DESC-ENC]
        11.4. The introduction protocol [INTRO-PROTOCOL]
        11.5. The rendezvous protocol
        11.6. Encrypting data between client and host
        11.7. Encoding onion addresses [ONIONADDRESS]
        11.8. Managing streams
        11.9. References
        11.10. Appendix A: Signature scheme with key blinding [KEYBLIND]
        11.11. Appendix B: Selecting nodes [PICKNODES]
        11.12. Appendix C: Recommendations for searching for vanity .onions [VANITY]
        11.13. Appendix D: (removed)
        11.14. Appendix E: Reserved numbers
        11.15. Appendix F: Hidden service directory format [HIDSERVDIR-FORMAT]
        11.16. Appendix G: Managing restricted discovery data [RESTRICTED-DISCOVERY-MGMT]
        11.17. Appendix F: Two methods for managing revision counters.
        11.18. Appendix G: Test vectors
    12. Proof of Work for onion service introduction
        12.1. Motivation
        12.2. Common protocol
        12.3. Version 1, Equi-X and Blake2b
        12.4. Analysis and discussion
    Anticensorship tools and protocols
    13. BridgeDB specification
    14. Extended ORPort for pluggable transports
    15. Pluggable Transport Specification (Version 1)
        15.1. Introduction
        15.2. Architecture Overview
        15.3. Specification
            15.3.1. Pluggable Transport Naming
            15.3.2. Pluggable Transport Configuration Environment Variables
            15.3.3. Pluggable Transport To Parent Process Communication
            15.3.4. Pluggable Transport Shutdown
            15.3.5. Pluggable Transport Client Per-Connection Arguments
        15.4. Anonymity Considerations
        15.5. References
        15.6. Acknowledgments
        15.7. Appendix A: Example Client Pluggable Transport Session
        15.8. Appendix B: Example Server Pluggable Transport Session
    For C Tor only
    16. The Tor Control Protocol
        16.1. Protocol outline
        16.2. Message format
        16.3. Commands
        16.4. Replies
        16.5. Implementation notes
    17. How Tor Version Numbers Work
    Less commonly needed file formats
    18. Tor Bandwidth File Format
        18.1. Scope and preliminaries
        18.2. Format details
            18.2.1. Definitions
            18.2.2. Header List format
            18.2.3. Relay Line format
            18.2.4. Implementation details
        18.3. Sample data
        18.4. Scaling bandwidths
    Implementation details
    19. Tor Directory List Format
    Reserved names and numbers
    20. Tor network parameters
    21. SSH protocol extensions
    Unfinished
    22. Glossary
    Historical information
    23. Historical protocol elements and behaviours
        23.1. Historical netdoc Items
        23.2. Historical special hostnames
    Maintenance and and editing of the Tor Specifications
    24. About the Tor Specifications documents
    25. Style guide
    26. Permalinks

Tor Specifications

Computing microdescriptors

Microdescriptors are a stripped-down version of server descriptors generated by the directory authorities which may additionally contain authority-generated information. Microdescriptors contain only the most relevant parts that clients care about. Microdescriptors are expected to be relatively static and only change about once per week. Microdescriptors do not contain any information that clients need to use to decide which servers to fetch information about, or which servers to fetch information from.

Microdescriptors are a straight transform from the server descriptor and the consensus method. Microdescriptors have no header or footer. A microdescriptor is identified by the SHA256 hash of its concatenated elements without a signature by the router. Microdescriptors do not contain any version information, because their version is determined by the consensus method.

Starting with consensus method 8, microdescriptors contain the following elements taken from or based on the server descriptor. Order matters here, because different directory authorities must be able to transform a given server descriptor and consensus method into the exact same microdescriptor.

"onion-key" NL (Optionally, a public key in PEM format)

[Exactly once, at start] [No extra arguments]

Optionally, an obsolete TAP key. (Note that while the key is optional, the onion-key element itself is not. It is used to denote the start of a microdescriptor.)

This key is no longer used for anything. If present, it MUST be in the same format as described for relay descriptors.

All current consensus methods generate a key in this position.

"ntor-onion-key" SP base-64-encoded-key NL

[Exactly once]

The "ntor-onion-key" element as specified in section 2.1.1.

When generating microdescriptors for consensus method 30 or later, the trailing = sign must be absent. For consensus method 29 or earlier, the trailing = sign must be present.

(Only included when generating microdescriptors for consensus-method 16 or later.)

[Before Tor 0.4.5.1-alpha, this field was optional.]

"a" SP address ":" port NL

[Any number]

Additional advertised addresses for the OR.

Present currently only if the OR advertises at least one IPv6 address; currently, the first address is included and all others are omitted. Any other IPv4 or IPv6 addresses should be ignored.

Address and port are as for "or-address" as specified in section 2.1.1.

(Only included when generating microdescriptors for consensus-methods 14 to 27.)

"family" names NL

[At most once]

The "family" element as specified in section 2.1.1.

When generating microdescriptors for consensus method 29 or later, the following canonicalization algorithm is applied to improve compression:

           For all entries of the form $hexid=name or $hexid~name,
           remove the =name or ~name portion.

           Remove all entries of the form $hexid, where hexid is not
           40 hexadecimal characters long.

           If an entry is a valid nickname, put it into lower case.

           If an entry is a valid $hexid, put it into upper case.

           If there are any entries, add a single $hexid entry for
           the relay in question, so that it is a member of its own
           family.

           Sort all entries in lexical order.

           Remove duplicate entries.

(Note that if an entry is not of the form "nickname", "$hexid", "$hexid=nickname" or "$hexid~nickname", then it will be unchanged: this is what makes the algorithm forward-compatible.)

"p" SP ("accept" / "reject") SP PortList NL

[At most once.]

The exit-policy summary as specified in sections 3.4.1 and 3.8.2.

[With microdescriptors, clients don't learn exact exit policies: clients can only guess whether a relay accepts their request, try the BEGIN request, and might get end-reason-exit-policy if they guessed wrong, in which case they'll have to try elsewhere.]

[In consensus methods before 5, this line was omitted.]

"p6" SP ("accept" / "reject") SP PortList NL

[At most once]

The IPv6 exit policy summary as specified in sections 3.4.1 and 3.8.2. A missing "p6" line is equivalent to "p6 reject 1-65535".

(Only included when generating microdescriptors for consensus-method 15 or later.)

"id" SP "rsa1024" SP base64-encoded-identity-digest NL

[At most once]

The node identity digest SHA1(DER(KP_relayid_rsa)), base64 encoded, without trailing =s. This line is included to prevent collisions between microdescriptors.

Implementations SHOULD ignore these lines: they are added to microdescriptors only to prevent collisions.

(Only included when generating microdescriptors for consensus-method 18 or later.)

"id" SP "ed25519" SP base64-encoded-ed25519-identity NL

[At most once]

The node's master Ed25519 identity key, base64 encoded, without trailing =s.

All implementations MUST ignore this key for any microdescriptor whose corresponding entry in the consensus includes the 'NoEdConsensus' flag.

(Only included when generating microdescriptors for consensus-method 21 or later.)

"id" SP keytype ... NL

[At most once per distinct keytype.]

Implementations MUST ignore "id" lines with unrecognized key-types in place of "rsa1024" or "ed25519"

(Note that with microdescriptors, clients do not learn the RSA identity of their routers: they only learn a hash of the RSA identity key. This is all they need to confirm the actual identity key when doing a TLS handshake, and all they need to put the identity key digest in their CREATE cells.)