public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil•org>
To: Cameron Garnham <da2ce7@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Wed, 29 Jun 2016 01:29:10 +0200	[thread overview]
Message-ID: <2DC6C84C-5FE1-4908-B50B-47C6BF928A1C@voskuil.org> (raw)
In-Reply-To: <E1CB43A4-F13D-4109-AB05-DDD650FEC0C9@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3678 bytes --]

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 <da2ce7@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 <eric@voskuil•org> wrote:
>> 
>> Hi Cameron, good to hear from you!
>> 
>>> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@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

[-- Attachment #2: Type: text/html, Size: 6373 bytes --]

  reply	other threads:[~2016-06-28 23:29 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-28  2:31 [bitcoin-dev] BIP 151 use of HMAC_SHA512 Rusty Russell
2016-06-28  7:17 ` [bitcoin-dev] BIP 151 Eric Voskuil
2016-06-28  8:26   ` Jonas Schnelli
2016-06-28 16:45     ` Eric Voskuil
2016-06-28 18:22       ` Peter Todd
2016-06-28 18:35         ` Eric Voskuil
2016-06-28 20:14           ` Peter Todd
2016-06-28 20:29             ` Eric Voskuil
2016-06-28 20:36               ` Peter Todd
2016-06-28 21:22                 ` Eric Voskuil
2016-06-28 21:36                   ` Gregory Maxwell
2016-06-28 21:40                     ` Cameron Garnham
2016-06-28 22:07                       ` Eric Voskuil
2016-06-28 22:33                         ` Cameron Garnham
2016-06-28 23:29                           ` Eric Voskuil [this message]
2016-06-29  0:06                             ` Nick ODell
2016-06-28 21:59                     ` Eric Voskuil
     [not found]                       ` <CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>
2016-06-28 23:34                         ` Eric Voskuil
2016-06-28 20:06       ` Jonas Schnelli
2016-06-28 23:31         ` Eric Voskuil
2016-06-29 11:17       ` Alfie John
2016-06-30 11:56         ` Eric Voskuil
2016-06-30 12:20           ` Jonas Schnelli
2016-06-30 12:27             ` Eric Voskuil
2016-06-30 12:43               ` Jonas Schnelli
2016-06-30 15:22                 ` Eric Voskuil
2016-06-30 16:52                   ` Peter Todd
2016-06-30 18:25                     ` Eric Voskuil
2016-06-30 19:06                       ` Peter Todd
2016-06-30 20:26                         ` Eric Voskuil
2016-06-28 19:55     ` Gregory Maxwell
2016-06-28 23:33       ` Eric Voskuil
2016-06-29  1:01         ` Gregory Maxwell
2016-06-30  9:57           ` Eric Voskuil
2016-06-30 13:03             ` Pieter Wuille
2016-06-30 15:10               ` Eric Voskuil
2016-08-31 14:29                 ` Pieter Wuille
2016-06-30 13:36             ` Erik Aronesty
2016-06-30 14:47               ` Alfie John
2016-07-02  9:44               ` Chris Priest
2016-06-28 12:13   ` Jonas Schnelli
2016-06-28 17:39     ` Eric Voskuil
2016-06-28  7:19 ` [bitcoin-dev] BIP 151 use of HMAC_SHA512 Jonas Schnelli
2016-06-28  8:31   ` Arthur Chen
2016-06-29 18:34     ` Jonas Schnelli
2016-06-29 20:13       ` Peter Todd
2016-06-29 20:31         ` Jonas Schnelli
2016-06-29  1:00   ` Rusty Russell
2016-06-29  1:38     ` Arthur Chen
2016-06-29  1:56     ` Ethan Heilman
2016-06-29  6:58       ` Pieter Wuille
2016-06-29 14:38         ` Ethan Heilman
2016-06-29 18:46           ` Jonas Schnelli
2016-07-01  3:25       ` Rusty Russell
2016-07-01 22:42         ` Zooko Wilcox
2016-07-04  1:23           ` Arthur Chen
2016-07-04  1:44             ` Arthur Chen
2016-07-04  6:47               ` Jonas Schnelli
2016-07-04  6:37           ` Jonas Schnelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2DC6C84C-5FE1-4908-B50B-47C6BF928A1C@voskuil.org \
    --to=eric@voskuil$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=da2ce7@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox