Reason behind this is to simplify the negotiation of this feature. A
ntorv3 handshake is in the fast path of circuit creation and minimizing
any parsing and on the wire binary size is a win.
Furthermore, this prevents us to go into a complex code path of version
negotiation where either side can be tricked into using another older
version.
We also do NOT expect to ever end up in a situation where one side sends
packed cells but not the other.
And so, this change simplifies everything and reflects the approach we
took with congestion control as well. Future change of packed/fragmented
relay cells will be possible through a new ntorv3 extension and a Relay
protover.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Introduce an optional header called the "message routing header" which
contains a `stream_id` and is only present for commands that do require
it.
We also specify that if an unrecognized command is encountered, the
circuit MUST be destroyed immediately.
Signed-off-by: David Goulet <dgoulet@torproject.org>
These layers use SHA3 instead of SHA1 and AES256 instead of AES128.
Their SENDME tags are made with SHA3 too, but they are truncated to
20 bytes.
Closes#204.
This makes numerous small changes, but also adds some larger blocks of
explanation that are written based on the finalized design.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
EXTEND/EXTEND2 cells MUST only be send through RELAY_EARLY cells, as
demanded by section 5.6.
This commit informs about this in the section of the EXTEND/EXTEND2
cells, as the current formulation contradicts the one in 5.6 to some
degree.
These were generated using a patched Tor with extra logging info.
I've used them to validate (and find bugs in) the arti hs-ntor
implementation. (See arti!1189.)
This commit adds an explanation of the meaning behind the EXP(a, b)
function, primarily targeted for readers without a deep understanding of
the cryptography.
Fixes#195
This commit updates the "5.1.1. Choosing circuit IDs in create cells"
section, in order to clarify its importance, as well as to adjust it to
modern link protocol versions.
The first goal is achieved, by directly adding a "MUST" in the first
paragraph, alongside a reformulation in the paragraph explaining the
method in link protocol version 4 or higher.
The second goal is achieved by merging the second paragraph with the
third paragraph, as the second paragraph only applies to the link
protocol versions addressed in the third one.
Specifically, you can look at the directory to see if somebody is
lying about a relay (mismatched IDs, etc), but you can't modify
the list of linkspecs.
We were previously a bit unclear on how to handle multiple linkspecs
of type ed25519, and our spec didn't actually permit Tor's current
behavior.
Now we say that both Ed25519 ID and Legacy ID linkspecs MUST appear
at most once in a list of linkspecs, and that parties SHOULD
enforce this.
This is "problem 1" on torspec#193.
I found src/lib/encoding/binascii.[ch] in the C Tor codebase.
It has
#define BASE32_CHARS "abcdefghijklmnopqrstuvwxyz234567"
The function "base32_encode" says "Implements base32 encoding as in
RFC 4648.". Now, that RFC says that it's supposed to be padded unless
explicitly stated otherwise. However, the padding is pointless and
neither our "base32_encode" nor our "base32_decode" seem to implemnet
it.
I hope that we are using the same base32 encoding everywhere, but have
not checked.
These new names are the ones used in arti's hsdir_ring.rs and make a
lot more sense than calling one of them the "directory" index and
the other just the "index".
In C Tor these are calculated by functions called
hs_build_hs_index
hs_build_hsdir_index
That might be a reason *not* to accept this change. Or it might be a
reason to change the C Tor code.
If we don't change the names in the spec the Arti function names
should change.
