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
Attachment:
0x11044FD19FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev