[tor-bugs] #19043 [Core Tor/Tor]: Implementation of prop224 ESTABLISH_INTRO cell

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Aug 11 10:46:34 UTC 2016


#19043: Implementation of prop224 ESTABLISH_INTRO cell
-------------------------------------------------+-------------------------
 Reporter:  alec.heif                            |          Owner:
     Type:  enhancement                          |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.2.???
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, prop224, 6.s194,             |  Actual Points:
  0210-proposed, TorCoreTeam201608               |
Parent ID:  #17241                               |         Points:  3
 Reviewer:  asn, dgoulet                         |        Sponsor:
                                                 |  SponsorR-must
-------------------------------------------------+-------------------------

Comment (by asn):

 Replying to [comment:15 nickm]:
 > Replying to [comment:13 asn]:
 > >   b) Somehow refactor the current system so that we can do both old-
 style and prop224 mappings using the same data structure. For example, we
 could hash the old-style keys with sha256 and store them in a digest256
 map, and do the same for new style keys as well (or just store the keys
 intact since they are 32bytes).
 >
 > This is what I'd suggest.  I'd suggest an underlying data structure
 mapping a tagged structure to a circuit pointer.  If you use the handle
 and the ht code, it should actually be easy.
 >
 > Then you can define all the accessor functions, to actually make the
 code safer.

 Hm, I'm very unfamiliar with the `HT_` and `HANDLE_` code, but I'm
 definitely willing to get my hands dirty if this is the right way to do
 this. I'll start studying the `HT_PROTOTYPE` and `HT_GENERATE2` functions.

 BTW, the idea here is that we want to create a new map that maps from all
 sorts of HS tokens (`hs_token_t`) to circuits. Right? An `hs_token_t` in
 this case can hold both old-style and new-style tokens for both
 introduction and rendezvous.

 For example here is a data structure definition:
 {{{
 /** Represents a token used in the HS protocol. Each such token maps to a
  *  specific introduction or rendezvous circuit. */
 typedef struct hs_token_t {
   /* The HS protocol version that uses this token.
    *
    * The version value is 2 for the old HS version, and 3 for next
 generation
    * hidden services.
    *
    * The size of the hs_token depends on the HS protocol version and the
 type
    * of token:
    *  Old HS protocol uses 128bit tokens for introduction and rendezvous.
    *  New HS protocol uses 128bit tokens for rendezvous, and 256bit tokens
 for
    *  introductions. */
   int version;

   /* Is this a rendezvous cookie? Otherwise, it's an introduction token.
 */
   int is_rend_token;

   /* The token itself. Memory allocated at runtime depending on the HS
 version. */
   uint8_t *hs_token;
 }
 }}}

 Does this look reasonable to you?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19043#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list