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