torproject/torspec
1
0
Fork 0
mirror of https://github.com/torproject/torspec.git synced 2024-11-23 01:39:44 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix typos and cleanup

Browse Source
This commit is contained in:
Dimitris Apostolou 2021-10-25 23:03:20 +03:00 committed by Nick Mathewson
parent c10dd31c0d
commit 29245fd50d
14 changed files with 45 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -6,7 +6,7 @@ the reader to implement a compatible implementation of Tor without ever
having to read the Tor source code.
The [proposals](/proposals) directory holds our design proposals. These
include historical documents that have now been merged into . For more
include historical documents that have now been merged into. For more
information on the proposal process, including an explanation of how to
make new proposals, see, see
[001-process.txt](/proposals/001-process.txt).

2
bandwidth-file-spec.txt
View File

@ -1161,7 +1161,7 @@ B.1. Scaling requirements
B.2. A linear scaling method
If scaling is required, here is a simple linear bandwith scaling
If scaling is required, here is a simple linear bandwidth scaling
method, which ensures that all bandwidth votes contain approximately
the same total bandwidth:

2
bridgedb-spec.txt
View File

@ -94,7 +94,7 @@ Table of Contents
in the bridge network status parsed earlier or if the bridge does not
have the Running flag.
BridgeDB discards bridge descriptors which have a different purpose
than "bridge". BridgeDB can be configured to only accept descriptors
than "bridge". BridgeDB can be configured to only accept descriptors
with another purpose or not discard descriptors based on purpose at
all.
BridgeDB memorizes the IP addresses and OR ports of the remaining

6
control-spec.txt
View File

@ -1023,7 +1023,7 @@ Table of Contents
"net/listeners/dir"
Listeners for Tor directory protocol, as decribed in dir-spec.txt.
Listeners for Tor directory protocol, as described in dir-spec.txt.
"net/listeners/socks"
@ -2699,7 +2699,7 @@ Table of Contents
[NOTE: This feature was removed in Tor 0.3.2.1-alpha.]
Tor generates this event when it's an directory authority, and
Tor generates this event when it's a directory authority, and
somebody has just uploaded a server descriptor.
Syntax:
@ -3736,7 +3736,7 @@ Table of Contents
Program = The program path as defined in the *TransportPlugin
configuration option. Tor accepts relative and full path.
Transport = This value indicate a hint on what the PT is such as the
Transport = This value indicates a hint on what the PT is such as the
name or the protocol used for instance.
Message = The status message that the PT sends back to the tor parent
process minus the "STATUS" string prefix. Formatted as

4
dir-list-spec.txt
View File

@ -358,7 +358,7 @@ Table of Contents
recent Tor versions.
weight was removed in version 2.0.0, but is documented because it
may be of interest to libraries implementing Tor's fallaback
may be of interest to libraries implementing Tor's fallback
behaviour.
DQUOTE SP+ key_value DQUOTE SP* NL
@ -457,7 +457,7 @@ Table of Contents
Libraries SHOULD consider the potential load on the authorities, and
whether other sources can meet their needs.
Libraries that require high-uptime availablility of Tor directory
Libraries that require high-uptime availability of Tor directory
information should investigate the following options:
* OnionOO: https://metrics.torproject.org/onionoo.html

2
dos-spec.md
View File

@ -46,7 +46,7 @@ kinds of allocation:
* Half-open stream records.
* Cached onion service descriptors (hsdir only).
* Cached DNS resolves (relay only).
* GEOIP-based usage activity statistics.
* GEOIP-based usage activity statistics.
Note that directory caches aren't counted, since those are stored on
disk and accessed via mmap.

6
ext-orport-spec.txt
View File

@ -63,14 +63,14 @@ Table of Contents
We define one authentication type: SAFE_COOKIE. Its AuthType
value is 1. It is based on the client proving to the bridge that
it can access a given "cookie" file on disk. The purpose of
it can access a given "cookie" file on disk. The purpose of
authentication is to defend against cross-protocol attacks.
If the Extended ORPort is enabled, Tor should regenerate the cookie
file on startup and store it in
$DataDirectory/extended_orport_auth_cookie.
The location of the cookie can be overriden by using the
The location of the cookie can be overridden by using the
configuration file parameter ExtORPortCookieAuthFile, which is
defined as:
@ -139,7 +139,7 @@ Table of Contents
Status [1 octet]
Where,
+ Status is 1 if the authentication was successfull. If the
+ Status is 1 if the authentication was successful. If the
authentication failed, Status is 0.
3. The extended ORPort protocol

