# tor-cell
Coding and decoding for the cell types that make up Tor's protocol
## Overview
Tor's primary network protocol is oriented around a set of
messages called "Cells". They exist at two primary layers of the
protocol: the channel-cell layer, and the relay-cell layer.
[Channel cells](chancell::ChanCell) are sent between relays, or
between a client and a relay, over a TLS connection. Each of them
encodes a single [Channel Message](chancell::ChanMsg).
Channel messages can affect the channel itself (such as those used
to negotiate and authenticate the channel), but more frequently are
used with respect to a given multi-hop circuit.
Channel message that refer to a circuit do so with a channel-local
identifier called a [Circuit ID](chancell::CircId). These
messages include CREATE2 (used to extend a circuit to a first hop)
and DESTROY (used to tear down a circuit). But the most
frequently used channel message is RELAY, which is used to send a
message to a given hop along a circuit.
Each RELAY cell is encrypted and decrypted (according to protocols
not implemented in this crate) until it reaches its target. When
it does, it is decoded into a single [Relay
Message](relaycell::RelayMsg). Some of these relay messages
are used to manipulate circuits (e.g., by extending the circuit to
a new hop); others are used to manipulate anonymous data-streams
(by creating them, ending them, or sending data); and still others
are used for protocol-specific purposes (like negotiating with an
onion service.)
For a list of _most_ of the cell types used in Tor, see
[tor-spec.txt](https://spec.torproject.org/tor-spec). Other cell
types are defined in [rend-spec-v3.txt (for onion
services)](https://spec.torproject.org/tor-spec) and
[padding-spec.txt (for padding
negotiation)](https://spec.torproject.org/padding-spec).
This crate is part of
[Arti](https://gitlab.torproject.org/tpo/core/arti/), a project to
implement [Tor](https://www.torproject.org/) in Rust.
## Compile-time features
* `hs` -- Types relating to Tor Hidden Services (`.onion` services).
* `hs-pow-v1` -- Types relating to Tor Hidden Services Proof of Work (`v1` scheme only)
* `hs-pow-full` -- Types relating to Tor Hidden Services Proof of Work
(metafeature, enables all non-experimental schemes: currently, implies only `hs-pow-v1`).
* `full` -- Enable all features above.
### Experimental and unstable features
Note that the APIs enabled by these features are NOT covered by
semantic versioning[^1] guarantees: we might break them or remove
them between patch versions.
* `experimental-udp`: Types for conveying UDP over Tor.
* `testing`: Additional APIs for testing,
used in our whole-workspace tests.
* `experimental`: Enable all the above experimental features.
features work reliably. To be explicit: if you want `cargo update`
to _only_ make safe changes, then you cannot enable these
features.
License: MIT OR Apache-2.0