arti/crates/tor-cell
Nick Mathewson 96875ea208 Bump crate versions in preparation for Arti 1.0.0 release.
Because we want to work more on ensuring that our semver stability
story is solid, we are _not_ bumping arti-client to 1.0.0 right now.

Here are the bumps we _are_ doing.  Crates with "minor" bumps have
had API breaks; crates with "patch" bumps have had new APIs added.

Note that `tor-congestion` is not bumped here: it's a new crate, and
hasn't been published before.

```
tor-basic-utils         minor
fs-mistrust             minor
tor-config              minor
tor-rtcompat            minor
tor-rtmock              minor
tor-llcrypto            patch
tor-bytes               patch
tor-linkspec            minor
tor-cell                minor
tor-proto               minor
tor-netdoc              patch
tor-netdir              minor
tor-persist             patch
tor-chanmgr             minor
tor-guardmgr            minor
tor-circmgr             minor
tor-dirmgr              minor
arti-client             minor
arti-hyper              minor
arti                    major
arti-bench              minor
arti-testing            minor
```
2022-09-01 08:59:49 -04:00
..
fuzz Update corpus and links. 2021-09-07 12:32:50 -04:00
src Clean up EstablishIntro cell 2022-08-25 16:45:40 -04:00
tests Clean up EstablishIntro cell 2022-08-25 16:45:40 -04:00
Cargo.toml Bump crate versions in preparation for Arti 1.0.0 release. 2022-09-01 08:59:49 -04:00
README.md Update our disclaimers and limitations sections. 2021-10-27 11:13:46 -04:00
semver.md Add semver notes 2022-08-17 10:54:41 +01:00

README.md

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 are sent between relays, or between a client and a relay, over a TLS connection. Each of them encodes a single Channel Message. 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. 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. 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. Other cell types are defined in rend-spec-v3.txt (for onion services) and padding-spec.txt (for padding negotiation).

This crate is part of Arti, a project to implement Tor in Rust.

Futureproofing note

There are two pending proposals to remove the one-to-one correspondence between relay cells and relay messages.

Proposal 319 would add a "RELAY_FRAGMENT" command that would allow larger relay messages to span multiple RELAY cells.

Proposal 325, on the other hand, would allow multiple relay messages to be packed into a single RELAY cell.

The distinction between RelayCell and RelayMsg is meant in part to future-proof arti against these proposals if they are adopted.

License: MIT OR Apache-2.0