Apply "cell" and "message" consistently

Done by grepping for "cell" and making sure it was accurate in every
place where it occurs.  In tor-spec, I also searched for "message".

Part of #253.

1 files changed, 62 insertions, 59 deletions

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