prop224: Switch back to a TYPE/LEN/KEY construction for cells.

   themselves, but over those strings prefixed with a distinguishing

   value.

   Through this proposal we use the following construction when sending

   cryptographic keys in tor cells:

        KEYTYPE         [1 byte]

        KEY             [depends on KEYTYPE]

   In this case the size of the KEY depends on the KEYTYPE. Here are the

   currently defined key types:

     * The KEYTYPE value [01] is for Ed25519 keys (size: 32 bytes).

     * The KEYTYPE value [02] is for Curve25519 keys (size: 32 bytes).

     * The KEYTYPE value [03] is for truncated Curve25519 keys (size: 8 bytes).

0.4. Protocol building blocks [BUILDING-BLOCKS]

   In sections below, we need to transmit the locations and identities

   An INTRODUCE1 cell has the following contents:

     AUTH_KEYTYPE    [1 byte]

     AUTH_KEYID      [depends on AUTH_KEYTYPE]

     ENC_KEYTYPE     [1 byte]

     ENC_KEYID       [depends on ENC_KEYTYPE]

     AUTH_KEY_TYPE   [1 byte]

     AUTH_KEY_LEN    [1 byte]

     AUTH_KEY        [AUTH_KEY_LEN bytes]

     ENC_KEY_TYPE    [1 byte]

     ENC_KEY_LEN     [1 byte]

     ENC_KEY         [ENC_KEY_LEN bytes]

     N_EXTENSIONS    [1 byte]

     N_EXTENSIONS times:

       EXT_FIELD_TYPE [1 byte]

   encryption method? The latter is probably safer.]

   Upon receiving an INTRODUCE1 cell, the introduction point checks

   whether AUTH_KEYID and ENC_KEYID match a configured introduction

   whether AUTH_KEY and ENC_KEY match a configured introduction

   point authentication key and introduction point encryption key.  If

   they do, the cell is relayed; if not, it is not.

   (After checking AUTH_KEYID and ENC_KEYID and finding no match, the

   introduction point should check to see whether a legacy hidden service is

   running whose PK_ID is the first 20 bytes of AUTH_KEYID.  If so, it

   behaves as in rend-spec.txt.)

   (After checking AUTH_KEY and ENC_KEY and finding no match, the introduction

   point should check to see whether a legacy hidden service is running whose

   PK_ID is the first 20 bytes of AUTH_KEY.  If so, it behaves as in

   rend-spec.txt.)

   The AUTH_KEYTYPE is an Ed25519 public key (value [01]).

   The AUTH_KEY_TYPE is an Ed25519 public key (value [01]).

   The ENC_KEYTYPE is a truncated Curve25519 public key (value [03]). (This key

   The ENC_KEY_TYPE is a truncated Curve25519 public key (value [03]). (This key

   is safe to truncate, since all the keys are generated by the hidden service

   host, and the ID is only valid relative to a single AUTH_KEYID.)  The

   host, and the ID is only valid relative to a single AUTH_KEY.)  The

   ENCRYPTED field is as described in 3.3 below.

   To relay an INTRODUCE1 cell, the introduction point sends an

          EXT_FIELD_LEN                          [1 byte]

          EXT_FIELD                              [EXT_FIELD_LEN bytes]

      ONION_KEY_TYPE                             [1 bytes]

      ONION_KEY                                  [depends on ONION_KEY_TYPE]

      ONION_KEY_LEN                              [1 bytes]

      ONION_KEY                                  [ONION_KEY_LEN bytes]

      NSPEC      (Number of link specifiers)     [1 byte]

      NSPEC times:

          LSTYPE (Link specifier type)           [1 byte]

   Substituting those fields into the INTRODUCE1 cell body format

   described in [FMT_INTRO1] above, we have

            AUTH_KEYTYPE                [1 byte]

            AUTH_KEYID                  [depends on AUTH_KEYTYPE]

            ENC_KEYTYPE                 [1 byte]

            ENC_KEYID                   [depends on ENC_KEYTYPE]

            AUTH_KEY_TYPE               [1 byte]

            AUTH_KEY_LEN                [1 byte]

            AUTH_KEY                    [AUTH_KEY_LEN bytes]

            ENC_KEY_TYPE                [1 byte]

            ENC_KEY_LEN                 [1 byte]

            ENC_KEY                     [ENC_KEY_LEN bytes]

            N_EXTENSIONS                [1 bytes]

            N_EXTENSIONS times:

               EXT_FIELD_TYPE           [1 byte]

   described in [LEGACY-INTRODUCE1].)

   Here, the encryption key plays the role of B in the regular ntor

   handshake, and the AUTH_KEYID field plays the role of the node ID.

   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_KEYID through the

   MAC field is a MAC of all of the cell 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)