| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
This commit implements a pseudocode example for the digest in both:
encryption and decryption cases.
The pseudocode itself is a combination of Python code and the Rust
slice type.
Fixes #205
|
|
I UTSL C-tor and it memsets the thing to zero and then fails to write
these timeout fields.
We should recommend that other implementations do the same.
|
|
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.
|
|
tor-spec: inform about RELAY_EARLY in EXTEND(2)
See merge request tpo/core/torspec!135
|
|
|
|
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.
|
|
|
|
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 removes the redundant MULT(a, b) function from the ntor
section, as the function is defined but never used.
|
|
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.
|
|
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 names are slightly shorter and a bit more descriptive IMO, and
now (when they are still fresh) is the best time to rename these
keys.
`hs_intro_tid` becomes `hs_ipt_sid`: It is a _session identifier_
key used with an _introduction point_. Using `ipt` here emphasizes
that it is not part of the introduction _handshake_.
`hs_intro_ntor` becomes `hss_ntor`. The extra "s" means it is owned
by the service. Renaming "intro" here removes the implication that
it is held by or used by the introduction point.
`onion_ntor` becomes `ntor`: There is no such thing as an ntor key
that is not an onion key.
|
|
|
|
Emacs's idea of s/\bPK\b/KP/
|
|
|
|
|
|
As per review comments
|
|
|
|
Even the ones that are actually ntor. Perhaps that's wrong and those
should be ntor? Personally I like it this way.
|
|
In particular, give these formal names which contain "hs" (since they
are part of the hidden service protocol, and not any other kind of
authentication or authorisation scheme), and "N" to indicate that they
are hash-generated nonces, not passwords.
Change the references in the formulae, which it really seems to me
ought to refer to the formal names.
|
|
|
|
|
|
|
|
|
|
This commit fixes an ambitious formulation within the definition of the
VERSIONS cells. It says, that a VERSIONS cell with an odd number of
bytes is invalid. This statement is not true, because the CircID (2
bytes for VERSIONS cells), Command (1 byte) and Length (2 byte) make up
5 bytes, which is an odd number. Adding an odd number to an even number
of bytes (the payload in this case) always results in an odd number.
|
|
As per review from nickm in
https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/95
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Series of change after discussin with mikeperry the proposal in depth.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
This commit inserts a line break in order to fix the only line exceeding
80 characters in this document.
|
|
In addition, this commit also changes the spec so no destroy reasons
(error code) are propagated down or up the circuit in order to mitigate
potential side channel risks.
See https://gitlab.torproject.org/tpo/core/tor/-/issues/40649 for more
details on why.
Related to tor/#40623
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
As far as I can tell, we had not previously said that 43 was "XON"
and 44 was "XOFF".
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
See proposal 332 for more details.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Relays started advertising Relay=3 in 0.4.5.1-alpha, see core/tor commit
e787e521af9.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
(hopefully i picked the right fix :)
|
|
|
|
|
|
|
|
|
|
|
