nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-27 22:03:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

fix some typos in our spec files

Browse Source
This commit is contained in:
Roger Dingledine 2010-01-12 12:39:39 -05:00
parent 184e7aa792
commit 397f7c874f
2 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/spec/dir-spec.txt
View File

@ -1285,7 +1285,7 @@
selection. selection.
Additionally, the Measured= keyword is present in votes by Additionally, the Measured= keyword is present in votes by
participating bandwidth measurement authorites to indicate participating bandwidth measurement authorities to indicate
a measured bandwidth currently produced by measuring stream a measured bandwidth currently produced by measuring stream
capacities. capacities.
@ -1436,7 +1436,7 @@
by multiplying the previous published consensus bandwidth by the by multiplying the previous published consensus bandwidth by the
ratio of the measured average node stream capacity to the network ratio of the measured average node stream capacity to the network
average. If 3 or more authorities provide a Measured= keyword for average. If 3 or more authorities provide a Measured= keyword for
a router, the authorites produce a consensus containing a "w" a router, the authorities produce a consensus containing a "w"
Bandwidth= keyword equal to the median of the Measured= votes. Bandwidth= keyword equal to the median of the Measured= votes.
The ports listed in a "p" line should be taken as those ports for The ports listed in a "p" line should be taken as those ports for

20
doc/spec/tor-spec.txt
View File

@ -20,7 +20,7 @@ see tor-design.pdf.
PK -- a public key. PK -- a public key.
SK -- a private key. SK -- a private key.
K -- a key for a symmetric cypher. K -- a key for a symmetric cipher.
a|b -- concatenation of 'a' and 'b'. a|b -- concatenation of 'a' and 'b'.
@ -171,8 +171,8 @@ see tor-design.pdf.
In "renegotiation", the connection initiator sends no certificates, and In "renegotiation", the connection initiator sends no certificates, and
the responder sends a single connection certificate. Once the TLS the responder sends a single connection certificate. Once the TLS
handshake is complete, the initiator renegotiates the handshake, with each handshake is complete, the initiator renegotiates the handshake, with each
parties sending a two-certificate chain as in "certificates up-front". party sending a two-certificate chain as in "certificates up-front".
The initiator's ClientHello MUST include at least once ciphersuite not in The initiator's ClientHello MUST include at least one ciphersuite not in
the list above. The responder SHOULD NOT select any ciphersuite besides the list above. The responder SHOULD NOT select any ciphersuite besides
those in the list above. those in the list above.
[The above "should not" is because some of the ciphers that [The above "should not" is because some of the ciphers that
@ -200,9 +200,9 @@ see tor-design.pdf.
to decide which to use. to decide which to use.
In all of the above handshake variants, certificates sent in the clear In all of the above handshake variants, certificates sent in the clear
SHOULD NOT include any strings to identify the host as a Tor server. In SHOULD NOT include any strings to identify the host as a Tor server. In
the "renegotation" and "backwards-compatible renegotiation", the the "renegotiation" and "backwards-compatible renegotiation" steps, the
initiator SHOULD chose a list of ciphersuites and TLS extensions chosen initiator SHOULD choose a list of ciphersuites and TLS extensions
to mimic one used by a popular web browser. to mimic one used by a popular web browser.
Responders MUST NOT select any TLS ciphersuite that lacks ephemeral keys, Responders MUST NOT select any TLS ciphersuite that lacks ephemeral keys,
@ -288,7 +288,7 @@ see tor-design.pdf.
6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1) 6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1)
7 -- VERSIONS (Negotiate proto version) (See Sec 4) 7 -- VERSIONS (Negotiate proto version) (See Sec 4)
8 -- NETINFO (Time and address info) (See Sec 4) 8 -- NETINFO (Time and address info) (See Sec 4)
9 -- RELAY_EARLY (End-to-end data; limited) (See sec 5.6) 9 -- RELAY_EARLY (End-to-end data; limited)(See Sec 5.6)
The interpretation of 'Payload' depends on the type of the cell. The interpretation of 'Payload' depends on the type of the cell.
PADDING: Payload is unused. PADDING: Payload is unused.
@ -356,7 +356,7 @@ see tor-design.pdf.
The address format is a type/length/value sequence as given in section The address format is a type/length/value sequence as given in section
6.4 below. The timestamp is a big-endian unsigned integer number of 6.4 below. The timestamp is a big-endian unsigned integer number of
seconds since the unix epoch. seconds since the Unix epoch.
Implementations MAY use the timestamp value to help decide if their Implementations MAY use the timestamp value to help decide if their
clocks are skewed. Initiators MAY use "other OR's address" to help clocks are skewed. Initiators MAY use "other OR's address" to help
@ -398,7 +398,7 @@ see tor-design.pdf.
Onion skin [DH_LEN+KEY_LEN+PK_PAD_LEN bytes] Onion skin [DH_LEN+KEY_LEN+PK_PAD_LEN bytes]
Identity fingerprint [HASH_LEN bytes] Identity fingerprint [HASH_LEN bytes]
The port and address field denote the IPV4 address and port of the next The port and address field denote the IPv4 address and port of the next
onion router in the circuit; the public key hash is the hash of the PKCS#1 onion router in the circuit; the public key hash is the hash of the PKCS#1
ASN1 encoding of the next onion router's identity (signing) key. (See 0.3 ASN1 encoding of the next onion router's identity (signing) key. (See 0.3
above.) Including this hash allows the extending OR verify that it is above.) Including this hash allows the extending OR verify that it is
@ -885,7 +885,7 @@ see tor-design.pdf.
6.4. Remote hostname lookup 6.4. Remote hostname lookup
To find the address associated with a hostname, the OP sends a To find the address associated with a hostname, the OP sends a
RELAY_RESOLVE cell containing the hostname to be resolved with a nul RELAY_RESOLVE cell containing the hostname to be resolved with a NUL
terminating byte. (For a reverse lookup, the OP sends a RELAY_RESOLVE terminating byte. (For a reverse lookup, the OP sends a RELAY_RESOLVE
cell containing an in-addr.arpa address.) The OR replies with a cell containing an in-addr.arpa address.) The OR replies with a
RELAY_RESOLVED cell containing a status byte, and any number of RELAY_RESOLVED cell containing a status byte, and any number of