[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Onioncat and Tor Hidden Services V3

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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk