#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs