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

[Nick Mathewson]

On Wed, Feb 12, 2014 at 9:42 AM, George Kadianakis <desnacked at riseup.net> wrote:
> 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?

I don't understand the question.

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

No.  It's supposed to be compatible with it, though, to the extent
that the first bytes of the cell identify the key in use in both
cases.

I've added:
   (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.)


>>    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?

Yes.

> 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?

Note that the new encryption mechanism is supposed to be
non-malleable; the MAC is supposed to cover all of the INTRODUCE1
cell.