[tor-dev] Temporary hidden services

[George Kadianakis]

Michael Rogers <michael at briarproject.org> writes:

> Hi George,
>
> On 15/10/2018 19:11, George Kadianakis wrote:
>> Nick's trick seems like a reasonable way to avoid the issue with both parties
>> knowing the private key.
>
> Thanks! Good to know. Any thoughts about how to handle the conversion
> between ECDH and EdDSA keys?
>

Hmm, that's a tricky topic! Using the same x25519 keypair for DH and
signing is something that should be done only under supervision by a
proper cryptographer(tm). I'm not a proper cryptographer so I'm
literally unable to evaluate whether doing it in your case would be
secure. If it's possible I would avoid it altogether...

I think one of the issues is that when you transform your x25519 DH key
to an ed25519 key and use it for signing, if the attacker is able to
choose what you sign, the resulting signature will basically provide a
DH oracle to the attacker, which can result in your privkey getting
completely pwned. We actually do this x25519<->ed255519 conversion for
onionkeys cross-certificates (proposal228) but we had the design
carefully reviewed by people who know what's going on (unlike me).

In your case, the resulting ed25519 key would be used to sign the
temporary HS descriptor. The HS descriptor is of course not entirely
attacker-controlled data, but part of it *could be considered* attacker
controlled (e.g. the encrypted introduction points), and I really don't
know whether security can be impacted in this case. Also there might be
other attacks that I'm unaware of... Again, you need a proper
cryptographer for this.

A cheap way to avoid this, might be to include both an x25519 and an
ed25519 key in the "link" you send to the other person. You use the
x25519 key to do the DH and derive the shared secret, and then both
parties use the shared secret to blind the ed25519 key and derive the
blinded (aka hierarchically key derived) temporary onion service
address... Maybe that works for you but it will increase the link size
to double, which might impact UX.

And talking about UX, this is definitely a messy protocol UX-wise. One
person has to wait for the other person to start up a temporary HS. What
happens if the HS never comes up? Every when does the other person check
for the HS? How long does the first person keep the HS up? You can
probably hide all these details on the UI, but it still seems like a
messy situation.

I think the easiest approach here would be to just encrypt the permanent
onion address to the other person using a pre-shared-secret, but I guess
your protocol assumes that the two participants don't really know each other...

Good luck! :)