diff options
| author | Dimitris Apostolou <dimitris.apostolou@icloud.com> | 2021-10-25 23:03:20 +0300 |
|---|---|---|
| committer | Nick Mathewson <nickm@torproject.org> | 2021-10-25 16:35:13 -0400 |
| commit | 29245fd50d1ee3d96cca52154da4d888f34fedea (patch) | |
| tree | e15e67dcf9ba6c6beb0d3681e1db5ea0de0b6e8b /srv-spec.txt | |
| parent | c10dd31c0dcf970b8e199e029d56fc483f8a216c (diff) | |
| download | torspec-29245fd50d1ee3d96cca52154da4d888f34fedea.tar.gz torspec-29245fd50d1ee3d96cca52154da4d888f34fedea.zip | |
Fix typos and cleanup
Diffstat (limited to 'srv-spec.txt')
| -rw-r--r-- | srv-spec.txt | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/srv-spec.txt b/srv-spec.txt index a8bb878..a68ef3e 100644 --- a/srv-spec.txt +++ b/srv-spec.txt @@ -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 |