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

[Tor Bug Tracker & Wiki]

#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                                  |
Parent ID:  #17241                               |         Points:  3
 Reviewer:  asn, dgoulet                         |        Sponsor:
                                                 |  SponsorR-must
-------------------------------------------------+-------------------------

Comment (by dgoulet):

 Replying to [comment:13 asn]:
 >   a) Just define two more global maps that will store the prop224 rend
 circuit information. This is the cheap approach, since it's quite easy to
 implement. FWIW, we need two maps: one to store intro point circuit info,
 and another to store the rend cookies.
 >
 >   The downside here is that we are then left with maintaining 4 of those
 maps (two for old system, two for new system) which might become hairy.
 >
 >   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 seems like an approach that will be easier to maintain since we
 will only have two functions and data structures, instead of four.
 However, it's not a trivial refactoring. For example, we should be careful
 to not use new-style keys with clients trying to connect to old-style
 intro points.

 Hrm, I see `circuit_set_intro_point_digest` being called at only one place
 and `circuit_get_intro_point` two places. Very few call sites. I like the
 idea of using the same data structure and interface for this (with already
 working code). Refactoring to a `digest256map` with
 sha256(old_current_digest) and ed25519 keys sounds like a win. The only
 thing we would want I presume is a "flag" for the above function that is
 "Oh this is a old digest" or "New digest, do not hash".

 Heck, we could even "sha256(digest)" in `rend_mid_establish_intro()` and
 do directly the query with this instead of passing a flag. In that
 function, `pk_digest` is _only_ used for getting the intro points so we
 can just adapt it to a sha256 prior. Same goes for `rend_mid_introduce()`,
 hash and then call. Those functions will be deleted months/years after 224
 so adding code there is a better idea imo than adding code to the
 `circuit_` API that will actually be kept after.

 Another idea, we can add two functions that specifically only takes the
 old digest, sha256 it and then call the circuit interface
 (`circuit_set_intro_point_digest`). As long as those functions are "old
 HS" specific though and not making them part of the circuit API.

 >
 > Side question: Do we have a `digestmap_t` that can hold ed25519 keys?
 Can I just use `digest256map_t` for that since ed25519 keys are 32bytes
 anyway?

 Yes `digest256map_t` is what you want here.

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