[tor-dev] Temporary hidden services

[Michael Rogers]

On 28/09/2018 02:40, Nick Mathewson wrote:
> On Thu, Sep 27, 2018 at 9:26 AM Michael Rogers <michael at 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.)

Hi Nick,

This is a really interesting idea, thanks. I'm kicking myself because we
tried to come up with a way to derive a key pair such that the user gets
the private key and the contact gets the public key, and we couldn't
come up with anything - but it's already there as part of the HS design!

However, I'm much further away from being a cryptographer than you are,
and there are aspects of this that definitely go beyond my expertise.

The biggest one is that the user and her contact need to start with ECDH
key pairs (in order to derive a shared secret) and end up with an
Ed25519 key pair (in order to use it for a hidden service), whereas the
v3 key blinding scheme starts and ends with Ed21159 key pairs. I believe
there are ways to convert between X25519 and Ed25519 keys, but I don't
know what caveats would come with doing that, especially considering
that we want to reuse the DH keys for other exchanges.

I understand that the Tor devs are at a meeting this week, but hoping to
pick this up when you get back.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 15862 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20181001/03e37aec/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20181001/03e37aec/attachment-0001.sig>