[tor-dev] Temporary hidden services

[Michael Rogers]

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?

If we decided not to use the key blinding trick, and just allowed both
parties to know the private key, do you see any attacks?

> I have a separate question wrt the threat model:
> 
> It seems to me that adversary in this game can observe the link, and all
> these stunts are done just for the case where the adversary steals the
> link (i.e. the temporary ECDH public keys).
> 
> In that case, given that both Alice and Bob are completely
> unauthenticated and there is no root trust, how can you ensure that the
> adversary Eve won't perform the ECDH herself, then connect to the
> temporary onion service, and steal the long-term onion service link
> (thereby destroying the secrecy of the long-term onion service for ever,
> even if the attack is detected in the future through Alice and Bob
> communicating in an out-of-band way).
> 
> Are we assuming that Alice and Bob have no common shared-secret in
> place?  Because if they did, then you could use that from the start to
> encrypt the long-term onion service identifier. If you don't, you could
> potentially fall into attacks like the one above.

Great question. We assume the channel over which the links are exchanged
is insecure, so an adversary who can read and modify the channel can
carry out a man-in-the-middle attack as you describe. However, we also
assume there are some adversaries that can read but not modify the
channel, and it's worth protecting against those adversaries even if we
can't protect against stronger ones that can also modify the channel.

A realistic example of a read-only adversary would be one that gets
retrospective access to chat logs.

As you pointed out, modification can potentially be detected later
(although we haven't designed the protocol for doing that yet). I guess
that may help to deter adversaries who don't want to reveal that they
can read and modify the channel.

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/20181017/56a5a68e/attachment.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/20181017/56a5a68e/attachment.sig>