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@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. >> >> 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@xxxxxxxxxxxxxxxxxxxx >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >
Attachment:
0x11044FD19FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev