Michael Rogers michael@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!