diff options
| author | Eric Voskuil <eric@voskuil.org> | 2016-06-30 17:22:08 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-06-30 15:22:13 +0000 |
| commit | b36bb92fda17c5fbfd9a49e4034d52885023d544 (patch) | |
| tree | e052ca3051788590421e8062228f59ebe313469d | |
| parent | fbafce0a5f5c1e68ad3fea1bee7227466d77479b (diff) | |
| download | pi-bitcoindev-b36bb92fda17c5fbfd9a49e4034d52885023d544.tar.gz pi-bitcoindev-b36bb92fda17c5fbfd9a49e4034d52885023d544.zip | |
Re: [bitcoin-dev] BIP 151
| -rw-r--r-- | b8/3f7231ae2ed1bdbbee5cb54eb7663d7a47f6e9 | 137 |
1 files changed, 137 insertions, 0 deletions
diff --git a/b8/3f7231ae2ed1bdbbee5cb54eb7663d7a47f6e9 b/b8/3f7231ae2ed1bdbbee5cb54eb7663d7a47f6e9 new file mode 100644 index 000000000..d2585639c --- /dev/null +++ b/b8/3f7231ae2ed1bdbbee5cb54eb7663d7a47f6e9 @@ -0,0 +1,137 @@ +Return-Path: <eric@voskuil.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 38022A18 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 30 Jun 2016 15:22:13 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3C83206 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 30 Jun 2016 15:22:11 +0000 (UTC) +Received: by mail-wm0-f47.google.com with SMTP id a66so123731934wme.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 30 Jun 2016 08:22:11 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=voskuil-org.20150623.gappssmtp.com; s=20150623; + h=mime-version:subject:from:in-reply-to:date:cc + :content-transfer-encoding:message-id:references:to; + bh=Ymo6XZ5D3BcfFIJao2Dfj728rApTmFl9Xs9qkxPMobs=; + b=pTpkeYhNRxKSsQgxg8HyVUpYV/Wj3cIpuOPslridfj0UR6oJd+C94lFPehyZvyGAGv + QKqmtGc6YCuUl+hK48O9NB7HwY75DocbW98lwo5wo3OjKjpP2JCkVrUfL70D6n4TFola + htyP4G1nW0e1i/1VhZF1iYzhoDVsWP6WlwVLDDHPhjLA0O/KUXVmm4oY4sE6RsZR2Zxm + 521Zdh2HMgrIdGzG00CGvx3UIQp2yk9v1WsBCvoIRuNyzzCsfQGLPa0ZxqxycsQ9W+vl + N55oiGHoqqgmnTwDCLFDBvYJIDtpP6E0Z2fu/lKI9gip9vdYG81CJFe50MePo7j+uBRT + uVSQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc + :content-transfer-encoding:message-id:references:to; + bh=Ymo6XZ5D3BcfFIJao2Dfj728rApTmFl9Xs9qkxPMobs=; + b=IjAZ2Nx3wT3ar+OL3NUYD2OcahiGk8f3fyior29w6PP4HzITDloy/t7oQ0wtb+Wo0+ + jc+Q4/WyBRzMHLJAPyfwBq5T/LJW5ZaN8pOD8/ilUu/tz+QXyHWgZfwlVEqtemteF1i1 + dyIMyyh6CHQYM7PoJ9+g9vQUSdFLmaReN2OhxUSRB6ckMnJfn/7OS11EY1IY8XZdLOTq + YkhxmBkmikey3x/z2uKbcW3LNUm1LUO/wqcNccj2jIBCBJN8qPK6S30nnN/re0rCEXLg + 5K89OHo/oeUFksur+qcK+R95ZBfWWRyVuFSkhYkrex0yuvh1u33OFpRpwjt6ywOqRCOk + PyTw== +X-Gm-Message-State: ALyK8tI0M8UJ2kpUGiIax2iQ9sIkfN+Eov8PgjzjMNAxu5KRzIThuWSBhq5XKntuxNdsjw== +X-Received: by 10.194.176.132 with SMTP id ci4mr14299109wjc.138.1467300130551; + Thu, 30 Jun 2016 08:22:10 -0700 (PDT) +Received: from [197.161.188.155] ([197.161.188.155]) + by smtp.gmail.com with ESMTPSA id s67sm4867886wmf.3.2016.06.30.08.22.09 + (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); + Thu, 30 Jun 2016 08:22:09 -0700 (PDT) +Content-Type: text/plain; + charset=us-ascii +Mime-Version: 1.0 (1.0) +From: Eric Voskuil <eric@voskuil.org> +X-Mailer: iPhone Mail (13F69) +In-Reply-To: <577513DB.60101@jonasschnelli.ch> +Date: Thu, 30 Jun 2016 17:22:08 +0200 +Content-Transfer-Encoding: quoted-printable +Message-Id: <F4BDD091-FD80-4EE9-93EF-735B6BBE253C@voskuil.org> +References: <87h9cecad5.fsf@rustcorp.com.au> + <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> + <577234A4.3030808@jonasschnelli.ch> + <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> + <20160629111728.GO13338@dosf1.alfie.wtf> + <2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org> + <57750EAB.3020105@jonasschnelli.ch> + <426C2AA3-BFB8-4C41-B4DF-4D6CC11988B2@voskuil.org> + <577513DB.60101@jonasschnelli.ch> +To: Jonas Schnelli <dev@jonasschnelli.ch> +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, MIME_QP_LONG_LINE, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] BIP 151 +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 30 Jun 2016 15:22:13 -0000 + + +> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli <dev@jonasschnelli.ch> wrote: +>=20 +>>>> The core problem posed by BIP151 is a MITM attack. The implied solution= + (BIP151 + authentication) requires that a peer trusts that another is not a= +n attacker. +>>>=20 +>>> 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? +>>=20 +>> It is not clear to me why you believe an attack on privacy by an anonymou= +s peer is detectable. +>=20 +> 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 s= +ecure 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 the= +se two peers. It can be between either of them and any anonymous connection t= +hey (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 wi= +ll remain weak until the entire network is "secure". At that point it would n= +ecessarily be a private network. + +As Pieter rightly observes, there are and always will be tunnels between tru= +sting nodes. Often these are groups of nodes that are in collaboration, so l= +ogically they are one node from a system security standpoint. But if people b= +ecome generally reliant on good node registration, it will become the regist= +rar who controls access to the network. So my concern rests I this proposal b= +ecoming 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 w= +ith 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 direc= +tions. +> 6.) Alice has successfully detected the Mallory +>=20 +> Disclaimer: 4) and 5) are _not_ authentication proposals :-) +>=20 +> </jonas> +>=20 + |