diff options
Diffstat (limited to 'spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md')
| -rw-r--r-- | spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md | 17 |
1 files changed, 15 insertions, 2 deletions
diff --git a/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md b/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md index b98f1ae..2a1cb72 100644 --- a/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md +++ b/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-2.1"></a> + ## Deriving blinded keys and subcredentials [SUBCRED] In each time period (see [TIME-PERIODS] for a definition of time @@ -56,6 +57,7 @@ Which Tor servers hosts a hidden service depends on: ``` <a id="rend-spec-v3.txt-2.2.1"></a> + ### Dividing time into periods [TIME-PERIODS] To prevent a single set of hidden service directory from becoming a @@ -87,6 +89,7 @@ after the epoch, at 2016-04-12 12:00 UTC, and ended at 16904*1440*60 + (12*60*60) seconds after the epoch, at 2016-04-13 12:00 UTC. <a id="rend-spec-v3.txt-2.2.2"></a> + ### When to publish a hidden service descriptor [WHEN-HSDESC] Hidden services periodically publish their descriptor to the responsible @@ -100,11 +103,12 @@ descriptor again to the responsible HSDirs for that time period. [TODO: Control republish period using a consensus parameter?] <a id="rend-spec-v3.txt-2.2.2.1"></a> + #### Overlapping descriptors Hidden services need to upload multiple descriptors so that they can be reachable to clients with older or newer consensuses than them. Services -need to upload their descriptors to the HSDirs _before_ the beginning of +need to upload their descriptors to the HSDirs *before* the beginning of each upcoming time period, so that they are readily available for clients to fetch them. Furthermore, services should keep uploading their old descriptor even after the end of a time period, so that they can be reachable by @@ -120,6 +124,7 @@ achieved. [TODO: What to do when we run multiple hidden services in a single host?] <a id="rend-spec-v3.txt-2.2.3"></a> + ### Where to publish a hidden service descriptor [WHERE-HSDESC] This section specifies how the HSDir hash ring is formed at any given @@ -184,6 +189,7 @@ Again, nodes from lower-numbered replicas are disregarded when choosing the spread for a replica. <a id="rend-spec-v3.txt-2.2.4"></a> + ### Using time periods and SRVs to fetch/upload HS descriptors [FETCHUPLOADDESC] Hidden services and clients need to make correct use of time periods (TP) @@ -221,6 +227,7 @@ Let's start with an illustration of the system: ``` <a id="rend-spec-v3.txt-2.2.4.1"></a> + #### Client behavior for fetching descriptors [CLIENTFETCH] And here is how clients use TPs and SRVs to fetch descriptors: @@ -250,6 +257,7 @@ SRV#1 for fetching descriptors. Also, if a client (C2) is at 01:00 right after SRV#2, it will still use TP#1 and SRV#1. <a id="rend-spec-v3.txt-2.2.4.2"></a> + #### Service behavior for uploading descriptors [SERVICEUPLOAD] As discussed above, services maintain two active descriptors at any time. We @@ -263,6 +271,7 @@ Services like clients also employ a different logic for picking SRV and TP values based on their position in the graph above. Here is the logic: <a id="rend-spec-v3.txt-2.2.4.2.1"></a> + ##### First descriptor upload logic [FIRSTDESCUPLOAD] Here is the service logic for uploading its first descriptor: @@ -298,6 +307,7 @@ Consider that the service is at 01:00 right after SRV#2: it will upload its first descriptor using TP#1 and SRV#1. <a id="rend-spec-v3.txt-2.2.4.2.2"></a> + ##### Second descriptor upload logic [SECONDDESCUPLOAD] Here is the service logic for uploading its second descriptor: @@ -331,6 +341,7 @@ Consider that the service is at 01:00 right after SRV#2: it will upload its second descriptor using TP#2 and SRV#2. <a id="rend-spec-v3.txt-2.2.4.3"></a> + #### Directory behavior for handling descriptor uploads [DIRUPLOAD] Upon receiving a hidden service descriptor publish request, directories MUST @@ -356,6 +367,7 @@ service (required for decrypting the first layer of encryption), or the necessary client credentials (for decrypting the second layer). <a id="rend-spec-v3.txt-2.2.5"></a> + ### Expiring hidden service descriptors [EXPIRE-DESC] Hidden services set their descriptor's "descriptor-lifetime" field to 180 @@ -368,6 +380,7 @@ as descriptors including those intro points are valid (even if that's after the time period has changed). <a id="rend-spec-v3.txt-2.2.6"></a> + ### URLs for anonymous uploading and downloading Hidden service descriptors conforming to this specification are uploaded @@ -381,6 +394,7 @@ These requests must be made anonymously, on circuits not used for anything else. <a id="rend-spec-v3.txt-2.2.7"></a> + ### Client-side validation of onion addresses When a Tor client receives a prop224 onion address from the user, it @@ -402,4 +416,3 @@ only occur malevolently and never naturally) is to extract the ed25519 public key from the onion address and multiply it by the ed25519 group order and ensure that the result is the ed25519 identity element. For more details, please see [TORSION-REFS]. - |