nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-24 12:23:32 +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
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
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
a majority of the routers we've connected to recently, including at
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

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
router descriptor and the conensus method.
In votes, need to include the hash of each expected microdescriptor in
the routerstatus section. I suggest a new "m" line for each stanza,
In votes, we need to include the hash of each expected microdescriptor
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.
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
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
included in the consensus. (If there are multiple m lines for that
descriptor digest, we use whichever is most common. If they are
@ -103,7 +103,7 @@ Status: Open
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"
flavor of consensus, since no current clients use them, and they
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:
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
of just a single consensus being generated, multiple consensus
"flavors" are produced.
@ -116,7 +116,7 @@ Spec modifications:
Signature = "directory-signature" SP algname SP identity
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
a consensus (the signatures themselves are not included), along
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
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
its votes.
Authorities exchange votes with every other authority in any of their
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
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
@ -116,7 +116,7 @@ Data format changes:
implement the proposal), add this line to the consensus format as
well, before the first dir-source line. [This information is not
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.]
We don't need to list other information about authorities in our