Skip to content

GitLab

Trac
Trac

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

Closed (moved)
Opened by dmr@dmr

Clarify/determine specification for padding bytes, (formerly also PADDING cell)

EDIT: strikethrough content below is now covered in #26870 (moved) instead

==== Background I was trying to interpret the tor-spec for padding bytes, and ending up asking nickm for some clarification over IRC. nickm suggested most of the cc'd for the ticket - I added atagar, too.

==== Unclear areas Here are the points that need clarification / specification:

  • spec for padding bytes does not clearly say what senders MUST or SHOULD do, [mentioning that padding is with 0 bytes] or [NUL bytes]
  • spec for padding bytes does not say what receivers MUST or SHOULD do, when receiving non-zero bytes in the Cell (e.g. warn? ignore?)
  • spec is a bit inconsistent with PADDING cells ^^[1^^]^^[2^^]

==== Discussion: padding bytes For the padding bytes that are not part of PADDING cells, nickm offered the following as a non-exhaustive set of possible forward-compatible options:

  • "the [padding] bytes SHOULD be zero, and that implementations MUST ignore them"
  • "The first 8 padding bytes MUST be zero; all subsequent padding bytes SHOULD be randomized. Implementations MUST ignore padding bytes"
  • "All padding bytes should be randomized; implemenations MUST ignore unrecognized padding bytes" ... and mentioned that "[he doesn't] know enough of the argument in favor of randomization to have a very strong preference"

==== Inconsistency: PADDING cell payload (see bullet above)

These references highlight the inconsistency:

^^[1^^] PADDING: Payload is unused. per [3 "Cell Packet format"]. ~~ implies 0 bytes of payload, so the rest should be padded per that section~~ ^^[2^^] The contents of a PADDING, VPADDING, or DROP cell SHOULD be chosen randomly, and MUST be ignored. per [7.2 "Link padding"]. ~~ implies the payload of a PADDING cell actually is the rest of the size of the cell, and that it SHOULD be chosen randomly~~

The PADDING cells were mentioned in IRC but not discussed. I think a simple change to make the spec consistent between the two sections would be this: PADDING: Payload contains random data. (See Sec 7.2)

However, given the other points here, is that correct?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information