From b4dee3bdd7143929d2f3ef0ee1a1c9a4e13d5bad Mon Sep 17 00:00:00 2001 From: Adrien Johnson 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