The spec gives conficting advice about all-zero ed25519 keys in extends.
Resolve this conflict by documenting tor's current behaviour.
Also move a sentence about circuit IDs, so it's closer to the associated
paragraph.
This only adds newline characters to make the existing text blocks act like
"blockquote" or "code block" syntax in Markdown, asciidoc, and others.
This was accomplished by manually reviewing the output of this script:
```bash
for f in *.txt; do
cat $f | python -c "import sys,re;print(re.sub(r'(\n {0,3}[^ \n][^\n]*\n)( {4,}[^\n]*)', r'\1\n\2', sys.stdin.read()))" > ${f}.tmp
mv ${f}.tmp $f
done
```
The clear standard is trailing "." after each numeric section. This fixes
the small handful of outliers. This makes it easy to convert these headers
to common markup formats, for example:
http://hyperpolyglot.org/lightweight-markup
This merges proposal 289 into tor-spec.txt.
Most of the circuit-level flow control section has been rewritten to be
clearer and better detail version 0 and 1.
Closes#30365
Signed-off-by: David Goulet <dgoulet@torproject.org>
Let's refrain from mentioning section 6.4 in here, as the format
is not exactly the same - not all address type field values from
section 6.4 make sense in NETINFO cell and NETINFO cell does not
have a TTL value at the end of each address. It's a little confusing
to suggest that there is a reuse of wire format fragment between
RELAY_RESOLVED and NETINFO cells.
The section now consists of:
* forward encryption at the client
* forward decryption at ORs
* backward encryption at the end (exit)
* backward decryption at the client
Part of 26860.
In doing so, specify a general behavior for padding bytes in Section 3
and cross-reference other locations to this, to aid in future
consistency.
Also clarify a few vague parts of the prior wording.
Fixes#26860.
Our tor-spec left me pretty mystified what the 'recognized' field actually was.
It discussed what to do when it was zero, but not what the field *was* or what
non-zero meant. Thankfully Roger filled me in over tasty, tasty pizza.
Make sure we mention all the ciphers we use, and use the phrase
"unless otherwise specified" liberally to make sure that people
don't think that we're still RSA1024 all over.
Also rename the hybrid encryption thing to "legacy hybrid
encryption", and put it in its own section.
Closes ticket 22722.
