aboutsummaryrefslogtreecommitdiff
path: root/spec/rend-spec/shared-random.md
diff options
context:
space:
mode:
Diffstat (limited to 'spec/rend-spec/shared-random.md')
-rw-r--r--spec/rend-spec/shared-random.md49
1 files changed, 49 insertions, 0 deletions
diff --git a/spec/rend-spec/shared-random.md b/spec/rend-spec/shared-random.md
new file mode 100644
index 0000000..e6b2452
--- /dev/null
+++ b/spec/rend-spec/shared-random.md
@@ -0,0 +1,49 @@
+<a id="rend-spec-v3.txt-2.3"></a>
+
+# Publishing shared random values {#PUB-SHAREDRANDOM}
+
+Our design for limiting the predictability of HSDir upload locations
+relies on a shared random value (SRV) that isn't predictable in advance or
+too influenceable by an attacker. The authorities must run a protocol
+to generate such a value at least once per hsdir period. Here we
+describe how they publish these values; the procedure they use to
+generate them can change independently of the rest of this
+specification. For more information see \[SHAREDRANDOM-REFS\].
+
+According to proposal 250, we add two new lines in consensuses:
+
+```text
+ "shared-rand-previous-value" SP NUM_REVEALS SP VALUE NL
+ "shared-rand-current-value" SP NUM_REVEALS SP VALUE NL
+```
+
+<a id="rend-spec-v3.txt-2.3.1"></a>
+
+## Client behavior in the absence of shared random values {#client-disaster}
+
+If the previous or current shared random value cannot be found in a
+consensus, then Tor clients and services need to generate their own random
+value for use when choosing HSDirs.
+
+To do so, Tor clients and services use:
+
+SRV = H("shared-random-disaster" | INT_8(period_length) | INT_8(period_num))
+
+where period_length is the length of a time period in minutes,
+rounded down; period_num is calculated as specified in
+\[TIME-PERIODS\] for the wanted shared random value that could not be
+found originally.
+
+<a id="rend-spec-v3.txt-2.3.2"></a>
+
+## Hidden services and changing shared random values {#service-problems}
+
+It's theoretically possible that the consensus shared random values will
+change or disappear in the middle of a time period because of directory
+authorities dropping offline or misbehaving.
+
+To avoid client reachability issues in this rare event, hidden services
+should use the new shared random values to find the new responsible HSDirs
+and upload their descriptors there.
+
+XXX How long should they upload descriptors there for?