> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli <d...@jonasschnelli.ch> wrote: > >>>> The core problem posed by BIP151 is a MITM attack. The implied solution >>>> (BIP151 + authentication) requires that a peer trusts that another is not >>>> an attacker. >>> >>> BIP151 would increase the risks for MITM attackers. >>> What are the benefits for Mallory of he can't be sure Alice and Bob may >>> know that he is intercepting the channel? >> >> It is not clear to me why you believe an attack on privacy by an anonymous >> peer is detectable. > > If Mallory has substituted the ephemeral keys in both directions, at the > point where Alice and Bob will do an authentication, they can be sure > Mallory is listening.
I understand the mechanics of a tunnel between trusting parties that have a secure side channel. But this assumes that no other peer can connect to these two nodes. How then do they maintain the chain? The "middle" in this sense does not have to be the wire directly between these two peers. It can be between either of them and any anonymous connection they (must) allow. Of course this creates pressure to expand their tunnel. Hence the problem of expanding node identity in an effort to preserve privacy. The protection will remain weak until the entire network is "secure". At that point it would necessarily be a private network. As Pieter rightly observes, there are and always will be tunnels between trusting nodes. Often these are groups of nodes that are in collaboration, so logically they are one node from a system security standpoint. But if people become generally reliant on good node registration, it will become the registrar who controls access to the network. So my concern rests I this proposal becoming widely adopted. > Simple dummy example: > 1.) Encryption setup with ECDH with ephemeral keys after BIP151 > 2.) Mallory is MITMling the connection. He is substituting both direction > with its own keys > 3.) Connection is successfully MITMled > 4.) Alice tells Bob "prove me that you are Bob, please sign the session-ID > with your identity key" > 5.) Bob signs the sessionID (ECDH secret) with his identity key which > will be unusable for Mallory who has a substituted sessionID in both > directions. > 6.) Alice has successfully detected the Mallory > > Disclaimer: 4) and 5) are _not_ authentication proposals :-) > > </jonas> > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
