Hi Chad,
On 27/09/2018 20:02, Chad Retz wrote:
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.
Creating an onion service per contact would be a possibility, and although some information about the user's online and offline periods would still be leaked to an adversary who observed the link, via the publication and renewal of the hidden service descriptor, I think you're right that client auth would reduce the leakage by preventing the adversary from connecting to the service to test whether it was online at any given moment. Thanks for the suggestion!
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?
I admit it's a weird way of doing things. The shared secret approach allows the user to use the same link for all contacts over a long period, without exposing a long-term hidden service address to an adversary who observes the links.
This has some advantages, such as being able to publish your link via multiple channels (email sig, social media profile, etc) that recipients can check to increase their confidence that they've received your authentic link.
On the other hand, time-limited or single-use links are less likely to become surveillance selectors in their own right, and the "key fingerprints on business cards" pattern has never really caught on. So there are pros and cons to both approaches.
Cheers, Michael
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@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.
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev