[tor-dev] Temporary hidden services

[George Kadianakis]

Michael Rogers <michael at briarproject.org> writes:

> 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.
>

Hello Michael,

Nick's trick seems like a reasonable way to avoid the issue with both parties
knowing the private key.

I have a separate question wrt the threat model:

It seems to me that adversary in this game can observe the link, and all
these stunts are done just for the case where the adversary steals the
link (i.e. the temporary ECDH public keys).

In that case, given that both Alice and Bob are completely
unauthenticated and there is no root trust, how can you ensure that the
adversary Eve won't perform the ECDH herself, then connect to the
temporary onion service, and steal the long-term onion service link
(thereby destroying the secrecy of the long-term onion service for ever,
even if the attack is detected in the future through Alice and Bob
communicating in an out-of-band way).

Are we assuming that Alice and Bob have no common shared-secret in
place?  Because if they did, then you could use that from the start to
encrypt the long-term onion service identifier. If you don't, you could
potentially fall into attacks like the one above.

Cheers!