commit 9c097a0651d0a5f0bfd3c92a7eb89fa22eb7de8a Author: Nick Mathewson nickm@torproject.org Date: Thu Sep 17 09:28:06 2020 -0400
Describe the actual RELAY cell padding algorithm that we use.
For indistinguishability, other implementations should pad the same way that we do. --- tor-spec.txt | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/tor-spec.txt b/tor-spec.txt index 3e82ee8..11a991a 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -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 - redundant. + 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.