diff options
Diffstat (limited to 'spec/padding-spec/circuit-level-padding.md')
| -rw-r--r-- | spec/padding-spec/circuit-level-padding.md | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/spec/padding-spec/circuit-level-padding.md b/spec/padding-spec/circuit-level-padding.md index 575f248..a220507 100644 --- a/spec/padding-spec/circuit-level-padding.md +++ b/spec/padding-spec/circuit-level-padding.md @@ -3,13 +3,13 @@ # Circuit-level padding The circuit padding system in Tor is an extension of the WTF-PAD -event-driven state machine design[15]. At a high level, this design places +event-driven state machine design\[15\]. At a high level, this design places one or more padding state machines at the client, and one or more padding state machines at a relay, on each circuit. State transition and histogram generation has been generalized to be fully programmable, and probability distribution support was added to support more -compact representations like APE[16]. Additionally, packet count limits, +compact representations like APE\[16\]. Additionally, packet count limits, rate limiting, and circuit application conditions have been added. At present, Tor uses this system to deploy two pairs of circuit padding @@ -19,7 +19,7 @@ onion service circuits, up to the first 10 cells. This specification covers only the resulting behavior of these padding machines, and thus does not cover the state machine implementation details or operation. For full details on using the circuit padding system to develop -future padding defenses, see the research developer documentation[17]. +future padding defenses, see the research developer documentation\[17\]. <a id="padding-spec.txt-3.1"></a> @@ -133,16 +133,16 @@ Note that inter-arrival timing is not obfuscated by this defense. Most general Tor circuits used to surf the web or download directory information start with the following 6-cell relay cell sequence (cells -surrounded in [brackets] are outgoing, the others are incoming): +surrounded in \[brackets\] are outgoing, the others are incoming): -[EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED +\[EXTEND2\] -> EXTENDED2 -> \[EXTEND2\] -> EXTENDED2 -> \[BEGIN\] -> CONNECTED When this is done, the client has established a 3-hop circuit and also opened a stream to the other end. Usually after this comes a series of DATA cell that either fetches pages, establishes an SSL connection or fetches directory information: -[DATA] -> [DATA] -> DATA -> DATA...(inbound cells continue) +\[DATA\] -> \[DATA\] -> DATA -> DATA...(inbound cells continue) The above stream of 10 relay cells defines the grand majority of general circuits that come out of Tor browser during our testing, and it's what we use @@ -165,7 +165,7 @@ machine terminates at the second hop and does not get forwarded to the actual introduction point. From Section 3.3.1 above, most general circuits have the following initial -relay cell sequence (outgoing cells marked in [brackets]): +relay cell sequence (outgoing cells marked in \[brackets\]): ```text [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED @@ -181,12 +181,12 @@ This means that up to the sixth cell (first line of each sequence above), both general and intro circuits have identical cell sequences. After that we want to mimic the second line sequence of --> [DATA] -> [DATA] -> DATA -> DATA...(inbound data cells continue) +-> \[DATA\] -> \[DATA\] -> DATA -> DATA...(inbound data cells continue) We achieve this by starting padding INTRODUCE1 has been sent. With padding negotiation cells, in the common case of the second line looks like: --> [INTRO1] -> [PADDING_NEGOTIATE] -> PADDING_NEGOTIATED -> INTRO_ACK +-> \[INTRO1\] -> \[PADDING_NEGOTIATE\] -> PADDING_NEGOTIATED -> INTRO_ACK Then, the middle node will send between INTRO_MACHINE_MINIMUM_PADDING (7) and INTRO_MACHINE_MAXIMUM_PADDING (10) cells, to match the "...(inbound data cells @@ -218,7 +218,7 @@ circuits which usually look like this: This means that up to the sixth cell (the first line), both general and rend circuits have identical cell sequences. -After that we want to mimic a [DATA] -> [DATA] -> DATA -> DATA sequence. +After that we want to mimic a \[DATA\] -> \[DATA\] -> DATA -> DATA sequence. With padding negotiation right after the REND_ESTABLISHED, the sequence becomes: @@ -243,7 +243,7 @@ will look alike. ### Circuit setup machine overhead For the intro circuit case, we see that the origin-side machine just sends a -single [PADDING_NEGOTIATE] cell, whereas the origin-side machine sends a +single \[PADDING_NEGOTIATE\] cell, whereas the origin-side machine sends a PADDING_NEGOTIATED cell and between 7 to 10 DROP cells. This means that the average overhead of this machine is 11 padding cells per introduction circuit. |