| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
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 :)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Originally designed in tor#25573 as part of a defense for the
DropMark attack by Rochet and Pereira.
Closes torspec#33.
|
|
For indistinguishability, other implementations should pad the same
way that we do.
|
|
Right now, tor encodes them in a certain order; specifying that
order can help other implementations be indistinguishable.
|
|
|
|
|
|
|
|
|
|
OR_CONN_CLOSED has been CHANNEL_CLOSED since 0.2.4.4-alpha.
|
|
With minor edits from the draft in proposal 311.
Closes ticket 33227.
|
