[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Patch to improve time-period interval changes in 224-rend-spec-ng.txt
Hello all,
I have a patch for proposal 224-rend-spec-ng.txt that clarifies the
definition of time periods and improves the behaviour when the time
period duration needs to be changed.
-Adrien Johnson
From b4dee3bdd7143929d2f3ef0ee1a1c9a4e13d5bad Mon Sep 17 00:00:00 2001
From: Adrien Johnson <adrienj@xxxxxxxxxxx>
Date: Sat, 7 Mar 2015 13:16:48 -0500
Subject: [PATCH] Added offset to time period calc. in prop224
---
proposals/224-rend-spec-ng.txt | 63 ++++++++++++++++++++++++++++++++----------
1 file changed, 48 insertions(+), 15 deletions(-)
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index ffef617..391b2f1 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -615,25 +615,58 @@ Status: Draft
2.2.1. Dividing time into periods [TIME-PERIODS]
- To prevent a single set of hidden service directory from becoming a
+ To prevent a single set of hidden service directories from becoming a
target by adversaries looking to permanently censor a hidden service,
hidden service descriptors are uploaded to different locations that
change over time.
- The length of a "time period" is controlled by the consensus
- parameter 'hsdir-interval', and is a number of minutes between 30 and
- 14400 (10 days). The default time period length is 1500 (one day plus
- one hour).
-
- Time periods start with the Unix epoch (Jan 1, 1970), and are
- computed by taking the number of whole minutes since the epoch and
- dividing by the time period. So if the current time is 2013-11-12
- 13:44:32 UTC, making the seconds since the epoch 1384281872, the
- number of minutes since the epoch is 23071364. If the current time
- period length is 1500 (the default), then the current time period
- number is 15380. It began 15380*1500*60 seconds after the epoch at
- 2013-11-11 20:00:00 UTC, and will end at (15380+1)*1500*60 seconds
- after the epoch at 2013-11-12 21:00:00 UTC.
+ Time is divided into infinitely many discrete "time periods" of
+ identical duration. Each time period is sequentially numbered according
+ to how many whole periods have elapsed since the Unix epoch
+ (1970-1-1 00:00:00 UTC) at the start of that period, plus an offset.
+ The time between the Unix epoch and the start of any time period is
+ evenly divisible by the time period duration.
+
+ current_period = floor((current_time - unix_epoch) / duration) + offset
+
+ Time period duration is controlled by the consensus parameter
+ 'hsdir-interval', which is a number of minutes between 30 and
+ 14400 (10 days). The default time period duration is 1500 (one day plus
+ one hour). The time period numbering offset is controlled by the
+ consensus parameter 'hsdir-offset' which is a signed 32 bit integer.
+ The default numbering offset is 0.
+
+ For example if the current time is 2013-11-14 13:44:32 UTC, and the
+ current time period duration is 1500 minutes (the default), then the
+ number of whole periods that have elapsed since the Unix epoch is
+ 15382. If the current numbering offset is 5, then the current period
+ is 15387. Period 15387 began (15387-5)*1500*60 seconds after the epoch
+ at 2013-11-13 20:00:00 UTC, and will end (15387+1-5)*1500*60 seconds
+ after the epoch at 2013-11-14 21:00:00 UTC.
+
+ When a new time period duration is needed, a new numbering offset is
+ also chosen such that on the expected date consensus is reached on the
+ new values, the then-current time period number will remain the same.
+ This prevents changes to the time period duration from invalidating the
+ current keys and descriptors for all hidden services.
+
+ [NOTE: Depending on how accurately the consensus date can be predicted,
+ this may still be a problem, and it will get worse the further away we
+ are from the epoch. This could be improved by choosing a different epoch
+ closer to the present, or even one in the future.
+
+ An even more robust fix would be to have the epoch date set by a
+ third consensus parameter. This could be changed without altering the
+ progression of period numbers by also giving a new offset. In advance
+ of an expected need for a new duration, a new epoch date could be set
+ in the immediate future and a new offset given. Once consensus is
+ reached on this new epoch date, a new duration and offset are given,
+ timed so that consensus will be reached as close as possible to the
+ epoch date. This would almost guarantee monotonically increasing time
+ period numbers, even across very large duration changes. This assumes
+ consensus parameter value updates are atomic, i.e. if new consensus
+ parameter values are given in a single Tor update, consensus will be
+ reached on all the new values at the same time.]
2.2.2. Overlapping time periods to avoid thundering herds [TIME-OVERLAP]
--
1.9.5.msysgit.0
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev