path: root/ec/4cd6301df860e1b3b9faefa7fdea3803e3f1bf

Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8B97669
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 24 Mar 2016 00:38:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f173.google.com (mail-io0-f173.google.com
	[209.85.223.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E52FA16F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 24 Mar 2016 00:38:04 +0000 (UTC)
Received: by mail-io0-f173.google.com with SMTP id c63so73759270iof.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 23 Mar 2016 17:38:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=wwh/akJPflzTX+/QR/b+Ezajf9Qns7v0x8ia+uHfb/8=;
	b=EkAMII2X3AtKcg0RuY1dcSo3AJTdorq9Ovqg8PordM4KGiv8+vpaxn+/hMaMuP+lGK
	D+9DwCWT9kDTEZA+pYYHGZ0Nib11CkFi8US+ulZr66qjfnUiDjY+a8Y+bVlvPQBay9EW
	51t0CoJ8U3k/Klev5wH9EYIWvoiu8LfUvNwdUgIKy8gKtJlQ3CbIjD6DOkIRX0OdmEV1
	UHzJAw5sWXc4sfedGBMvPJTr7tssy6vI3HTa/H/B0/7pgCwbeyB1efOK5U6c4JL/mDf2
	hr7sDIBTc/1esTOZWur+ulDtYu0Igc/St4fqPuel8iqY+hgaxNINVvNLcnftLUH2EPXd
	qyNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=wwh/akJPflzTX+/QR/b+Ezajf9Qns7v0x8ia+uHfb/8=;
	b=HDCU1dksGCHrZ4iAVrk+FquhjnHdZrHNmVsaSONICPWTxhooWeFnjbNHhYon7/APyI
	/6FBfO7B7iHz8bZAxsbu4yVWkdiCLtExFx3nPV+SbfNP+90eY5C9pkLwJiWsw8irL/Gg
	3t1I/Q4mvwdEY6zbKws2YS6962xuoh6yoXo7ovKsltUJ64Nb5oMousRBUeMhGXhLjrzS
	r580t9pHSkMfwVh8mwpf8gdarTbw+lsl8xiH1fMxMEwBr6nRgnSWH7wU9svK87q8WGDy
	BagUCDTeQG2lp129IlkOzLznd1Hi93Vf11diI2LWcLVDelPmRGszS1U3ap7tJYGYNFEJ
	SK8Q==
X-Gm-Message-State: AD7BkJJwRhjteQGyb4BFTttuQIQyJOJmotB5RxyihB2vV5L+5mWxol8WTEenWgtLE73N4GaTmJ7FBb9C0Ce+8g==
X-Received: by 10.107.30.71 with SMTP id e68mr6650597ioe.145.1458779884432;
	Wed, 23 Mar 2016 17:38:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.143.193 with HTTP; Wed, 23 Mar 2016 17:37:25 -0700 (PDT)
In-Reply-To: <1983116.UNQS71VxHo@garp>
References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Wed, 23 Mar 2016 21:37:25 -0300
Message-ID: <CAKzdR-r7T2vC2dtvN1=PHzFox8T78wQMaYy+=1DezPOtRHNrjQ@mail.gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1140d71ed13b1f052ec0a873
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
X-Mailman-Approved-At: Thu, 24 Mar 2016 00:40:56 +0000
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 24 Mar 2016 00:38:05 -0000

--001a1140d71ed13b1f052ec0a873
Content-Type: text/plain; charset=UTF-8

It seems that every message must be signed (the protocols lacks MACs). This
can be very resource consuming in terms of CPU and bandwidth since most p2p
messages are small.


On Wed, Mar 23, 2016 at 5:36 PM, Tom via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:
> > Hi
> >
> > I have just PRed a draft version of two BIPs I recently wrote.
> > https://github.com/bitcoin/bips/pull/362
>
> I suggest running a spellchecker ;)
>
> Some questions;
>
> * why would you not allow encryption on non-pre-approved connections?
> * we just removed (ssl) encryption from the JSON interface, how do you
> suggest
> this encryption to be implemented without openSSL?
> * What is the reason for using the p2p code to connect a wallet to a node?
> I suggest using one of the other connection methods to connect to the node.
> This avoids a change in the bitcoin protocol for a very specific usecase.
> * Why do you want to do a per-message encryption (wrapping the original)?
> Smaller messages that contain predictable content and are able to be
> matched
> to the unencrypted versions on the wire send to other nodes will open this
> scheme up to various old statistical attacks.
>
> > Responding peers must ignore (banning would lead to fingerprinting) the
> requesting peer after 5 unsuccessfully authentication tries to avoid
> resource
> attacks.
>
> Any implementation of that kind would itself again be open to resource
> attacks.
> Why 5? Do you want to allow a node to make a typo?
>
>
> > To ensure that no message was dropped or blocked, the complete
> communication
> must be hashed (sha256). Both peers keep the SHA256 context of the
> encryption
> session. The complete <code>enc</code> message (leaving out the hash
> itself)
> must be added to the hash-context by both parties. Before sending a
> <code>enc</code> command, the sha256 context will be copied and finalized.
>
> You write "the complete communication must be hashed" and every message
> has a
> hash of the state until it is at that point.
> I think you need to explain how that works specifically.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a1140d71ed13b1f052ec0a873
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It seems that every message must be signed (the protocols =
lacks MACs). This can be very resource consuming in terms of CPU and bandwi=
dth since most p2p messages are small.<br><br></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Wed, Mar 23, 2016 at 5:36 PM, Tom via=
 bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On W=
ednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:<br>
&gt; Hi<br>
&gt;<br>
&gt; I have just PRed a draft version of two BIPs I recently wrote.<br>
&gt; <a href=3D"https://github.com/bitcoin/bips/pull/362" rel=3D"noreferrer=
" target=3D"_blank">https://github.com/bitcoin/bips/pull/362</a><br>
<br>
</span>I suggest running a spellchecker ;)<br>
<br>
Some questions;<br>
<br>
* why would you not allow encryption on non-pre-approved connections?<br>
* we just removed (ssl) encryption from the JSON interface, how do you sugg=
est<br>
this encryption to be implemented without openSSL?<br>
* What is the reason for using the p2p code to connect a wallet to a node?<=
br>
I suggest using one of the other connection methods to connect to the node.=
<br>
This avoids a change in the bitcoin protocol for a very specific usecase.<b=
r>
* Why do you want to do a per-message encryption (wrapping the original)?<b=
r>
Smaller messages that contain predictable content and are able to be matche=
d<br>
to the unencrypted versions on the wire send to other nodes will open this<=
br>
scheme up to various old statistical attacks.<br>
<br>
&gt; Responding peers must ignore (banning would lead to fingerprinting) th=
e<br>
requesting peer after 5 unsuccessfully authentication tries to avoid resour=
ce<br>
attacks.<br>
<br>
Any implementation of that kind would itself again be open to resource<br>
attacks.<br>
Why 5? Do you want to allow a node to make a typo?<br>
<br>
<br>
&gt; To ensure that no message was dropped or blocked, the complete communi=
cation<br>
must be hashed (sha256). Both peers keep the SHA256 context of the encrypti=
on<br>
session. The complete &lt;code&gt;enc&lt;/code&gt; message (leaving out the=
 hash itself)<br>
must be added to the hash-context by both parties. Before sending a<br>
&lt;code&gt;enc&lt;/code&gt; command, the sha256 context will be copied and=
 finalized.<br>
<br>
You write &quot;the complete communication must be hashed&quot; and every m=
essage has a<br>
hash of the state until it is at that point.<br>
I think you need to explain how that works specifically.<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>

--001a1140d71ed13b1f052ec0a873--