On 02.12.19 09:55, grarpamp wrote: > > Either HSv2 support must not be allowed to go away, > or onioncat must be made to work with HSv3. > Otherwise tor permanently loses a major onionland capability. >
Definitely. For v3 to integrate smoothly into OnionCat (and similar services), any kind of external mapping database is necessary (as I already mentioned in an earlier post). I suggest 2 possible options: 1) Integrate v2->v3 lookup mechanism (I call it hs descriptor v2a) into the HS directory. It should be like a v2 descriptor, but containing the v3 public id and being signed by the v3 key, which is found in the according v3 desriptor. 2) We implement any new database which offers such a lookup facility. This option has several disadvantages: a) it works only if there is a sufficient number of such databases up, and b) it's a little bit like reinventing the wheel. The V2a procedure could look like the following: 1) The V3 service creates a V3 descriptor and publishes it into the HS dir as usual. 2) The v3 service creates a V2a descriptor which is the following: V2a-id ... 80-bit truncated v3 public id (v3-id -> v2a-id = trunc80(v3-id) ) V3-id.... The full V3 id sig ... Digital signature of all fields above, created with the v3 private key. 3) Publish the V2a descriptor in the HS dir with the v2a-id being the primary key. The V2a lookup should work as follows 1) Client has v2a-id (e.g. OnionCat, derived from IP address) 2) lookup V2a-id in HS dir and retrieve v2a descriptor 3) lookup and retrieve V3 descriptor in HS dir which was found in v2a descriptor 4) check signaturs of V3 and V2a descriptor. 5) connect to V3 HS Best regards, Bernhard -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
