If version 2 or higher is negotiated, each party sends the other a

NETINFO cell. The cell's payload is:

TIME (Timestamp) [4 bytes]

OTHERADDR (Other OR's address) [variable]
ATYPE (Address type) [1 byte]
ALEN (Address length) [1 byte]
AVAL (Address value in NBO) [ALEN bytes]
NMYADDR (Number of this OR's addresses) [1 byte]
NMYADDR times:
ATYPE (Address type) [1 byte]
ALEN (Address length) [1 byte]
AVAL (Address value in NBO)) [ALEN bytes]

Recognized address types (ATYPE) are:

[04] IPv4.
[06] IPv6.

ALEN MUST be 4 when ATYPE is 0x04 (IPv4) and 16 when ATYPE is 0x06
(IPv6). If the ALEN value is wrong for the given ATYPE value, then
the provided address should be ignored.

The timestamp is a big-endian unsigned integer number of seconds

since the Unix epoch. Implementations MUST ignore unexpected bytes
at the end of the cell. Clients SHOULD send "0" as their timestamp, to
avoid fingerprinting.

Implementations MAY use the timestamp value to help decide if their

clocks are skewed. Initiators MAY use "other OR's address" to help
learn which address their connections may be originating from, if they
do
not know it; and to learn whether the peer will treat the current
connection as canonical. Implementations SHOULD NOT trust these
values unconditionally, especially when they come from non-authorities,
since the other party can lie about the time or IP addresses it sees.

Initiators SHOULD use "this OR's address" to make sure

that they have connected to another OR at its canonical address.
(See 5.3.1 below.)

5. Circuit management

5.1. CREATE and CREATED cells

Users set up circuits incrementally, one hop at a time. To create a

new circuit, OPs send a CREATE/CREATE2 cell to the first node, with
the first half of an authenticated handshake; that node responds with
a CREATED/CREATED2 cell with the second half of the handshake. To
extend a circuit past the first hop, the OP sends an EXTEND/EXTEND2
relay cell (see section 5.1.2) which instructs the last node in the
circuit to send a CREATE/CREATE2 cell to extend the circuit.

There are two kinds of CREATE and CREATED cells: The older
"CREATE/CREATED" format, and the newer "CREATE2/CREATED2" format. The
newer format is extensible by design; the older one is not.

A CREATE2 cell contains:

HTYPE (Client Handshake Type) [2 bytes]

HLEN (Client Handshake Data Len) [2 bytes]
 HDATA (Client Handshake Data) [HLEN bytes]

A CREATED2 cell contains:

HLEN (Server Handshake Data Len) [2 bytes]

HDATA (Server Handshake Data) [HLEN bytes]

Recognized handshake types are:

0x0000 TAP -- the original Tor handshake; see 5.1.3

0x0001 reserved
0x0002 ntor -- the ntor+curve25519+sha256 handshake; see 5.1.4

The format of a CREATE cell is one of the following:

HDATA (Client Handshake Data) [TAP_C_HANDSHAKE_LEN bytes]

or

HTAG (Client Handshake Type Tag) [16 bytes]

HDATA (Client Handshake Data) [TAP_C_HANDSHAKE_LEN-16 bytes]

The first format is equivalent to a CREATE2 cell with HTYPE of 'tap'

and length of TAP_C_HANDSHAKE_LEN. The second format is a way to
encapsulate new handshake types into the old CREATE cell format for
migration. See 5.1.2 below. Recognized HTAG values are:

ntor -- 'ntorNTORntorNTOR'

The format of a CREATED cell is:

HDATA (Server Handshake Data) [TAP_S_HANDSHAKE_LEN bytes]

(It's equivalent to a CREATED2 cell with length of TAP_S_HANDSHAKE_LEN.)

As usual with DH, x and y MUST be generated randomly.

In general, clients SHOULD use CREATE whenever they are using the TAP
handshake, and CREATE2 otherwise. Clients SHOULD NOT send the
second format of CREATE cells (the one with the handshake type tag)
to a server directly.

Servers always reply to a successful CREATE with a CREATED, and to a

successful CREATE2 with a CREATED2. On failure, a server sends a
DESTROY cell to tear down the circuit.

[CREATE2 is handled by Tor 0.2.4.7-alpha and later.]

5.1.1. Choosing circuit IDs in create cells

The CircID for a CREATE/CREATE2 cell is an arbitrarily chosen

nonzero integer, selected by the node (OP or OR) that sends the
CREATE/CREATE2 cell. In link protocol 3 or lower, CircIDs are 2
bytes long; in protocol 4 or higher, CircIDs are 4 bytes long.

To prevent CircID collisions, when one node sends a CREATE/CREATE2

cell to another, it chooses from only one half of the possible
values based on the ORs' public identity keys.

In link protocol version 3 or lower, if the sending node has a lower

 key, it chooses a CircID with an MSB of 0; otherwise, it chooses a
CircID with an MSB of 1. (Public keys are compared numerically by
modulus.) With protocol version 3 or lower, a client with no public key
MAY choose any CircID it wishes, since clients never need to process a
CREATE/CREATE2 cell.

In link protocol version 4 or higher, whichever node initiated the

connection sets its MSB to 1, and whichever node didn't initiate the
connection sets its MSB to 0.

The CircID value 0 is specifically reserved for cells that do not

belong to any circuit: CircID 0 must not be used for circuits. No
other CircID value, including 0x8000 or 0x80000000, is reserved.

Existing Tor implementations choose their CircID values at random from

among the available unused values. To avoid distinguishability, new
implementations should do the same. Implementations MAY give up and stop
attempting to build new circuits on a channel, if a certain number of
randomly chosen CircID values are all in use (today's Tor stops after
64).

5.1.2. EXTEND and EXTENDED cells

To extend an existing circuit, the client sends an EXTEND or EXTEND2

relay cell to the last node in the circuit.

An EXTEND2 cell's relay payload contains:

NSPEC (Number of link specifiers) [1 byte]

NSPEC times:
LSTYPE (Link specifier type) [1 byte]
LSLEN (Link specifier length) [1 byte]
LSPEC (Link specifier) [LSLEN bytes]
HTYPE (Client Handshake Type) [2 bytes]
HLEN (Client Handshake Data Len) [2 bytes]
HDATA (Client Handshake Data) [HLEN bytes]

Link specifiers describe the next node in the circuit and how to
connect to it. Recognized specifiers are:

[00] TLS-over-TCP, IPv4 address

A four-byte IPv4 address plus two-byte ORPort
[01] TLS-over-TCP, IPv6 address
A sixteen-byte IPv6 address plus two-byte ORPort
[02] Legacy identity
A 20-byte SHA1 identity fingerprint. At most one may be listed.
[03] Ed25519 identity
A 32-byte Ed25519 identity fingerprint. At most one may
be listed.

Nodes MUST ignore unrecognized specifiers, and MUST accept multiple

instances of specifiers other than 'legacy identity'.

For purposes of indistinguishability, implementations SHOULD send

these link specifiers, if using them, in this order: [00], [02], [03],
[01].

The relay payload for an EXTEND relay cell consists of:

Address [4 bytes]
Port [2 bytes]
 Onion skin [TAP_C_HANDSHAKE_LEN bytes]
Identity fingerprint [HASH_LEN bytes]

The "legacy identity" and "identity fingerprint" fields are the

SHA1 hash of the PKCS#1 ASN1 encoding of the next onion router's
identity (signing) key. (See 0.3 above.) The "Ed25519 identity"
field is the Ed25519 identity key of the target node. Including
this key information allows the extending OR verify that it is
indeed connected to the correct target OR, and prevents certain
man-in-the-middle attacks.

Extending ORs MUST check _all_ provided identity keys (if they
recognize the format), and and MUST NOT extend the circuit if the
target OR did not prove its ownership of any such identity key.
If only one identity key is provided, but the extending OR knows
the other (from directory information), then the OR SHOULD also
enforce that key.

If an extending OR has a channel with a given Ed25519 ID and RSA

identity, and receives a request for that Ed25519 ID and a
different RSA identity, it SHOULD NOT attempt to make another
connection: it should just fail and DESTROY the circuit.

The client MAY include multiple IPv4 or IPv6 link specifiers in an

EXTEND cell; current OR implementations only consider the first
of each type.

After checking relay identities, extending ORs generate a

CREATE/CREATE2 cell from the contents of the EXTEND/EXTEND2 cell.
See section 5.3 for details.

The payload of an EXTENDED cell is the same as the payload of a

CREATED cell.

The payload of an EXTENDED2 cell is the same as the payload of a

CREATED2 cell.

[Support for EXTEND2/EXTENDED2 was added in Tor 0.2.4.8-alpha.]

Clients SHOULD use the EXTEND format whenever sending a TAP

handshake, and MUST use it whenever the EXTEND cell will be handled
by a node running a version of Tor too old to support EXTEND2. In
other cases, clients SHOULD use EXTEND2.

When generating an EXTEND2 cell, clients SHOULD include the target's

Ed25519 identity whenever the target has one, and whenever the
target supports LinkAuth subprotocol version "3". (See section 9.2.)

When encoding a non-TAP handshake in an EXTEND cell, clients SHOULD

use the format with 'client handshake type tag'.

5.1.3. The "TAP" handshake

This handshake uses Diffie-Hellman in Z_p and RSA to compute a set of

shared keys which the client knows are shared only with a particular
server, and the server knows are shared with whomever sent the
original handshake (or with nobody at all). It's not very fast and
not very good. (See Goldberg's "On the Security of the Tor
Authentication Protocol".)