[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Temporary hidden services
On Thu, Sep 27, 2018 at 9: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.
Here's a third idea to think about: What if you use the same key
derivation trick we use in v3 onion services?
That is, every user could have a long term private key x and a public
key g^x. If the user with key g^x wants to allow a user with g^y to
meet them with them, they derive s=h( g^xy) as the shared secret...
but instead of using s as a private key, they do the key derivation
trick, so that the single-use public key is derived as (g^x)*(g^s) =
g^(x+s), and the single use secret key is derived as (x + s). This
way, each of them winds up with a private/public keypair for use with
the other; each user is the only one that knows their private key; and
the two of them are the only ones who can derive the public key.
You could do this in Tor's v3 onion-service design as-is: Just put
h(g^xy) as the the "optional secret s" input when deriving the daily
key.
For more info on this key derivation mechanism, see rend-spec-v3.txt,
appendix A.
(Warning: I am not a cryptographer; I haven't thought about this idea
very hard yet.)
peace,
--
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev