diff options
Diffstat (limited to 'spec/srv-spec')
| -rw-r--r-- | spec/srv-spec/discussion.md | 6 | ||||
| -rw-r--r-- | spec/srv-spec/overview.md | 12 | ||||
| -rw-r--r-- | spec/srv-spec/protocol.md | 20 | ||||
| -rw-r--r-- | spec/srv-spec/security-analysis.md | 10 | ||||
| -rw-r--r-- | spec/srv-spec/specification-spec.md | 14 |
5 files changed, 31 insertions, 31 deletions
diff --git a/spec/srv-spec/discussion.md b/spec/srv-spec/discussion.md index ea38318..59d26df 100644 --- a/spec/srv-spec/discussion.md +++ b/spec/srv-spec/discussion.md @@ -4,7 +4,7 @@ <a id="srv-spec.txt-6.1"></a> -## Why the added complexity from proposal 225? +## Why the added complexity from proposal 225? {#why-complexity} The complexity difference between this proposal and prop225 is in part because prop225 doesn't specify how the shared random value gets to the @@ -13,7 +13,7 @@ random values can always be readily accessible to clients. <a id="srv-spec.txt-6.2"></a> -## Why do you do a commit-and-reveal protocol in 24 rounds? +## Why do you do a commit-and-reveal protocol in 24 rounds? {#why-rounds} The reader might be wondering why we span the protocol over the course of a whole day (24 hours), when only 3 rounds would be sufficient to generate a @@ -32,7 +32,7 @@ recover and rejoin the protocol. <a id="srv-spec.txt-6.3"></a> -## Why can't we recover if the 00:00UTC consensus fails? +## Why can't we recover if the 00:00UTC consensus fails? {#why-no-recovery} If the 00:00UTC consensus fails, there will be no shared random value for the whole day. In theory, we could recover by calculating the shared diff --git a/spec/srv-spec/overview.md b/spec/srv-spec/overview.md index a9f4c99..b409e6c 100644 --- a/spec/srv-spec/overview.md +++ b/spec/srv-spec/overview.md @@ -12,7 +12,7 @@ in consensus documents so that clients who need it can get it. <a id="srv-spec.txt-2.1"></a> -## Introduction to our commit-and-reveal protocol +## Introduction to our commit-and-reveal protocol {#commit-and-reveal} Every day, before voting for the consensus at 00:00UTC each authority generates a new random value and keeps it for the whole day. The authority @@ -26,7 +26,7 @@ value. The construction of these values is specified in section \[COMMITREVEAL\] <a id="srv-spec.txt-2.1"></a> -## Ten thousand feet view of the protocol +## Ten thousand feet view of the protocol {#10000-feet} Our commit-and-reveal protocol aims to produce a fresh shared random value (denoted shared_random_value here and elsewhere) every day at 00:00UTC. The @@ -62,7 +62,7 @@ Commit phase: <a id="srv-spec.txt-2.3"></a> -## How we use the consensus \[CONS\] +## How we use the consensus {#CONS} The produced shared random values need to be readily available to clients. For this reason we include them in the consensus documents. @@ -86,7 +86,7 @@ authorities support this new protocol. <a id="srv-spec.txt-2.3.1"></a> -### Inserting Shared Random Values in the consensus +### Inserting Shared Random Values in the consensus {#inserting} After voting happens, we need to be careful on how we pick which shared random values (SRV) to put in the consensus, to avoid breaking the consensus @@ -124,7 +124,7 @@ reachability consequences for hidden service clients. <a id="srv-spec.txt-2.4"></a> -## Persistent State of the Protocol \[STATE\] +## Persistent State of the Protocol {#STATE} A directory authority needs to keep a persistent state on disk of the on going protocol run. This allows an authority to join the protocol seamlessly @@ -140,7 +140,7 @@ are available. <a id="srv-spec.txt-2.5"></a> -## Protocol Illustration +## Protocol Illustration {#illustration} An illustration for better understanding the protocol can be found here: diff --git a/spec/srv-spec/protocol.md b/spec/srv-spec/protocol.md index 683b65e..67aa493 100644 --- a/spec/srv-spec/protocol.md +++ b/spec/srv-spec/protocol.md @@ -10,7 +10,7 @@ Now we go through the phases of the protocol: <a id="srv-spec.txt-3.1"></a> -## Commitment Phase \[COMMITMENTPHASE\] +## Commitment Phase {#COMMITMENTPHASE} The commit phase lasts from 00:00UTC to 12:00UTC. @@ -23,7 +23,7 @@ included in Alice's vote. <a id="srv-spec.txt-3.1.1"></a> -### Voting During Commitment Phase +### Voting During Commitment Phase {#commitment-voting} During the commit phase, each authority includes in its votes: @@ -43,7 +43,7 @@ authorities. Any subsequent commitments MUST be ignored. <a id="srv-spec.txt-3.1.2"></a> -### Persistent State During Commitment Phase \[STATECOMMIT\] +### Persistent State During Commitment Phase {#STATECOMMIT} During the commitment phase, authorities save in their persistent state the authoritative commits they have received from each authority. Only one commit @@ -51,7 +51,7 @@ per authority must be considered trusted and active at a given time. <a id="srv-spec.txt-3.2"></a> -## Reveal Phase +## Reveal Phase {#reveal-phase} The reveal phase lasts from 12:00UTC to 00:00UTC. @@ -60,7 +60,7 @@ reveal their random values. <a id="srv-spec.txt-3.2.1"></a> -### Voting During Reveal Phase +### Voting During Reveal Phase {#reveal-voting} During the reveal phase, each authority includes in its votes: @@ -77,7 +77,7 @@ the new commitment MUST be ignored. <a id="srv-spec.txt-3.2.2"></a> -### Persistent State During Reveal Phase \[STATEREVEAL\] +### Persistent State During Reveal Phase {#STATEREVEAL} During the reveal phase, authorities keep the authoritative commits from the commit phase in their persistent state. They also save any received reveals @@ -90,7 +90,7 @@ its votes. <a id="srv-spec.txt-3.3"></a> -## Shared Random Value Calculation At 00:00UTC +## Shared Random Value Calculation At 00:00UTC {#midnight-utc} Finally, at 00:00UTC every day, authorities compute a fresh shared random value and this value must be added to the consensus so clients can use it. @@ -107,7 +107,7 @@ would in the first round of the commitment phase (section \[COMMITMENTPHASE\]). <a id="srv-spec.txt-3.3.1"></a> -### Shared Randomness Calculation \[SRCALC\] +### Shared Randomness Calculation {#SRCALC} An authority that wants to derive the shared random value SRV, should use the appropriate reveal values for that time period and calculate SRV as @@ -133,7 +133,7 @@ are ordered based on the R_a value in ascending order. <a id="srv-spec.txt-3.4"></a> -## Bootstrapping Procedure +## Bootstrapping Procedure {#bootstrapping} As described in \[CONS\], two shared random values are required for the HSDir overlay periods to work properly as specified in proposal 224. Hence @@ -144,7 +144,7 @@ produced, which takes 48 hours. <a id="srv-spec.txt-3.5"></a> -## Rebooting Directory Authorities \[REBOOT\] +## Rebooting Directory Authorities {#REBOOT} The shared randomness protocol must be able to support directory authorities who leave or join in the middle of the protocol execution. diff --git a/spec/srv-spec/security-analysis.md b/spec/srv-spec/security-analysis.md index a1cc72d..d3346f9 100644 --- a/spec/srv-spec/security-analysis.md +++ b/spec/srv-spec/security-analysis.md @@ -4,7 +4,7 @@ <a id="srv-spec.txt-5.1"></a> -## Security of commit-and-reveal and future directions +## Security of commit-and-reveal and future directions {#sec-commit-and-reveal} The security of commit-and-reveal protocols is well understood, and has certain flaws. Basically, the protocol is insecure to the extent that an @@ -28,7 +28,7 @@ also see the discussion at \[RNGMESSAGING\]. <a id="srv-spec.txt-5.2"></a> -## Predicting the shared random value during reveal phase +## Predicting the shared random value during reveal phase {#sec-predicting} The reveal phase lasts 12 hours, and most authorities will send their reveal value on the first round of the reveal phase. This means that an @@ -44,7 +44,7 @@ be aware of this property. <a id="srv-spec.txt-5.3"></a> -## Partition attacks +## Partition attacks {#sec-partition} This design is not immune to certain partition attacks. We believe they don't offer much gain to an attacker as they are very easy to detect and @@ -56,7 +56,7 @@ and how to detect them. <a id="srv-spec.txt-5.3.1"></a> -### Partition attacks during commit phase +### Partition attacks during commit phase {#sec-partition-commit} A malicious directory authority could send only its commit to one single authority which results in that authority having an extra commit value for @@ -74,7 +74,7 @@ so, this means an attack is ongoing or very bad bug (highly unlikely). <a id="srv-spec.txt-5.3.2"></a> -### Partition attacks during reveal phase +### Partition attacks during reveal phase {#sec-partition-reveal} Let's consider Alice, a malicious directory authority. Alice could wait until the last reveal round, and reveal its value to half of the diff --git a/spec/srv-spec/specification-spec.md b/spec/srv-spec/specification-spec.md index 63ffaff..8118f6d 100644 --- a/spec/srv-spec/specification-spec.md +++ b/spec/srv-spec/specification-spec.md @@ -1,6 +1,6 @@ <a id="srv-spec.txt-4"></a> -# Specification \[SPEC\] +# Specification {#spec} <a id="srv-spec.txt-4.1"></a> @@ -20,7 +20,7 @@ in their votes to announce that they take part in the protocol. <a id="srv-spec.txt-4.1.1"></a> -### Computing commitments and reveals \[COMMITREVEAL\] +### Computing commitments and reveals {#COMMITREVEAL} A directory authority that wants to participate in this protocol needs to create a new pair of commitment/reveal values for every protocol @@ -48,7 +48,7 @@ REVEAL = base64-encode( TIMESTAMP || H(RN) ) <a id="srv-spec.txt-4.1.2"></a> -### Validating commitments and reveals \[VALIDATEVALUES\] +### Validating commitments and reveals {#VALIDATEVALUES} Given a COMMIT message and a REVEAL message it should be possible to verify that they indeed correspond. To do so, the client extracts the random value @@ -64,7 +64,7 @@ correspond to commit values published during the Commitment Phase. <a id="srv-spec.txt-4.1.4"></a> -### Encoding commit/reveal values in votes \[COMMITVOTE\] +### Encoding commit/reveal values in votes {#COMMITVOTE} An authority puts in its vote the commitments and reveals it has produced and seen from the other authorities. To do so, it includes the following in its @@ -82,7 +82,7 @@ REVEAL which is "sha3-256" for version 1. <a id="srv-spec.txt-4.1.5"></a> -### Shared Random Value \[SRVOTE\] +### Shared Random Value {#SRVOTE} Authorities include a shared random value (SRV) in their votes using the following encoding for the previous and current value respectively: @@ -101,14 +101,14 @@ period should be listed before the values of the current period. <a id="srv-spec.txt-4.2"></a> -## Encoding Shared Random Values in the consensus \[SRCONSENSUS\] +## Encoding Shared Random Values in the consensus {#SRCONSENSUS} Authorities insert the two active shared random values in the consensus following the same encoding format as in \[SRVOTE\]. <a id="srv-spec.txt-4.3"></a> -## Persistent state format \[STATEFORMAT\] +## Persistent state format {#STATEFORMAT} As a way to keep ground truth state in this protocol, an authority MUST keep a persistent state of the protocol. The next sub-section suggest a |