diff options
Diffstat (limited to 'spec/rend-spec')
| -rw-r--r-- | spec/rend-spec/encrypting-user-data.md | 2 | ||||
| -rw-r--r-- | spec/rend-spec/introduction-protocol.md | 121 | ||||
| -rw-r--r-- | spec/rend-spec/overview.md | 10 | ||||
| -rw-r--r-- | spec/rend-spec/protocol-overview.md | 9 | ||||
| -rw-r--r-- | spec/rend-spec/rendezvous-protocol.md | 32 | ||||
| -rw-r--r-- | spec/rend-spec/text-vectors.md | 6 |
6 files changed, 92 insertions, 88 deletions
diff --git a/spec/rend-spec/encrypting-user-data.md b/spec/rend-spec/encrypting-user-data.md index f3ce6f7..460f71e 100644 --- a/spec/rend-spec/encrypting-user-data.md +++ b/spec/rend-spec/encrypting-user-data.md @@ -3,7 +3,7 @@ # Encrypting data between client and host A successfully completed handshake, as embedded in the -INTRODUCE/RENDEZVOUS cells, gives the client and hidden service host +INTRODUCE/RENDEZVOUS messages, gives the client and hidden service host a shared set of keys Kf, Kb, Df, Db, which they use for sending end-to-end traffic encryption and authentication as in the regular Tor relay encryption protocol, applying encryption with these keys diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md index 8b841fc..cb7debf 100644 --- a/spec/rend-spec/introduction-protocol.md +++ b/spec/rend-spec/introduction-protocol.md @@ -37,7 +37,7 @@ the introduction request to the client. ### Extensible ESTABLISH_INTRO protocol {#EST_INTRO} When a hidden service is establishing a new introduction point, it -sends an ESTABLISH_INTRO cell with the following contents: +sends an ESTABLISH_INTRO message with the following contents: ```text AUTH_KEY_TYPE [1 byte] @@ -58,7 +58,7 @@ authentication key and the type of the MAC to use in HANDSHAKE_AUTH. Recognized types are: ```text - [00, 01] -- Reserved for legacy introduction cells; see + [00, 01] -- Reserved for legacy introduction messages; see [LEGACY_EST_INTRO below] [02] -- Ed25519; SHA3-256. ``` @@ -91,20 +91,23 @@ The following extensions are currently defined: [`DOS_PARAMS`]: #DOS_PARAMS The HANDSHAKE_AUTH field contains the MAC of all earlier fields in -the cell using as its key the shared per-circuit material ("KH") +the message using as its key the shared per-circuit material ("KH") generated during the circuit extension protocol; see tor-spec.txt section 5.2, "Setting circuit keys". It prevents replays of -ESTABLISH_INTRO cells. +ESTABLISH_INTRO messages. SIG_LEN is the length of the signature. -SIG is a signature, using AUTH_KEY, of all contents of the cell, up +SIG is a signature, using AUTH_KEY, of all contents of the message, up to but not including SIG_LEN and SIG. These contents are prefixed with the string "Tor establish-intro cell v1". -Upon receiving an ESTABLISH_INTRO cell, a Tor node first decodes the +> (Note that this string is _sic_; +> it predates our efforts to distinguish cells from relay messages.) + +Upon receiving an ESTABLISH_INTRO message, a Tor node first decodes the key and the signature, and checks the signature. The node must reject -the ESTABLISH_INTRO cell and destroy the circuit in these cases: +the ESTABLISH_INTRO message and destroy the circuit in these cases: ```text * If the key type is unrecognized @@ -119,7 +122,7 @@ the ESTABLISH_INTRO cell and destroy the circuit in these cases: ``` Otherwise, the node must associate the key with the circuit, for use -later in INTRODUCE1 cells. +later in INTRODUCE1 messages. @@ -182,7 +185,7 @@ and the introduction point should ignore the other parameter. If the burst is lower than the rate, the introduction point SHOULD ignore the extension. -> Using this extension extends the payload of the ESTABLISH_INTRO cell by 19 +> Using this extension extends the payload of the ESTABLISH_INTRO message by 19 > bytes bringing it from 134 bytes to 155 bytes. When this extension is not _sent_, @@ -206,11 +209,11 @@ Introduced in tor-0.4.2.1-alpha. > relay versions. It is included for historical reasons. Tor nodes should also support an older version of the ESTABLISH_INTRO -cell, first documented in rend-spec.txt. New hidden service hosts +message, first documented in rend-spec.txt. New hidden service hosts must use this format when establishing introduction points at older Tor nodes that do not support the format above in \[EST_INTRO\]. -In this older protocol, an ESTABLISH_INTRO cell contains: +In this older protocol, an ESTABLISH_INTRO message contains: ```text KEY_LEN [2 bytes] @@ -237,9 +240,9 @@ authentication keys. ### Acknowledging establishment of introduction point {#INTRO_ESTABLISHED} After setting up an introduction circuit, the introduction point reports its -status back to the hidden service host with an INTRO_ESTABLISHED cell. +status back to the hidden service host with an INTRO_ESTABLISHED message. -The INTRO_ESTABLISHED cell has the following contents: +The INTRO_ESTABLISHED message has the following contents: ```text N_EXTENSIONS [1 byte] @@ -249,8 +252,8 @@ The INTRO_ESTABLISHED cell has the following contents: EXT_FIELD [EXT_FIELD_LEN bytes] ``` -Older versions of Tor send back an empty INTRO_ESTABLISHED cell instead. -Services must accept an empty INTRO_ESTABLISHED cell from a legacy relay. +Older versions of Tor send back an empty INTRO_ESTABLISHED message instead. +Services must accept an empty INTRO_ESTABLISHED message from a legacy relay. \[The above paragraph is obsolete and refers to a workaround for now-obsolete Tor relay versions. It is included for historical reasons.\] @@ -259,7 +262,7 @@ 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} +## Sending an INTRODUCE1 message to the introduction point {#SEND_INTRO1} In order to participate in the introduction protocol, a client must know the following: @@ -270,12 +273,12 @@ know the following: * The introduction encryption key for that introduction point. ``` -The client sends an INTRODUCE1 cell to the introduction point, +The client sends an INTRODUCE1 message to the introduction point, containing an identifier for the service, an identifier for the encryption key that the client intends to use, and an opaque blob to be relayed to the hidden service host. -In reply, the introduction point sends an INTRODUCE_ACK cell back to +In reply, the introduction point sends an INTRODUCE_ACK message back to the client, either informing it that its request has been delivered, or that its request will not succeed. @@ -289,15 +292,15 @@ either by extending its introduction circuit an additional hop, or by building a new introduction circuit. ```text - [TODO: specify what tor should do when receiving a malformed cell. Drop it? - Kill circuit? This goes for all possible cells.] + [TODO: specify what tor should do when receiving a malformed message. Drop it? + Kill circuit? This goes for all possible messages.] ``` <a id="rend-spec-v3.txt-3.2.1"></a> -### Extensible INTRODUCE1 cell format {#FMT_INTRO1} +### Extensible INTRODUCE1 message format {#FMT_INTRO1} -When a client is connecting to an introduction point, INTRODUCE1 cells +When a client is connecting to an introduction point, INTRODUCE1 messages should be of the form: ```text @@ -316,22 +319,22 @@ should be of the form: The `ENCRYPTED` field is described in the \[PROCESS_INTRO2\] section. AUTH_KEY_TYPE is defined as in \[EST_INTRO\]. Currently, the only value of -AUTH_KEY_TYPE for this cell is an Ed25519 public key \[02\]. +AUTH_KEY_TYPE for this message is an Ed25519 public key \[02\]. The LEGACY_KEY_ID field is used to distinguish between legacy and new style -INTRODUCE1 cells. In new style INTRODUCE1 cells, LEGACY_KEY_ID is 20 zero -bytes. Upon receiving an INTRODUCE1 cell, the introduction point checks the -LEGACY_KEY_ID field. If LEGACY_KEY_ID is non-zero, the INTRODUCE1 cell -should be handled as a legacy INTRODUCE1 cell by the intro point. +INTRODUCE1 messages. In new style INTRODUCE1 messages, LEGACY_KEY_ID is 20 zero +bytes. Upon receiving an INTRODUCE1 messages, the introduction point checks the +LEGACY_KEY_ID field. If LEGACY_KEY_ID is non-zero, the INTRODUCE1 message +should be handled as a legacy INTRODUCE1 message by the intro point. -Upon receiving a INTRODUCE1 cell, the introduction point checks +Upon receiving a INTRODUCE1 message, the introduction point checks whether AUTH_KEY matches the introduction point authentication key for an active introduction circuit. If so, the introduction point sends an -INTRODUCE2 cell with exactly the same contents to the service, and sends an +INTRODUCE2 message with exactly the same contents to the service, and sends an INTRODUCE_ACK response to the client. (Note that the introduction point does not "clean up" the -INTRODUCE1 cells that it retransmits. Specifically, it does not +INTRODUCE1 message that it retransmits. Specifically, it does not change the order or multiplicity of the extensions sent by the client.) @@ -347,7 +350,7 @@ An acceptable proof will raise the priority of this introduction request accordi This is for the [proof-of-work DoS mitigation](../dos-spec/overview.md#hs-intro-pow), described in depth by the [Proof of Work for onion service introduction](../hspow-spec/index.md) specification. If used, it needs to be encoded within the N_EXTENSIONS field of the -ESTABLISH_INTRO cell defined in the previous section. The content is +ESTABLISH_INTRO message defined in the previous section. The content is defined as follows: EXT_FIELD_TYPE: @@ -379,15 +382,15 @@ A correctly functioning client only submits solutions with a version and seed wh An extension with an unknown version or expired seed is suspicious and SHOULD result in introduction failure. This will increase the INTRODUCE1 payload size by 43 bytes since the extension type and length is 2 extra bytes, the N_EXTENSIONS field is always present and currently set to 0 and the EXT_FIELD is 41 bytes. -According to ticket #33650, INTRODUCE1 cells currently have more than 200 bytes available. +According to ticket #33650, INTRODUCE1 messages currently have more than 200 bytes available. Introduced in tor-0.4.8.1-alpha. <a id="rend-spec-v3.txt-3.2.2"></a> -### INTRODUCE_ACK cell format. {#INTRO_ACK} +### INTRODUCE_ACK message format. {#INTRO_ACK} -An INTRODUCE_ACK cell has the following fields: +An INTRODUCE_ACK message has the following fields: ```text STATUS [2 bytes] @@ -399,10 +402,10 @@ An INTRODUCE_ACK cell has the following fields: Recognized status values are: - [00 00] -- Success: cell relayed to hidden service host. + [00 00] -- Success: message relayed to hidden service host. [00 01] -- Failure: service ID not recognized [00 02] -- Bad message format - [00 03] -- Can't relay cell to service + [00 03] -- Can't relay message to service ``` The same rules for multiplicity, ordering, and handling unknown types @@ -410,21 +413,21 @@ 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} +## Processing an INTRODUCE2 message at the hidden service. {#PROCESS_INTRO2} -Upon receiving an INTRODUCE2 cell, the hidden service host checks whether +Upon receiving an INTRODUCE2 message, the hidden service host checks whether the AUTH_KEY or LEGACY_KEY_ID field matches the keys for this introduction circuit. -The service host then checks whether it has received a cell with these +The service host then checks whether it has received a message with these contents or rendezvous cookie before. If it has, it silently drops it as a -replay. (It must maintain a replay cache for as long as it accepts cells +replay. (It must maintain a replay cache for as long as it accepts messages with the same encryption key. Note that the encryption format below should be non-malleable.) -If the cell is not a replay, it decrypts the ENCRYPTED field, +If the message is not a replay, it decrypts the ENCRYPTED field, establishes a shared key with the client, and authenticates the whole -contents of the cell as having been unmodified since they left the +contents of the message as having been unmodified since they left the client. There may be multiple ways of decrypting the ENCRYPTED field, depending on the chosen type of the encryption key. Requirements for an introduction handshake protocol are described in @@ -459,8 +462,8 @@ in \[BUILDING-BLOCKS\], the "TLS-over-TCP, IPv4" and "Legacy node identity" specifiers must be present. As of 0.4.1.1-alpha, clients include both IPv4 and IPv6 link specifiers -in INTRODUCE1 cells. All available addresses SHOULD be included in the -cell, regardless of the address that the client actually used to extend +in INTRODUCE1 messages. All available addresses SHOULD be included in the +message, regardless of the address that the client actually used to extend to the rendezvous point. The hidden service should handle invalid or unrecognised link specifiers @@ -491,7 +494,7 @@ proposal 340 and thus lower the number of bytes that can be contained in a single relay message.) Note also that current versions of Tor only pad the INTRODUCE2 message up to 246 bytes. -Upon receiving a well-formed INTRODUCE2 cell, the hidden service host +Upon receiving a well-formed INTRODUCE2 message, the hidden service host will have: ```text @@ -508,7 +511,7 @@ apply to the extension fields here as described \[EST_INTRO\] above. ### INTRODUCE1 Extensions The following sections details the currently supported or reserved extensions -of an `INTRODUCE1` cell. +of an `INTRODUCE1` message. #### Congestion Control @@ -558,7 +561,7 @@ effort is currently zero, the service follows the procedure detailed in prop327. If the service requires the PROOF_OF_WORK extension but received an INTRODUCE1 -cell without any embedded proof-of-work, the service SHOULD consider this cell +message without any embedded proof-of-work, the service SHOULD consider this message as a zero-effort introduction for the purposes of the priority queue (see section \[INTRO_QUEUE\] of prop327). @@ -577,17 +580,17 @@ point to the proposal.) ### Introduction handshake encryption requirements {#INTRO-HANDSHAKE-REQS} -When decoding the encrypted information in an INTRODUCE2 cell, a +When decoding the encrypted information in an INTRODUCE2 message, a hidden service host must be able to: ```text - * Decrypt additional information included in the INTRODUCE2 cell, + * Decrypt additional information included in the INTRODUCE2 message, to include the rendezvous token and the information needed to extend to the rendezvous point. * Establish a set of shared keys for use with the client. - * Authenticate that the cell has not been modified since the client + * Authenticate that the message has not been modified since the client generated it. ``` @@ -624,7 +627,7 @@ We also use the following tweak values: m_hsexpand = PROTOID | ":hs_key_expand" ``` -To make an INTRODUCE1 cell, the client must know a public encryption +To make an INTRODUCE1 message, the client must know a public encryption key B for the hidden service on this introduction circuit. The client generates a single-use keypair: @@ -639,14 +642,14 @@ and computes: ENC_KEY = hs_keys[0:S_KEY_LEN] MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN] - and sends, as the ENCRYPTED part of the INTRODUCE1 cell: + and sends, as the ENCRYPTED part of the INTRODUCE1 message: CLIENT_PK [PK_PUBKEY_LEN bytes] ENCRYPTED_DATA [Padded to length of plaintext] MAC [MAC_LEN bytes] ``` -Substituting those fields into the INTRODUCE1 cell body format +Substituting those fields into the INTRODUCE1 message body format described in \[FMT_INTRO1\] above, we have ```text @@ -672,14 +675,14 @@ Here, the encryption key plays the role of B in the regular ntor handshake, and the AUTH_KEY field plays the role of the node ID. The CLIENT_PK field is the public key X. The ENCRYPTED_DATA field is the message plaintext, encrypted with the symmetric key ENC_KEY. The -MAC field is a MAC of all of the cell from the AUTH_KEY through the +MAC field is a MAC of all of the message from the AUTH_KEY through the end of ENCRYPTED_DATA, using the MAC_KEY value as its key. To process this format, the hidden service checks PK_VALID(CLIENT_PK) as necessary, and then computes ENC_KEY and MAC_KEY as the client did above, except using EXP(CLIENT_PK,b) in the calculation of intro_secret_hs_input. The service host then checks whether the MAC is -correct. If it is invalid, it drops the cell. Otherwise, it computes +correct. If it is invalid, it drops the message. Otherwise, it computes the plaintext by decrypting ENCRYPTED_DATA. The hidden service host now completes the service side of the @@ -712,7 +715,7 @@ introduction point encryption key 'b' to compute: AUTH AUTH_INPUT_MAC [MAC_LEN bytes] ``` -These fields will be sent to the client in a RENDEZVOUS1 cell using the +These fields will be sent to the client in a RENDEZVOUS1 message using the HANDSHAKE_INFO element (see \[JOIN_REND\]). The hidden service host now also knows the keys generated by the @@ -743,7 +746,7 @@ prevent replays. We might also want to look for ways to limit the number of keys a user needs to have.) To authenticate with an Ed25519 private key, the user must include an -extension field in the encrypted part of the INTRODUCE1 cell with an +extension field in the encrypted part of the INTRODUCE1 message with an EXT_FIELD_TYPE type of \[02\] and the contents: ```text @@ -760,7 +763,7 @@ key instead?\] Signature is the signature, using Ed25519, of: "hidserv-userauth-ed25519" Nonce (same as above) Pubkey (same as above) - AUTH_KEY (As in the INTRODUCE1 cell) + AUTH_KEY (As in the INTRODUCE1 message) ``` The hidden service host checks this by seeing whether it recognizes @@ -768,7 +771,7 @@ and would accept a signature from the provided public key. If it would, then it checks whether the signature is correct. If it is, then the correct user has authenticated. -Replay prevention on the whole cell is sufficient to prevent replays +Replay prevention on the whole message is sufficient to prevent replays on the authentication. Users SHOULD NOT use the same public key with multiple hidden diff --git a/spec/rend-spec/overview.md b/spec/rend-spec/overview.md index 61aa55a..5ccddd4 100644 --- a/spec/rend-spec/overview.md +++ b/spec/rend-spec/overview.md @@ -151,7 +151,7 @@ value. In sections below, we need to transmit the locations and identities of Tor nodes. We do so in the link identification format used by -EXTEND2 cells in the Tor protocol. +EXTEND2 messages in the Tor protocol. ```text NSPEC (Number of link specifiers) [1 byte] @@ -183,9 +183,9 @@ server's public key. <a id="rend-spec-v3.txt-0.5"></a> -## Assigned relay cell types {#relay-cell-types} +## Assigned relay message types {#relay-cell-types} -These relay cell types are reserved for use in the hidden service +These relay message types are reserved for use in the hidden service protocol. 32 -- RELAY_COMMAND_ESTABLISH_INTRO @@ -232,13 +232,13 @@ protocol. 39 -- RELAY_COMMAND_RENDEZVOUS_ESTABLISHED Sent from rendezvous point to client; acknowledges - receipt of ESTABLISH_RENDEZVOUS cell. Discussed in + receipt of ESTABLISH_RENDEZVOUS message. Discussed in [EST_REND_POINT] 40 -- RELAY_COMMAND_INTRODUCE_ACK Sent from introduction point to client; acknowledges - receipt of INTRODUCE1 cell and reports success/failure. + receipt of INTRODUCE1 message and reports success/failure. Discussed in [INTRO_ACK] ``` diff --git a/spec/rend-spec/protocol-overview.md b/spec/rend-spec/protocol-overview.md index 10c67b9..a50b3d1 100644 --- a/spec/rend-spec/protocol-overview.md +++ b/spec/rend-spec/protocol-overview.md @@ -40,9 +40,10 @@ circuits, and the cryptographic handshake gives the two parties a shared key and proves to the client that it is indeed talking to the hidden service. -Once the two circuits are joined, the client can send Tor RELAY cells -to the server. RELAY_BEGIN cells open streams to an external process -or processes configured by the server; RELAY_DATA cells are used to +Once the two circuits are joined, the client can use Tor RELAY cells +to deliver relay messages +to the server. RELAY_BEGIN messages open streams to an external process +or processes configured by the server; RELAY_DATA messages are used to communicate data on those streams, and so forth. <a id="rend-spec-v3.txt-1.2"></a> @@ -330,7 +331,7 @@ Specifically, each authorized client possesses: - An ed25519 keypair which allows the client to compute signatures which prove to the hidden service that the client is authorized. These - signatures are inserted into the INTRODUCE1 cell, and without them the + signatures are inserted into the INTRODUCE1 message, and without them the introduction to the hidden service cannot be completed. See [INTRO-AUTH]. KP_hsc_intro_auth, KS_hsc_intro_auth. ``` diff --git a/spec/rend-spec/rendezvous-protocol.md b/spec/rend-spec/rendezvous-protocol.md index fbd79a1..2b14934 100644 --- a/spec/rend-spec/rendezvous-protocol.md +++ b/spec/rend-spec/rendezvous-protocol.md @@ -4,10 +4,10 @@ Before connecting to a hidden service, the client first builds a circuit to an arbitrarily chosen Tor node (known as the rendezvous -point), and sends an ESTABLISH_RENDEZVOUS cell. The hidden service -later connects to the same node and sends a RENDEZVOUS cell. Once +point), and sends an ESTABLISH_RENDEZVOUS message. The hidden service +later connects to the same node and sends a RENDEZVOUS message. Once this has occurred, the relay forwards the contents of the RENDEZVOUS -cell to the client, and joins the two circuits together. +message to the client, and joins the two circuits together. Single Onion Services attempt to build a non-anonymous single-hop circuit, but use an anonymous 3-hop circuit if: @@ -24,12 +24,12 @@ but use an anonymous 3-hop circuit if: ## Establishing a rendezvous point {#EST_REND_POINT} The client sends the rendezvous point a RELAY_COMMAND_ESTABLISH_RENDEZVOUS -cell containing a 20-byte value. +message containing a 20-byte value. RENDEZVOUS_COOKIE \[20 bytes\] Rendezvous points MUST ignore any extra bytes in an -ESTABLISH_RENDEZVOUS cell. (Older versions of Tor did not.) +ESTABLISH_RENDEZVOUS message. (Older versions of Tor did not.) The rendezvous cookie is an arbitrary 20-byte value, chosen randomly by the client. The client SHOULD choose a new rendezvous cookie for @@ -37,12 +37,12 @@ each new connection attempt. If the rendezvous cookie is already in use on an existing circuit, the rendezvous point should reject it and destroy the circuit. -Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point associates +Upon receiving an ESTABLISH_RENDEZVOUS message, the rendezvous point associates the cookie with the circuit on which it was sent. It replies to the client -with an empty RENDEZVOUS_ESTABLISHED cell to indicate success. Clients MUST -ignore any extra bytes in a RENDEZVOUS_ESTABLISHED cell. +with an empty RENDEZVOUS_ESTABLISHED message to indicate success. Clients MUST +ignore any extra bytes in a RENDEZVOUS_ESTABLISHED message. -The client MUST NOT use the circuit which sent the cell for any +The client MUST NOT use the circuit which sent the message for any purpose other than rendezvous with the given location-hidden service. The client should establish a rendezvous point BEFORE trying to @@ -53,7 +53,7 @@ connect to a hidden service. ## Joining to a rendezvous point {#JOIN_REND} To complete a rendezvous, the hidden service host builds a circuit to -the rendezvous point and sends a RENDEZVOUS1 cell containing: +the rendezvous point and sends a RENDEZVOUS1 message containing: ```text RENDEZVOUS_COOKIE [20 bytes] @@ -67,10 +67,10 @@ introduction (see \[PROCESS_INTRO2\]) and HANDSHAKE_INFO is defined in If the cookie matches the rendezvous cookie set on any not-yet-connected circuit on the rendezvous point, the rendezvous -point connects the two circuits, and sends a RENDEZVOUS2 cell to the -client containing the HANDSHAKE_INFO field of the RENDEZVOUS1 cell. +point connects the two circuits, and sends a RENDEZVOUS2 message to the +client containing the HANDSHAKE_INFO field of the RENDEZVOUS1 message. -Upon receiving the RENDEZVOUS2 cell, the client verifies that HANDSHAKE_INFO +Upon receiving the RENDEZVOUS2 message, the client verifies that HANDSHAKE_INFO correctly completes a handshake. To do so, the client parses SERVER_PK from HANDSHAKE_INFO and reverses the final operations of section \[NTOR-WITH-EXTRA-DATA\] as shown here: @@ -103,7 +103,7 @@ 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 final S_KEY_LEN bytes form Kb. Excess bytes from K are discarded. -Subsequently, the rendezvous point passes relay cells, unchanged, from each +Subsequently, the rendezvous point passes RELAY cells, unchanged, from each of the two circuits to the other. When Alice's OP sends RELAY cells along the circuit, it authenticates with Df, and encrypts them with the Kf, then with all of the keys for the ORs in Alice's side of the circuit; and when @@ -127,12 +127,12 @@ The behavior of ESTABLISH_RENDEZVOUS is unchanged from older versions of this protocol, except that relays should now ignore unexpected bytes at the end. -Old versions of Tor required that RENDEZVOUS cell payloads be exactly +Old versions of Tor required that RENDEZVOUS message payloads be exactly 168 bytes long. All shorter rendezvous payloads should be padded to this length with random bytes, to make them difficult to distinguish from older protocols at the rendezvous point. 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 +RENDEZVOUS messages. Hence the "HSRend" protocol from proposal#264 should be used to select relays for rendezvous points. diff --git a/spec/rend-spec/text-vectors.md b/spec/rend-spec/text-vectors.md index ad3701b..eadaee2 100644 --- a/spec/rend-spec/text-vectors.md +++ b/spec/rend-spec/text-vectors.md @@ -23,7 +23,7 @@ G.1. Test vectors for hs-ntor / NTOR-WITH-EXTRA-DATA The client wants to make in INTRODUCE request. It generates the following header (everything before the ENCRYPTED portion) - of its INTRODUCE1 cell: + of its INTRODUCE1 message: H = 000000000000000000000000000000000000000002002034E171E4358E501BFF 21ED907E96AC6BFEF697C779D040BBAF49ACC30FC5D21F00 @@ -74,7 +74,7 @@ G.1. Test vectors for hs-ntor / NTOR-WITH-EXTRA-DATA D1A51B7554D8B3692D85AC587FB9E69DF990EFB776D8 ``` -Later the service receives that body in an INTRODUCE2 cell. It +Later the service receives that body in an INTRODUCE2 message. It processes it according to the hs-ntor handshake, and recovers the client's plaintext P. To continue the hs-ntor handshake, the service chooses a curve25519 keypair: @@ -93,7 +93,7 @@ the service chooses a curve25519 keypair: 83402B28CDFD48C8A530A5A3D7D578DB ``` -The service sends back Y | AUTH_INPUT_MAC in its RENDEZVOUS1 cell +The service sends back Y | AUTH_INPUT_MAC in its RENDEZVOUS1 message body. From these, the client finishes the handshake, validates AUTH_INPUT_MAC, and computes the same NTOR_KEY_SEED. |