diff options
Diffstat (limited to 'spec/rend-spec-v3')
21 files changed, 87 insertions, 30 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]. - diff --git a/spec/rend-spec-v3/encoding-onion-addresses-onionaddress.md b/spec/rend-spec-v3/encoding-onion-addresses-onionaddress.md index 674f584..7919b73 100644 --- a/spec/rend-spec-v3/encoding-onion-addresses-onionaddress.md +++ b/spec/rend-spec-v3/encoding-onion-addresses-onionaddress.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-6"></a> + # Encoding onion addresses [ONIONADDRESS] The onion address of a hidden service includes its identity public key, a @@ -24,4 +25,3 @@ encoded as shown below: For more information about this encoding, please see our discussion thread at [ONIONADDRESS-REFS]. - diff --git a/spec/rend-spec-v3/encrypting-data-between-client-host.md b/spec/rend-spec-v3/encrypting-data-between-client-host.md index 41cb1fa..f3ce6f7 100644 --- a/spec/rend-spec-v3/encrypting-data-between-client-host.md +++ b/spec/rend-spec-v3/encrypting-data-between-client-host.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-5"></a> + # Encrypting data between client and host A successfully completed handshake, as embedded in the @@ -9,4 +10,3 @@ Tor relay encryption protocol, applying encryption with these keys before other encryption, and decrypting with these keys before other decryption. The client encrypts with Kf and decrypts with Kb; the service host does the opposite. - diff --git a/spec/rend-spec-v3/generating-publishing-hidden-service-descriptors.md b/spec/rend-spec-v3/generating-publishing-hidden-service-descriptors.md index 403ef31..a540bec 100644 --- a/spec/rend-spec-v3/generating-publishing-hidden-service-descriptors.md +++ b/spec/rend-spec-v3/generating-publishing-hidden-service-descriptors.md @@ -1,8 +1,8 @@ <a id="rend-spec-v3.txt-2"></a> + # Generating and publishing hidden service descriptors [HSDIR] Hidden service descriptors follow the same metaformat as other Tor directory objects. They are published anonymously to Tor servers with the HSDir flag, HSDir=2 protocol version and tor version >= 0.3.0.8 (because a bug was fixed in this version). - diff --git a/spec/rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md b/spec/rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md index 8c6982b..719d4fa 100644 --- a/spec/rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md +++ b/spec/rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-2.5"></a> + ## Hidden service descriptors: encryption format [HS-DESC-ENC] Hidden service descriptors are protected by two layers of encryption. @@ -10,6 +11,7 @@ second layer of encryption is only useful when client authorization is enabled and protects against entities that do not possess valid client credentials. <a id="rend-spec-v3.txt-2.5.1"></a> + ### First layer of encryption [HS-DESC-FIRST-LAYER] The first layer of HS descriptor encryption is designed to protect @@ -17,6 +19,7 @@ descriptor confidentiality against entities who don't know the public identity key of the hidden service. <a id="rend-spec-v3.txt-2.5.1.1"></a> + #### First layer encryption logic The encryption keys and format for the first layer of encryption are @@ -39,6 +42,7 @@ Before encryption the plaintext is padded with NUL bytes to the nearest multiple of 10k bytes. <a id="rend-spec-v3.txt-2.5.1.2"></a> + #### First layer plaintext format After clients decrypt the first layer of encryption, they need to parse the @@ -133,6 +137,7 @@ Here are all the supported fields: ``` <a id="rend-spec-v3.txt-2.5.1.3"></a> + #### Client behavior [FIRST-LAYER-CLIENT-BEHAVIOR] ```text @@ -154,6 +159,7 @@ Here are all the supported fields: ``` <a id="rend-spec-v3.txt-2.5.1.4"></a> + #### Hiding client authorization data ```text @@ -176,6 +182,7 @@ Here are all the supported fields: ``` <a id="rend-spec-v3.txt-2.5.2"></a> + ### Second layer of encryption [HS-DESC-SECOND-LAYER] The second layer of descriptor encryption is designed to protect descriptor @@ -188,6 +195,7 @@ If client authorization is disabled, then the second layer of HS encryption does not offer any additional security, but is still used. <a id="rend-spec-v3.txt-2.5.2.1"></a> + #### Second layer encryption keys The encryption keys and format for the second layer of encryption are @@ -204,6 +212,7 @@ parameters as follows: ``` <a id="rend-spec-v3.txt-2.5.2.2"></a> + #### Second layer plaintext format After decrypting the second layer ciphertext, clients can finally learn the @@ -386,6 +395,7 @@ implementations MUST accept this section even if it is missing its final newline. <a id="rend-spec-v3.txt-2.5.3"></a> + ### Deriving hidden service descriptor encryption keys [HS-DESC-ENCRYPTION-KEYS] In this section we present the generic encryption format for hidden service @@ -428,6 +438,7 @@ Here is the key generation logic: ``` <a id="rend-spec-v3.txt-2.5.4"></a> + ### Number of introduction points [NUM_INTRO_POINT] This section defines how many introduction points an hidden service @@ -443,4 +454,3 @@ The reason for a maximum value of 20 is to give enough scalability to tools like OnionBalance to be able to load balance up to 120 servers (20 x 6 HSDirs) but also in order for the descriptor size to not overwhelmed hidden service directories with user defined values that could be gigantic. - diff --git a/spec/rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md b/spec/rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md index df6a790..f981e11 100644 --- a/spec/rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md +++ b/spec/rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-2.4"></a> + ## Hidden service descriptors: outer wrapper [DESC-OUTER] The format for a hidden service descriptor is as follows, using the @@ -71,4 +72,3 @@ meta-format from dir-spec.txt. HSDirs accept hidden service descriptors of up to 50k bytes (a consensus parameter should also be introduced to control this value). - diff --git a/spec/rend-spec-v3/hidden-service-directory-format-hidservdir-format.md b/spec/rend-spec-v3/hidden-service-directory-format-hidservdir-format.md index 6c56bba..9f6cfc6 100644 --- a/spec/rend-spec-v3/hidden-service-directory-format-hidservdir-format.md +++ b/spec/rend-spec-v3/hidden-service-directory-format-hidservdir-format.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-F"></a> + # Appendix F: Hidden service directory format [HIDSERVDIR-FORMAT] This appendix section specifies the contents of the HiddenServiceDir directory: @@ -27,4 +28,3 @@ the client. See section [CLIENT-AUTH-MGMT] for more details and the format of the client file. (NOTE: client authorization is implemented as of 0.3.5.1-alpha.) - diff --git a/spec/rend-spec-v3/hidden-services-overview-preliminaries.md b/spec/rend-spec-v3/hidden-services-overview-preliminaries.md index a71790c..382c732 100644 --- a/spec/rend-spec-v3/hidden-services-overview-preliminaries.md +++ b/spec/rend-spec-v3/hidden-services-overview-preliminaries.md @@ -1,5 +1,6 @@ <a id="rend-spec-v3.txt-0"></a> -# Hidden services: overview and preliminaries. + +# Hidden services: overview and preliminaries Hidden services aim to provide responder anonymity for bidirectional stream-based communication on the Tor network. Unlike regular Tor @@ -32,7 +33,8 @@ Operator -- A person running a hidden service ``` <a id="rend-spec-v3.txt-0.1"></a> -## Improvements over previous versions. + +## Improvements over previous versions Here is a list of improvements of this proposal over the legacy hidden services: @@ -46,6 +48,7 @@ f) Offline keys for onion services g) Advanced client authorization <a id="rend-spec-v3.txt-0.2"></a> + ## Notation and vocabulary Unless specified otherwise, all multi-octet integers are big-endian. @@ -72,6 +75,7 @@ unsigned integer "val" in N bytes. For example, INT_4(1337) is [00 00 INT_4(42) is 42 % 4294967296 (32 bit). <a id="rend-spec-v3.txt-0.3"></a> + ## Cryptographic building blocks This specification uses the following cryptographic building blocks: @@ -129,8 +133,8 @@ This specification uses the following cryptographic building blocks: where k_len is htonll(len(k)). ``` - When we need a particular MAC key length below, we choose - MAC_KEY_LEN=32 (256 bits). + When we need a particular MAC key length below, we choose + MAC_KEY_LEN=32 (256 bits). For legacy purposes, we specify compatibility with older versions of the Tor introduction point and rendezvous point protocols. These used @@ -142,6 +146,7 @@ themselves, but over those strings prefixed with a distinguishing value. <a id="rend-spec-v3.txt-0.4"></a> + ## Protocol building blocks [BUILDING-BLOCKS] In sections below, we need to transmit the locations and identities @@ -177,6 +182,7 @@ material unless they control the secret key corresponding to the server's public key. <a id="rend-spec-v3.txt-0.5"></a> + ## Assigned relay cell types These relay cell types are reserved for use in the hidden service @@ -237,6 +243,7 @@ protocol. ``` <a id="rend-spec-v3.txt-0.6"></a> + ## Acknowledgments This design includes ideas from many people, including @@ -306,4 +313,3 @@ editing help from Please forgive me if I've missed you; please forgive me if I've misunderstood your best ideas here too. - diff --git a/spec/rend-spec-v3/introduction-protocol-intro-protocol.md b/spec/rend-spec-v3/introduction-protocol-intro-protocol.md index a9813c2..e1977fc 100644 --- a/spec/rend-spec-v3/introduction-protocol-intro-protocol.md +++ b/spec/rend-spec-v3/introduction-protocol-intro-protocol.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-3"></a> + # The introduction protocol [INTRO-PROTOCOL] The introduction protocol proceeds in three steps. @@ -28,9 +29,11 @@ the introduction circuit to the hidden service host, and acknowledges the introduction request to the client. <a id="rend-spec-v3.txt-3.1"></a> + ## Registering an introduction point [REG_INTRO_POINT] <a id="rend-spec-v3.txt-3.1.1"></a> + ### Extensible ESTABLISH_INTRO protocol. [EST_INTRO] When a hidden service is establishing a new introduction point, it @@ -111,6 +114,7 @@ Otherwise, the node must associate the key with the circuit, for use later in INTRODUCE1 cells. <a id="rend-spec-v3.txt-3.1.1.1"></a> + #### Denial-of-Service Defense Extension. [EST_INTRO_DOS_EXT] This extension can be used to send Denial-of-Service (DoS) parameters to @@ -210,6 +214,7 @@ Older versions of Tor always use a 1024-bit RSA key for these introduction authentication keys. <a id="rend-spec-v3.txt-3.1.3"></a> + ### Acknowledging establishment of introduction point [INTRO_ESTABLISHED] After setting up an introduction circuit, the introduction point reports its @@ -234,6 +239,7 @@ The same rules for multiplicity, ordering, and handling unknown types apply to the extension fields here as described [EST_INTRO] above. <a id="rend-spec-v3.txt-3.2"></a> + ## Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] In order to participate in the introduction protocol, a client must @@ -260,6 +266,7 @@ or that its request will not succeed. ``` <a id="rend-spec-v3.txt-3.2.1"></a> + ### INTRODUCE1 cell format [FMT_INTRO1] When a client is connecting to an introduction point, INTRODUCE1 cells @@ -302,6 +309,7 @@ The same rules for multiplicity, ordering, and handling unknown types apply to the extension fields here as described [EST_INTRO] above. <a id="rend-spec-v3.txt-3.2.2"></a> + ### INTRODUCE_ACK cell format. [INTRO_ACK] An INTRODUCE_ACK cell has the following fields: @@ -326,6 +334,7 @@ The same rules for multiplicity, ordering, and handling unknown types apply to the extension fields here as described [EST_INTRO] above. <a id="rend-spec-v3.txt-3.3"></a> + ## Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2] Upon receiving an INTRODUCE2 cell, the hidden service host checks whether @@ -422,6 +431,7 @@ The same rules for multiplicity, ordering, and handling unknown types apply to the extension fields here as described [EST_INTRO] above. <a id="rend-spec-v3.txt-3.3.1"></a> + ### Introduction handshake encryption requirements [INTRO-HANDSHAKE-REQS] When decoding the encrypted information in an INTRODUCE2 cell, a @@ -569,6 +579,7 @@ computed in tor-spec.txt section 5.1.4, except that instead of using AES-128 and SHA1 for this hop, we use AES-256 and SHA3-256. <a id="rend-spec-v3.txt-3.4"></a> + ## Authentication during the introduction phase. [INTRO-AUTH] Hidden services may restrict access only to authorized users. @@ -578,7 +589,8 @@ know the credential for a hidden service may connect at all. There is one defined authentication type: `ed25519`. <a id="rend-spec-v3.txt-3.4.1"></a> -### Ed25519-based authentication `ed25519`. + +### Ed25519-based authentication `ed25519` (NOTE: This section is not implemented by Tor. It is likely that we would want to change its design substantially before @@ -618,4 +630,3 @@ on the authentication. Users SHOULD NOT use the same public key with multiple hidden services. - diff --git a/spec/rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md b/spec/rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md index 6802d4b..2051e86 100644 --- a/spec/rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md +++ b/spec/rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-G"></a> + # Appendix G: Managing authorized client data [CLIENT-AUTH-MGMT] Hidden services and clients can configure their authorized client data either @@ -102,4 +103,3 @@ G.1.1. Hidden Service side configuration [XXX what happens when people use both the control port interface and the filesystem interface?] ``` - diff --git a/spec/rend-spec-v3/numeric-values-reserved-this-document.md b/spec/rend-spec-v3/numeric-values-reserved-this-document.md index 82eca4c..1e11c73 100644 --- a/spec/rend-spec-v3/numeric-values-reserved-this-document.md +++ b/spec/rend-spec-v3/numeric-values-reserved-this-document.md @@ -1,5 +1,5 @@ <a id="rend-spec-v3.txt-D"></a> + # Appendix D: Numeric values reserved in this document [TODO: collect all the lists of commands and values mentioned above] - diff --git a/spec/rend-spec-v3/open-questions.md b/spec/rend-spec-v3/open-questions.md index af2b347..140b1f5 100644 --- a/spec/rend-spec-v3/open-questions.md +++ b/spec/rend-spec-v3/open-questions.md @@ -1,5 +1,6 @@ <a id="rend-spec-v3.txt-7"></a> -# Open Questions: + +# Open Questions Scaling hidden services is hard. There are on-going discussions that you might be able to help with. See [SCALING-REFS]. @@ -77,4 +78,3 @@ References: https://lists.torproject.org/pipermail/tor-dev/2017-April/012164.html https://getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html ``` - diff --git a/spec/rend-spec-v3/protocol-overview.md b/spec/rend-spec-v3/protocol-overview.md index cb47184..1c03e49 100644 --- a/spec/rend-spec-v3/protocol-overview.md +++ b/spec/rend-spec-v3/protocol-overview.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-1"></a> + # Protocol overview In this section, we outline the hidden service protocol. This section @@ -6,6 +7,7 @@ omits some details in the name of simplicity; those are given more fully below, when we specify the protocol in more detail. <a id="rend-spec-v3.txt-1.1"></a> + ## View from 10,000 feet A hidden service host prepares to offer a hidden service by choosing @@ -44,6 +46,7 @@ or processes configured by the server; RELAY_DATA cells are used to communicate data on those streams, and so forth. <a id="rend-spec-v3.txt-1.2"></a> + ## In more detail: naming hidden services [NAMING] A hidden service's name is its long term master identity key. This is @@ -69,6 +72,7 @@ their length. An older name might look like: ``` <a id="rend-spec-v3.txt-1.3"></a> + ## In more detail: Access control [IMD:AC] Access control for a hidden service is imposed at multiple points through @@ -103,6 +107,7 @@ optional client authorization is enabled, the service may additionally require the client to prove knowledge of a pre-shared private key. <a id="rend-spec-v3.txt-1.4"></a> + ## In more detail: Distributing hidden service descriptors. [IMD:DIST] Periodically, hidden service descriptors become stored at different @@ -147,6 +152,7 @@ its blinded signing key. The keys for the last period remain valid until the new keys come online. <a id="rend-spec-v3.txt-1.5"></a> + ## In more detail: Scaling to multiple hosts This design is compatible with our current approaches for scaling hidden @@ -168,6 +174,7 @@ enable the use of older Tor nodes as rendezvous points and introduction points. <a id="rend-spec-v3.txt-1.7"></a> + ## In more detail: Keeping crypto keys offline In this design, a hidden service's secret identity key may be @@ -194,6 +201,7 @@ only be used to create credentials for the descriptor signing keys. implemented as of 0.3.2.1-alpha.) <a id="rend-spec-v3.txt-1.8"></a> + ## In more detail: Encryption Keys And Replay Resistance To avoid replays of an introduction request by an introduction point, @@ -204,6 +212,7 @@ time can create a problematic fingerprint. (See proposal 222 for more discussion.) <a id="rend-spec-v3.txt-1.9"></a> + ## In more detail: A menagerie of keys [In the text below, an "encryption keypair" is roughly "a keypair you @@ -282,6 +291,7 @@ Public/private keypairs defined in this document: ``` <a id="rend-spec-v3.txt-1.9.1"></a> + ### In even more detail: Client authorization keys [CLIENT-AUTH] When client authorization is enabled, each authorized client of a hidden @@ -316,4 +326,3 @@ keys should be managed. [TODO: Also specify stealth client authorization.] (NOTE: client authorization is implemented as of 0.3.5.1-alpha.) - diff --git a/spec/rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md b/spec/rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md index 51f3624..dce072c 100644 --- a/spec/rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md +++ b/spec/rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md @@ -1,4 +1,5 @@ <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 @@ -17,6 +18,7 @@ According to proposal 250, we add two new lines in consensuses: ``` <a id="rend-spec-v3.txt-2.3.1"></a> + ### Client behavior in the absence of shared random values If the previous or current shared random value cannot be found in a @@ -33,6 +35,7 @@ rounded down; period_num is calculated as specified in found originally. <a id="rend-spec-v3.txt-2.3.2"></a> + ### Hidden services and changing shared random values It's theoretically possible that the consensus shared random values will @@ -44,4 +47,3 @@ 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? - diff --git a/spec/rend-spec-v3/recommendations-for-searching-for-vanity-onions.md b/spec/rend-spec-v3/recommendations-for-searching-for-vanity-onions.md index 9cbd8b9..3c7142b 100644 --- a/spec/rend-spec-v3/recommendations-for-searching-for-vanity-onions.md +++ b/spec/rend-spec-v3/recommendations-for-searching-for-vanity-onions.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-C"></a> + # Appendix C: Recommendations for searching for vanity .onions [VANITY] EDITORIAL NOTE: The author thinks that it's silly to brute-force the @@ -42,4 +43,3 @@ independently. See [VANITY-REFS] for a reference implementation of this vanity .onion search scheme. - diff --git a/spec/rend-spec-v3/rendezvous-protocol.md b/spec/rend-spec-v3/rendezvous-protocol.md index 65a70aa..316bcf2 100644 --- a/spec/rend-spec-v3/rendezvous-protocol.md +++ b/spec/rend-spec-v3/rendezvous-protocol.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-4"></a> + # The rendezvous protocol Before connecting to a hidden service, the client first builds a @@ -19,6 +20,7 @@ but use an anonymous 3-hop circuit if: ``` <a id="rend-spec-v3.txt-4.1"></a> + ## Establishing a rendezvous point [EST_REND_POINT] The client sends the rendezvous point a RELAY_COMMAND_ESTABLISH_RENDEZVOUS @@ -47,6 +49,7 @@ The client should establish a rendezvous point BEFORE trying to connect to a hidden service. <a id="rend-spec-v3.txt-4.2"></a> + ## Joining to a rendezvous point [JOIN_REND] To complete a rendezvous, the hidden service host builds a circuit to @@ -87,13 +90,14 @@ Now both parties use the handshake output to derive shared keys for use on the circuit as specified in the section below: <a id="rend-spec-v3.txt-4.2.1"></a> + ### Key expansion The hidden service and its client need to derive crypto keys from the NTOR_KEY_SEED part of the handshake output. To do so, they use the KDF construction as follows: -K = KDF(NTOR_KEY_SEED | m_hsexpand, HASH_LEN * 2 + S_KEY_LEN * 2) +K = KDF(NTOR_KEY_SEED | m_hsexpand, HASH_LEN *2 + S_KEY_LEN* 2) The first HASH_LEN bytes of K form the forward digest Df; the next HASH_LEN bytes form the backward digest Db; the next S_KEY_LEN bytes form Kf, and the @@ -113,6 +117,7 @@ contents? It's not necessary, but it could be wise. Similarly, we should make it extensible.] <a id="rend-spec-v3.txt-4.3"></a> + ## Using legacy hosts as rendezvous points [This section is obsolete and refers to a workaround for now-obsolete Tor @@ -131,4 +136,3 @@ Relays older than 0.2.9.1 should not be used for rendezvous points by next generation onion services because they enforce too-strict length checks to rendezvous cells. Hence the "HSRend" protocol from proposal#264 should be used to select relays for rendezvous points. - diff --git a/spec/rend-spec-v3/reserved-numbers.md b/spec/rend-spec-v3/reserved-numbers.md index 2fe9fba..70c9e36 100644 --- a/spec/rend-spec-v3/reserved-numbers.md +++ b/spec/rend-spec-v3/reserved-numbers.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-E"></a> + # Appendix E: Reserved numbers We reserve these certificate type values for Ed25519 certificates: @@ -14,4 +15,3 @@ We reserve these certificate type values for Ed25519 certificates: Note: The value "0A" is skipped because it's reserved for the onion key cross-certifying ntor identity key from proposal 228. ``` - diff --git a/spec/rend-spec-v3/selecting-nodes-picknodes.md b/spec/rend-spec-v3/selecting-nodes-picknodes.md index cb4cb13..ef5edb4 100644 --- a/spec/rend-spec-v3/selecting-nodes-picknodes.md +++ b/spec/rend-spec-v3/selecting-nodes-picknodes.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-B"></a> + # Appendix B: Selecting nodes [PICKNODES] Picking introduction points @@ -7,4 +8,3 @@ Building paths Reusing circuits (TODO: This needs a writeup) - diff --git a/spec/rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md b/spec/rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md index f4f950d..d0393dd 100644 --- a/spec/rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md +++ b/spec/rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md @@ -1,7 +1,9 @@ <a id="rend-spec-v3.txt-A"></a> + # Appendix A: Signature scheme with key blinding [KEYBLIND] <a id="rend-spec-v3.txt-A.1"></a> + ## Key derivation overview As described in [IMD:DIST] and [SUBCRED] above, we require a "key @@ -34,6 +36,7 @@ There is a master keypair (sk, pk). ``` <a id="rend-spec-v3.txt-A.2"></a> + ## Tor's key derivation scheme We propose the following scheme for key blinding, based on Ed25519. @@ -99,4 +102,3 @@ Verifying the signature: Check whether SB = R+hash(R,A',M)A'. See [KEYBLIND-REFS] for an extensive discussion on this scheme and possible alternatives. Also, see [KEYBLIND-PROOF] for a security proof of this scheme. - diff --git a/spec/rend-spec-v3/text-vectors.md b/spec/rend-spec-v3/text-vectors.md index 71897e8..ad3701b 100644 --- a/spec/rend-spec-v3/text-vectors.md +++ b/spec/rend-spec-v3/text-vectors.md @@ -1,4 +1,5 @@ <a id="rend-spec-v3.txt-G"></a> + # Appendix G: Text vectors G.1. Test vectors for hs-ntor / NTOR-WITH-EXTRA-DATA @@ -98,4 +99,3 @@ AUTH_INPUT_MAC, and computes the same NTOR_KEY_SEED. Now that both parties have the same NTOR_KEY_SEED, they can derive the shared key material they will use for their circuit. - diff --git a/spec/rend-spec-v3/two-methods-for-managing-revision-counters.md b/spec/rend-spec-v3/two-methods-for-managing-revision-counters.md index 45ebc10..9088cf7 100644 --- a/spec/rend-spec-v3/two-methods-for-managing-revision-counters.md +++ b/spec/rend-spec-v3/two-methods-for-managing-revision-counters.md @@ -1,5 +1,6 @@ <a id="rend-spec-v3.txt-F"></a> -# Appendix F: Two methods for managing revision counters. + +# Appendix F: Two methods for managing revision counters Implementations MAY generate revision counters in any way they please, so long as they are monotonically increasing over the lifetime of each @@ -78,4 +79,3 @@ F.1. Increment-on-generation increase forever without resetting it -- doing so links the service across changes in the blinded public key. ``` - |