[tor-dev] Temporary hidden services

[Michael Rogers]

On 18/10/2018 13:26, George Kadianakis wrote:
> 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.

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...

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.

(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.)

> 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...

Sure, a pre-shared secret would solve all our problems, but the use case
here is adding contacts without meeting in person. We already have a
completely different, equally messy UX for users who can meet face to
face. ;-)

> Good luck! :)

Thanks!

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 16659 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20181019/b8265eb1/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/20181019/b8265eb1/attachment-0001.sig>