Re: [tor-dev] Temporary hidden services

[Chad Retz <chad.retz@xxxxxxxxx>]

I am no expert here, but I'm confused by "the client connecting to the
service knows the service's private key". Why not just create an onion
service (per contact) and then use the client authentication feature
to ensure they share the same secret? Client auth is built in to
discovery and from what I understand, retains anonymity of the owner.
Also, why derive the hidden service key pair from the shared secret
instead of having the sender provide the address based on a privately
derived key pair? To your primary question, I to would like to know
that, given the private key of an onion service, the anonymity of the
original publisher is maintained. I would guess that it is (granted
they can overwrite the descriptor and take it over and what not).

Chad
On Thu, Sep 27, 2018 at 8:26 AM Michael Rogers <michael@xxxxxxxxxxxxxxxx> wrote:
>
> Hi all,
>
> The Briar team is working on a way for users to add each other as
> contacts by exchanging links without having to meet in person.
>
> We don't want to include the address of the user's long-term Tor hidden
> service in the link, as we assume the link may be observed by an
> adversary, who would then be able to use the availability of the hidden
> service to tell whether the user was online at any future time.
>
> We're considering two solutions to this issue. The first is to use a
> temporary hidden service that's discarded after, say, 24 hours. The
> address of the temporary hidden service is included in the link. This
> limits the window during which the user's activity is exposed to an
> adversary who observes the link, but it also requires the contact to use
> the link before it expires.
>
> The second solution is to include an ECDH public key in the link,
> exchange links with the contact, and derive a hidden service key pair
> from the shared secret. The key pair is known to both the user and the
> contact. One of them publishes the hidden service, the other connects to
> it. They exchange long-term hidden service addresses via the temporary
> hidden service, which is then discarded.
>
> The advantage of the second solution is that the user's link is static -
> it doesn't expire and can be shared with any number of contacts. A
> different shared secret, and thus a different temporary hidden service,
> is used for adding each contact.
>
> But using a hidden service in such a way that the client connecting to
> the service knows the service's private key is clearly a departure from
> the normal way of doing things. So before pursuing this idea I wanted to
> check whether it's safe, in the sense that the hidden service still
> conceals its owner's identity from the client.
>
> Attacks against the availability of the service (such as uploading a
> different descriptor) are pointless in this scenario because the client
> is the only one who would connect to the service anyway. So I'm just
> interested in attacks against anonymity.
>
> Can anyone shed any light on this question? Or is this way of using
> hidden services too disgusting to even discuss? :-)
>
> Thanks,
> Michael
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev