[tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor

[George Kadianakis]

Nick Mathewson <nickm at torproject.org> writes:

> Hi, all!
>
> <snipz>
>
> 3.2.3. Legacy formats [LEGACY-INTRODUCE1]
>
>    When the ESTABLISH_INTRO cell format of [LEGACY_EST_INTRO] is used,
>    INTRODUCE1 cells are of the form:
>
>      AUTH_KEYID_HASH  [20 bytes]
>      ENC_KEYID        [8 bytes]
>      Any number of times:
>        EXT_FIELD_TYPE [1 byte]
>        EXT_FIELD_LEN  [1 byte]
>        EXT_FIELD      [EXTRA_FIELD_LEN bytes]
>      ZERO             [1 byte]
>      ENCRYPTED        [Up to end of relay payload]
>

What is this cell format? Is this supposed to match the format of the
legacy INTRODUCE1 from rend-spec.txt?

>    Here, AUTH_KEYID_HASH is the hash of the introduction point
>    authentication key used to establish the introduction.
>
>    Because of limitations in older versions of Tor, the relay payload
>    size for these INTRODUCE1 cells must always be at least 246 bytes, or
>    they will be rejected as invalid.
>
> 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2]
>
>    Upon receiving an INTRODUCE2 cell, the hidden service host checks
>    whether the AUTH_KEYID/AUTH_KEYID_HASH field and the ENC_KEYID fields
>    are as expected, and match the configured authentication and
>    encryption key(s) on that circuit.
>
>    The service host then checks whether it has received a cell with
>    these contents before. If it has, it silently drops it as a
>    replay. (It must maintain a replay cache for as long as it accepts
>    cells with the same encryption key.)
>

Hm, which parts of the cell is the HS supposed to save in its replay
cache? Is it the whole cell?

If it's the whole cell, should we be careful of the malleability of
AES-CTR, where the IP can tweak a bit of the ciphertext and get past
the replay cache?

>    If the cell 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
>    client. There may be multiple ways of decrypting the ENCRYTPED field,
>    depending on the chosen type of the encryption key. Requirements for
>    an introduction handshake protocol are described in
>    [INTRO-HANDSHAKE-REQS]. We specify one below in section
>    [NTOR-WITH-EXTRA-DATA].
>