2
guard-spec.txt
View File

@ -429,7 +429,7 @@ Table of Contents
That is: if a non-primary guard becomes confirmed and not every primary
guard is confirmed, then the list of primary guards list is regenerated,
first from the confirmed guards (as before), and then from any
non-confirmed primary guards guards.
non-confirmed primary guards.
Note that {PRIMARY_GUARDS} do not have to be in
{USABLE_FILTERED_GUARDS}: they might be unreachable.

6
param-spec.txt
View File

@ -83,7 +83,7 @@ Table of Contents
"perconnbwrate" and "perconnbwburst" -- if set, each relay sets up a
separate token bucket for every client OR connection, and rate limits
that connection indepedently. Typically left unset, except when used for
that connection independently. Typically left unset, except when used for
performance experiments around trac entry 1750. Only honored by relays
running Tor 0.2.2.16-alpha and later. (Note that relays running
0.2.2.7-alpha through 0.2.2.14-alpha looked for bwconnrate and
@ -324,7 +324,7 @@ Table of Contents
Min: 0. Max: 1. Default: 0.
First appeared: 0.2.6
"guard-lifetime-days" -- Controls guard lifetime. If a unconfirmed
"guard-lifetime-days" -- Controls guard lifetime. If an unconfirmed
guard has been sampled more than this many days ago, it should be
removed from the guard sample.
Min: 1. Max: 3650. Default: 120.
@ -395,7 +395,7 @@ Table of Contents
Min: 1. Max: INT32_MAX. Default: 15
First appeared: 0.3.0
"guard-nonprimary-guard-idle-timeout" -- When trying to confirm
"guard-nonprimary-guard-idle-timeout" -- When trying to confirm
nonprimary guards, if a guard doesn't answer for more than this long
in seconds, treat it as down.
Min: 1. Max: INT32_MAX. Default: 600

8
path-spec.txt
View File

@ -192,7 +192,7 @@ Tables of Contents
* The fraction of descriptors that we have for nodes with the Guard
flag, weighted by their bandwidth for the guard position.
* The fraction of descriptors that we have for all nodes,
weighted by their bandwidth for the middle position position.
weighted by their bandwidth for the middle position.
* The fraction of descriptors that we have for nodes with the Exit
flag, weighted by their bandwidth for the exit position.
@ -491,7 +491,7 @@ Tables of Contents
used directly as Xm.
Instead of using the mode of discrete build times directly, Tor clients
compute the Xm parameter using the weighted average of the the midpoints
compute the Xm parameter using the weighted average of the midpoints
of the 'cbtnummodes' (10) most frequently occurring 10ms histogram bins.
Ties are broken in favor of earlier bins (that is, in favor of bins
corresponding to shorter build times).
@ -511,7 +511,7 @@ Tables of Contents
All times below Xm are counted as having the Xm value via the MAX(),
because in Pareto estimators, Xm is supposed to be the lowest value.
However, since clients use mode averaging to estimatre Xm, there can be
However, since clients use mode averaging to estimate Xm, there can be
values below our Xm. Effectively, the Pareto estimator then treats that
everything smaller than Xm happened at Xm. One can also see that if
clients did not do this, alpha could underflow to become negative, which
@ -577,7 +577,7 @@ Tables of Contents
to the point 'cbtclosequantile' (default 99) on the Pareto curve, or 60
seconds, whichever is greater.
The actual completion times for these measurements circuits should be
The actual completion times for these measurement circuits should be
recorded.
Implementations should completely abandon a circuit and ignore the circuit

8
pt-spec.txt
View File

@ -452,7 +452,7 @@ Table of Contents
The "VERSION" message is used to signal the Pluggable Transport
Specification version (as in "TOR_PT_MANAGED_TRANSPORT_VER")
that the PT proxy will use to configure it's transports and
that the PT proxy will use to configure its transports and
communicate with the parent process.
The version for the environment values and reply messages
@ -644,7 +644,7 @@ Table of Contents
For example, the tor daemon logs those messages at the Severity level and
sends them onto the control port using the PT_LOG (see control-spec.txt)
event so any third part can pick them up for debugging.
event so any third party can pick them up for debugging.
The format of the message:
@ -670,7 +670,7 @@ Table of Contents
STATUS TRANSPORT=Transport <K_1>=<V_1> [<K_2>=<V_2>, ...]
The TRANSPORT value indicate a hint on what the PT is such has the name or
The TRANSPORT value indicates a hint on what the PT is such has the name or
the protocol used for instance. As an example, obfs4proxy would use
"obfs4". Thus, the Transport value can be anything the PT itself defines
and it can be a String or CString (see section 2 in control-spec.txt).
@ -711,7 +711,7 @@ Table of Contents
causes cleanup and a graceful shutdown if able).
- PT proxies SHOULD attempt to detect when the parent has
terminated (eg: via detecting that it's parent process ID haso
terminated (eg: via detecting that its parent process ID has
changed on U*IX systems), and gracefully terminate.
3.5. Pluggable Transport Client Per-Connection Arguments

24
rend-spec-v3.txt
View File

@ -35,7 +35,7 @@ Table of contents:
2.2.5. Expiring hidden service descriptors [EXPIRE-DESC]
2.2.6. URLs for anonymous uploading and downloading
2.3. Publishing shared random values [PUB-SHAREDRANDOM]
2.3.1. Client behavior in the absense of shared random values
2.3.1. Client behavior in the absence of shared random values
2.3.2. Hidden services and changing shared random values
2.4. Hidden service descriptors: outer wrapper [DESC-OUTER]
2.5. Hidden service descriptors: encryption format [HS-DESC-ENC]
@ -457,7 +457,7 @@ Table of contents:
To learn the introduction points, clients must decrypt the body of the
hidden service descriptor. To do so, clients must know the _unblinded_
public key of the service, which makes the descriptor unuseable by entities
public key of the service, which makes the descriptor unusable by entities
without that knowledge (e.g. HSDirs that don't know the onion address).
Also, if optional client authorization is enabled, hidden service
@ -626,7 +626,7 @@ Table of contents:
1.9.1. In even more detail: Client authorization keys [CLIENT-AUTH]
When client authorization is enabled, each authorized client of a hidden
service has two more assymetric keypairs which are shared with the hidden
service has two more asymmetric keypairs which are shared with the hidden
service. An entity without those keys is not able to use the hidden
service. Throughout this document, we assume that these pre-shared keys are
exchanged between the hidden service and its clients in a secure out-of-band
@ -746,7 +746,7 @@ Table of contents:
HSDirs. The set of responsible HSDirs is determined as specified in
[WHERE-HSDESC].
Specifically, everytime a hidden service publishes its descriptor, it also
Specifically, every time a hidden service publishes its descriptor, it also
sets up a timer for a random time between 60 minutes and 120 minutes in the
future. When the timer triggers, the hidden service needs to publish its
descriptor again to the responsible HSDirs for that time period.
@ -831,7 +831,7 @@ Table of contents:
2.2.4. Using time periods and SRVs to fetch/upload HS descriptors [FETCHUPLOADDESC]
Hidden services and clients need to make correct use of time periods (TP)
and shared random values (SRVs) to successfuly fetch and upload
and shared random values (SRVs) to successfully fetch and upload
descriptors. Furthermore, to avoid problems with skewed clocks, both clients
and services use the 'valid-after' time of a live consensus as a way to take
decisions with regards to uploading and fetching descriptors. By using the
@ -894,7 +894,7 @@ Table of contents:
As discussed above, services maintain two active descriptors at any time. We
call these the "first" and "second" service descriptors. Services rotate
their descriptor everytime they receive a consensus with a valid_after time
their descriptor every time they receive a consensus with a valid_after time
past the next SRV calculation time. They rotate their descriptors by
discarding their first descriptor, pushing the second descriptor to the
first, and rebuilding their second descriptor with the latest data.
@ -1008,7 +1008,7 @@ Table of contents:
with a torsion component).
The right way for clients to detect such fraudulent addresses (which should
only occur malevolently and never natutally) is to extract the ed25519
only occur malevolently and never naturally) is to extract the ed25519
public key from the onion address and multiply it by the ed25519 group order
and ensure that the result is the ed25519 identity element. For more
details, please see [TORSION-REFS].
@ -1028,7 +1028,7 @@ Table of contents:
"shared-rand-previous-value" SP NUM_REVEALS SP VALUE NL
"shared-rand-current-value" SP NUM_REVEALS SP VALUE NL
2.3.1. Client behavior in the absense of shared random values
2.3.1. Client behavior in the absence of shared random values
If the previous or current shared random value cannot be found in a
consensus, then Tor clients and services need to generate their own random
@ -1424,7 +1424,7 @@ Table of contents:
MUST be present if "legacy-key" is present.
The certificate is a proposal 220 RSA->Ed cross-certificate wrapped
in "-----BEGIN CROSSCERT-----" armor, cross-certifying the the RSA
in "-----BEGIN CROSSCERT-----" armor, cross-certifying the RSA
public key found in "legacy-key" using the descriptor signing key.
To remain compatible with future revisions to the descriptor format,
@ -1433,7 +1433,7 @@ Table of contents:
should ignore ones they do not recognize.
Clients who manage to extract the introduction points of the hidden service
can prroceed with the introduction protocol as specified in [INTRO-PROTOCOL].
can proceed with the introduction protocol as specified in [INTRO-PROTOCOL].
2.5.3. Deriving hidden service descriptor encryption keys [HS-DESC-ENCRYPTION-KEYS]
@ -1448,7 +1448,7 @@ Table of contents:
Here is the key generation logic:
SALT = 16 bytes from H(random), changes each time we rebuld the
SALT = 16 bytes from H(random), changes each time we rebuild the
descriptor even if the content of the descriptor hasn't changed.
(So that we don't leak whether the intro point list etc. changed)
@ -1615,7 +1615,7 @@ Table of contents:
The burst per second of INTRODUCE2 cell relayed to the
service.
The PARAM_VALUE size is 8 bytes in order to accomodate 64bit values.
The PARAM_VALUE size is 8 bytes in order to accommodate 64bit values.
It MUST match the specified limit for the following PARAM_TYPE:
[01] -- Min: 0, Max: 2147483647

12
srv-spec.txt
View File

@ -98,7 +98,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt.
2.1. Ten thousand feet view of the protocol
Our commit-and-reveal protocol aims to produce a fresh shared random value
everyday at 00:00UTC. The final fresh random value is embedded in the
every day at 00:00UTC. The final fresh random value is embedded in the
consensus document at that time.
Our protocol has two phases and uses the hourly voting procedure of Tor.
@ -124,11 +124,11 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt.
At 00:00UTC, the shared random value is computed from the agreed
revealed values and added to the consensus.
This concludes the commit-and-reveal protocol at 00:00UTC everyday.
This concludes the commit-and-reveal protocol every day at 00:00UTC.
2.3. How we use the consensus [CONS]
The produced shared random values needs to be readily available to
The produced shared random values need to be readily available to
clients. For this reason we include them in the consensus documents.
Every hour the consensus documents need to include the shared random value
@ -403,7 +403,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt.
from the COMMIT message. We say that the COMMIT and REVEAL messages
correspond, if the comparison was successful.
Pariticipants MUST also check that corresponding COMMIT and REVEAL values
Participants MUST also check that corresponding COMMIT and REVEAL values
have the same timestamp value.
Authorities should ignore reveal values during the Reveal Phase that don't
@ -578,7 +578,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt.
different shared randomness value than the others.
We claim that this attack is not particularly fruitful: Alice ends up
having two shared random values to chose from which is a fundamental
having two shared random values to choose from which is a fundamental
problem of commit-and-reveal protocols as well (since the last person can
always abort or reveal). The attacker can also sabotage the consensus, but
there are other ways this can be done with the current voting system.
@ -587,7 +587,7 @@ Tor works. This text used to be proposal 250-commit-reveal-consensus.txt.
First of all, it requires the authority to sabotage two consensuses which
will cause quite some noise. Furthermore, the authority needs to send
different votes to different auths which is detectable. Like the commit
phase attack, the detection here is to make sure that the commiment values
phase attack, the detection here is to make sure that the commitment values
in a vote coming from an authority are always the same for each authority.
6. Discussion

6
tor-spec.txt
View File

@ -944,12 +944,12 @@ see tor-design.pdf.
TIME (Timestamp) [4 bytes]
OTHERADDR (Other OR's address) [variable]
ATYPE (Address type) [1 byte]
ALEN (Adress length) [1 byte]
ALEN (Address length) [1 byte]
AVAL (Address value in NBO) [ALEN bytes]
NMYADDR (Number of this OR's addresses) [1 byte]
NMYADDR times:
ATYPE (Address type) [1 byte]
ALEN (Adress length) [1 byte]
ALEN (Address length) [1 byte]
AVAL (Address value in NBO)) [ALEN bytes]
Recognized address types (ATYPE) are:
@ -1849,7 +1849,7 @@ see tor-design.pdf.
and relays MUST ignore the payload.
In response to a RELAY_BEGIN_DIR cell, relays respond either with a
RELAY_CONNECTED cell on succcess, or a RELAY_END cell on failure. They
RELAY_CONNECTED cell on success, or a RELAY_END cell on failure. They
MUST send a RELAY_CONNECTED cell all-zero payload, and clients MUST ignore
the payload.