Michael Rogers michael@briarproject.org writes:
On 18/10/2018 13:26, George Kadianakis wrote:
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.
Thanks, that confirms my reservations about converting between ECDH and EdDSA keys, especially when we don't fully control what each key will be used for. I think we'd better hold off on that approach unless/until the crypto community comes up with idiot-proof instructions.
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.
Nice! Link size aside, that sounds like it ought to work.
A given user's temporary hidden service addresses would all be related to each other in the sense of being derived from the same root Ed25519 key pair. If I understand right, the security proof for the key blinding scheme says the blinded keys are unlinkable from the point of view of someone who doesn't know the root public key (and obviously that's a property the original use of key blinding requires). I don't think the proof says whether the keys are unlinkable from the point of view of someone who does know the root public key, but doesn't know the blinding factors (which would apply to the link-reading adversary in this case, and also to each contact who received a link). It seem like common sense that you can't use the root key (and one blinding factor, in the case of a contact) to find or distinguish other blinded keys without knowing the corresponding blinding factors. But what seems like common sense to me doesn't count for much in crypto...
Hm, where did you get this about the security proof? The only security proof I know of is https://www-users.cs.umn.edu/~hoppernj/basic-proof.pdf and I don't see that assumption anywhere in there, but it's also been a long while since I read it.
I think in general you are OK here. An informal argument: according to rend-spec-v3.txt appendix A.2 the key derivation is as follows:
derived private key: a' = h a (mod l) derived public key: A' = h A = (h a) B
In your case, the attacker does not know 'h' (the blinding factor), whereas in the case of onion service the attacker does not know 'a' or 'a*B' (the private/public key). In both cases, the attacker is missing knowledge of a secret scalar, so it does not seem to make a difference which scalar the attacker does not know.
Of course, the above is super informal, and I'm not a cryptographer, yada yada.
We'd also have to be careful about the number of blinded keys generated from a given root key. The security proof uses T = 2^16 as an example for the maximum number of epochs, giving a 16-bit security loss vs normal Ed25519. In this scheme T would be the maximum number of contacts rather than epochs. 2^16 is more than enough for the current context, where contacts are added manually, but we'd have to bear in mind that it wouldn't be safe to use this for automatic exchanges initiated by other parties.
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.
Messy? Yeah, welcome to P2P. ;-)
We're testing a prototype of the UX at the moment.
Bringing up the hidden service tends to take around 30 seconds, which is a long time if you make the user sit there and watch a progress wheel, but not too bad if you let them go away and do other things until a notification tells them it's done.
Of course that's the happy path, where the contact's online and has already opened the user's link. If the contact sent their link and then went offline, the user has to wait for them to come back online. So we keep a list of pending contact requests and show the status for each one. After some time, perhaps 7 days, we stop trying to connect and mark the contact request as failed.
Yeah, I don't think a progress wheel is what you want here. You probably want a greyed out contact saying "Contact pending..." like in the case of adding a contact in Ricochet.
(In my first email I mentioned an alternative approach, where we set up a temporary hidden service in advance and just send its address in the link, which expires after 24 hours. In that case we can shave 30 seconds off the happy path, but we need to work out the UX for explaining that links will expire and dealing with expired links. So there are pros and cons to both approaches.)