On Wed, Feb 12, 2014 at 9:42 AM, George Kadianakis <desnac...@riseup.net> wrote: > Nick Mathewson <ni...@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. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev