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

spelling fixes for proposals

Browse Source
This commit is contained in:
Sebastian Hahn 2009-05-30 03:15:54 +02:00
parent 4945fee65a
commit 169c019a60
4 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/spec/proposals/149-using-netinfo-data.txt
View File

@ -22,14 +22,14 @@ Motivation
idea of their own IP addresses, so they can publish correct idea of their own IP addresses, so they can publish correct
descriptors. This is also in NETINFO cells. descriptors. This is also in NETINFO cells.
Learning the time and IP Learning the time and IP address
We need to think about attackers here. Just because a router tells We need to think about attackers here. Just because a router tells
us that we have a given IP or a given clock skew doesn't mean that us that we have a given IP or a given clock skew doesn't mean that
it's true. We believe this information only if we've heard it from it's true. We believe this information only if we've heard it from
a majority of the routers we've connected to recently, including at a majority of the routers we've connected to recently, including at
least 3 routers. Routers only believe this information if the least 3 routers. Routers only believe this information if the
majority inclues at least one authority. majority includes at least one authority.
Avoiding MITM attacks Avoiding MITM attacks

8
doc/spec/proposals/158-microdescriptors.txt
View File

@ -58,8 +58,8 @@ Status: Open
A microdescriptor should in every case be a pure function of the A microdescriptor should in every case be a pure function of the
router descriptor and the conensus method. router descriptor and the conensus method.
In votes, need to include the hash of each expected microdescriptor in In votes, we need to include the hash of each expected microdescriptor
the routerstatus section. I suggest a new "m" line for each stanza, in the routerstatus section. I suggest a new "m" line for each stanza,
with the base64 of the SHA256 hash of the router's microdescriptor. with the base64 of the SHA256 hash of the router's microdescriptor.
For every consensus method that an authority supports, it includes a For every consensus method that an authority supports, it includes a
@ -84,7 +84,7 @@ Status: Open
3.1.2. Computing consensus for microdescriptor-elements and "m" lines 3.1.2. Computing consensus for microdescriptor-elements and "m" lines
When we generating a consensus, we use whichever m line When we are generating a consensus, we use whichever m line
unambiguously corresponds to the descriptor digest that will be unambiguously corresponds to the descriptor digest that will be
included in the consensus. (If there are multiple m lines for that included in the consensus. (If there are multiple m lines for that
descriptor digest, we use whichever is most common. If they are descriptor digest, we use whichever is most common. If they are
@ -103,7 +103,7 @@ Status: Open
This flavor can safely omit descriptor digests. This flavor can safely omit descriptor digests.
We still need to descide whether to move ports into microdescriptors We still need to decide whether to move ports into microdescriptors
or not. In either case, they can be removed from the current "ns" or not. In either case, they can be removed from the current "ns"
flavor of consensus, since no current clients use them, and they flavor of consensus, since no current clients use them, and they
take up about 5% of the compressed consensus. take up about 5% of the compressed consensus.

4
doc/spec/proposals/162-consensus-flavors.txt
View File

@ -37,7 +37,7 @@ Motivation:
Design in brief: Design in brief:
Let the voting process will remain as it is, until a consensus is Let the voting process remain as it is, until a consensus is
generated. With future versions of the voting algorithm, instead generated. With future versions of the voting algorithm, instead
of just a single consensus being generated, multiple consensus of just a single consensus being generated, multiple consensus
"flavors" are produced. "flavors" are produced.
@ -116,7 +116,7 @@ Spec modifications:
Signature = "directory-signature" SP algname SP identity Signature = "directory-signature" SP algname SP identity
SP signing-key-digest NL signature SP signing-key-digest NL signature
There must be one Document line for each generated consensus flavor There must be one Document line for each generated consensus flavor.
Each Document line describes the length of the signed portion of Each Document line describes the length of the signed portion of
a consensus (the signatures themselves are not included), along a consensus (the signatures themselves are not included), along
with one or more digests of that signed portion. Digests are with one or more digests of that signed portion. Digests are

6
doc/spec/proposals/165-simple-robust-voting.txt
View File

@ -51,14 +51,14 @@ Proposed protocol design:
A "Voting Set" is a set of authorities. Each authority has a list of A "Voting Set" is a set of authorities. Each authority has a list of
the voting sets it considers acceptable. These sets are chosen the voting sets it considers acceptable. These sets are chosen
manually by the authority operators. they must always contain the manually by the authority operators. They must always contain the
authority itself. Each authority lists all of these voting sets in authority itself. Each authority lists all of these voting sets in
its votes. its votes.
Authorities exchange votes with every other authority in any of their Authorities exchange votes with every other authority in any of their
voting sets. voting sets.
When it comes time to calculate a consensus, an authority votes with When it is time to calculate a consensus, an authority votes with
whichever voting set it lists that is listed by the most members of whichever voting set it lists that is listed by the most members of
that set. In other words, given two sets S1 and S2 that an authority that set. In other words, given two sets S1 and S2 that an authority
lists, that authority will prefer to vote with S1 over S2 whenever lists, that authority will prefer to vote with S1 over S2 whenever
@ -116,7 +116,7 @@ Data format changes:
implement the proposal), add this line to the consensus format as implement the proposal), add this line to the consensus format as
well, before the first dir-source line. [This information is not well, before the first dir-source line. [This information is not
redundant with the dir-source sections in the consensus: If an redundant with the dir-source sections in the consensus: If an
authority is recognized didn't vote, that authority will appear in authority is recognized but didn't vote, that authority will appear in
the voting-set line but not in the dir-source sections.] the voting-set line but not in the dir-source sections.]
We don't need to list other information about authorities in our We don't need to list other information about authorities in our