On Thu, Sep 27, 2018 at 9:26 AM Michael Rogers michael@briarproject.org 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,