>They both require authentication, Yeah, but not the same *sort* of authentication. As a trivial example, you could have ten servers that sign long-term keys for nodes. All that they need to check is that the node requesting a signature owns the corresponding IP address. On the other hand, 'evil nodes' is a subjective quality that is hard to assess automatically.
>and if you intend to connect to potentially evil nodes you aren't securing >anything Bitcoin is designed with the assumption that some of the nodes you connect to might be evil. Sure, if 100% of the nodes you're connected to are evil, you're screwed. However, we shouldn't avoid protecting people from someone on the same coffee-shop network, just because the same mitigation won't work against a nation-state. On Tue, Jun 28, 2016 at 5:29 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > Your description of the two scenarios reduces to one. They both require > authentication, and if you intend to connect to potentially evil nodes you > aren't securing anything with link level security except the knowledge that > your potentially evil node connection remains so. > > e > > On Jun 29, 2016, at 12:33 AM, Cameron Garnham <da2...@gmail.com> wrote: > > > There are two different topics mixed up here. > > 1. Link-level security (secure connection to the node we intended to connect > to). > > 2. Node-level security (aka; don't connect to a 'evil node'). > > The fist requires link-level encryption and authentication. > > The second requires identity authentication. > > You described the 'evil node' attack; that indeed needs an identity system > to stop. However BIP151 doesn't intend to protect against connecting to evil > Bitcoin Nodes. > > It is important not to mixup link-level authentication and node-level > authentication. > > When your client picks random nodes to connect to, you are not considered > whom in particular runs them. (Rather that you have a good random sample of > the network). > > If you manually add a friends node; at this point you wish to have > node-level authentication. However, this may (and probably should) happen > out-of-band. > > > Sent from my iPhone > > On 29 Jun 2016, at 01:07, Eric Voskuil <e...@voskuil.org> wrote: > > Hi Cameron, good to hear from you! > > On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2...@gmail.com> wrote: > > Unauthenticated link level encryption is wonderful! MITM attacks are > overrated; as they require an active attacker. > > > This is not really the case with Bitcoin. A MITM attack does not require > that the attacker find a way to inject traffic into the communication > between nodes. Peers will connect to the attacker directly, or accept > connections directly from it. Such attacks can be easier than even passive > attacks. > > Stopping passive attacks is the low hanging fruit. This should be taken > first. > > Automated and secure peer authentication in a mesh network is a huge topic. > One of the unsolved problems in computer science. > > A simple 'who is that' by asking for the fingerprint of your peers from your > other peers is a very simple way to get 'some' authentication. Semi-trusted > index nodes also is a low hanging fruit for authentication. > > > It is the implication of widespread authentication that is at issue. Clearly > there are ways to implement it using a secure side channels. > > However, let's first get unauthenticated encryption. Force the attackers to > use active attacks. (That are thousands times more costly to couduct). > > Sent from my iPhone > > On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > An "out of band key check" is not part of BIP151. > > > It has a session ID for this purpose. > > It requires a secure channel and is authentication. So BIP151 doesn't > provide the tools to detect an attack, that requires authentication. A > general requirement for authentication is the issue I have raised. > > > One might wonder how you ever use a Bitcoin address, or even why we > might guess these emails from "you" aren't actually coming from the > NSA. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
