[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