[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 asn):

 OK, code architecture question here:

 I'm working on the intro point code for ESTABLISH_INTRO. I'm now at the
 part where I need to connect intro circuits with auth keys. This is done
 so that when a client comes with an auth key, we can easily find the right
 circuit.

 This is currently done with functions `circuit_set_intro_point_digest()`
 and `circuit_clear_rend_token()` using the `digestmap_t`
 `intro_digest_map`.

 However, for prop224 I suspect it's bad form to use a SHA1 `digestmap_t`
 for storing ed25519 keys, so I'm trying to figure out what to do.

 Here are some approaches:

   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.

 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?

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