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

Comment (by asn):

 Note: #19896 is relevant here

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

Comment (by dgoulet):

 My two cents. I like the idea very much. Scales much better with future
 version. We can have a single version agnostic function that takes the
 token and re-route it to the right function.

 Yes, tokens have different size depending on the version (well except rdv
 token but that might not be true for version 4 and onward). I would add an
 `enum` of the possible type (in this case only two exists) which will
 makes it nicer if we ever add more types. And the token length as well.
 You might also want to put a `or_circuit_t` in there? :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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, 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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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, TorCoreTeam201608   |
Parent ID:  #17241   | Points:  3
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-
Changes (by asn):

 * keywords:  tor-hs, prop224, 6.s194, 0210-proposed => tor-hs, prop224,
 6.s194, 0210-proposed, TorCoreTeam201608


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.???
 Keywords:  tor-hs, prop224, 6.s194, |Version:
  0210-proposed  | Resolution:
Parent ID:  #17241   |  Actual Points:
 Reviewer:  asn, dgoulet | Points:  3
 |Sponsor:
 |  SponsorR-must
-+-
Changes (by asn):

 * keywords:  tor-hs, prop224, 6.s194, sponsorr-0.2.10 => tor-hs, prop224,
 6.s194, 0210-proposed


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.???
 Keywords:  tor-hs, prop224, 6.s194, |Version:
  sponsorr-0.2.10| Resolution:
Parent ID:  #17241   |  Actual Points:
 Reviewer:  asn, dgoulet | Points:  3
 |Sponsor:
 |  SponsorR-must
-+-
Changes (by asn):

 * keywords:  tor-hs, prop224, 6.s194 => tor-hs, prop224, 6.s194,
 sponsorr-0.2.10
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.2.???


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194  |  Actual Points:
Parent ID:  #17241   | Points:  3
 Reviewer:  asn, dgoulet |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

 * points:   => 3


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19043 [Core Tor/Tor]: Implementation of prop224 ESTABLISH_INTRO cell (was: Implementation of Proposal 224 Section 3.1)

[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.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194  |  Actual Points:
Parent ID:  #17241   | Points:
 Reviewer:  asn, dgoulet |Sponsor:  SponsorR-must
-+

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs