Commit 9c097a06 authored by Nick Mathewson's avatar Nick Mathewson 🎨
Browse files

Describe the actual RELAY cell padding algorithm that we use.

For indistinguishability, other implementations should pad the same
way that we do.
parent bf81f842
......@@ -506,9 +506,11 @@ see tor-design.pdf.
Padding bytes SHOULD be set to NUL.
We recommend random padding in RELAY/RELAY_EARLY cells, so that the cell
content is unpredictable. See proposal 289 for details. For other
cells, TLS authenticates cell content, so randomised padding bytes are
content is unpredictable. See the format of relay cells in section 6.1
for detail.
For other cells, TLS authenticates cell content, so randomized padding
bytes are redundant.
Receivers MUST ignore padding bytes.
......@@ -1578,7 +1580,8 @@ see tor-design.pdf.
StreamID [2 bytes]
Digest [4 bytes]
Length [2 bytes]
Data [PAYLOAD_LEN-11 bytes]
Data [Length bytes]
Padding [PAYLOAD_LEN - 11 - Length bytes]
The relay commands are:
......@@ -1649,6 +1652,14 @@ see tor-design.pdf.
handle padding bytes of unencrypted relay cells as they do padding
bytes for other cell types; see Section 3.
The 'Padding' field is used to make relay cell contents unpredictable, to
avoid certain attacks (see proposal 289 for rationale). Implementations
SHOULD fill this field with four zero-valued bytes, followed by as many
random bytes as will fit. (If there are fewer than 4 bytes for padding,
then they should all be filled with zero.
Implementations MUST NOT rely on the contents of the 'Padding' field.
If the RELAY cell is recognized but the relay command is not
understood, the cell must be dropped and ignored. Its contents
still count with respect to the digests and flow control windows, though.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment