path: root/f2/efb55170ec0ec57192e7e19f34e7ae8fd37944

Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 89C847D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Mar 2016 18:43:07 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4643413D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Mar 2016 18:43:06 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
	id 39FB32E200F5; Fri, 25 Mar 2016 19:43:05 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1
	autolearn=ham version=3.3.1
Received: from Jonass-MacBook-Pro.local (cable-static-140-182.teleport.ch
	[87.102.140.182]) by server3 (Postfix) with ESMTPSA id 560932D00182
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Mar 2016 19:43:04 +0100 (CET)
To: bitcoin-dev@lists.linuxfoundation.org
References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp>
	<56F310D6.2070002@jonasschnelli.ch> <2590065.B4dTBeyc1A@garp>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <56F586B4.8020507@jonasschnelli.ch>
Date: Fri, 25 Mar 2016 19:43:00 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
	Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <2590065.B4dTBeyc1A@garp>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="PTiC416NeDLALWvVr79LdWip7HRX9AKpR"
X-Mailman-Approved-At: Fri, 25 Mar 2016 18:46:30 +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: Fri, 25 Mar 2016 18:43:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--PTiC416NeDLALWvVr79LdWip7HRX9AKpR
Content-Type: multipart/mixed; boundary="mrGixo64MLljSDbmLc3wX57lJU3m8bdrC"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <56F586B4.8020507@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp>
 <56F310D6.2070002@jonasschnelli.ch> <2590065.B4dTBeyc1A@garp>
In-Reply-To: <2590065.B4dTBeyc1A@garp>

--mrGixo64MLljSDbmLc3wX57lJU3m8bdrC
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Tom

>> The encryption should be optional.
>> The proposed authentication scheme does take care of the
>> identity-management and therefor prevent MITM attacks.
>> Without the identity management, you might not detect sending/receivin=
g
>> encrypted data from/to a MITM.
>=20
> If you want to extend the Bitcoin protocol itself, you will have to res=
olve=20
> that. Which many other solutions do (ssh for instance).

Please check the newest auth BIP (it solves MITM).

The encryption BIP itself does not cover peer authentication.
Encryption without authentication of peers can also be valuable.


>>> * 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 usec=
ase.
>>
>> Most known use-case: SPV.
>=20
> You didn't answer the question.

I hope you see the today's problem with SPV.
You fully reveal to your ISP / WiFi provider most of your wallet
controlled addresses (when using BF). The ISP/WiFi provider can link
your bitcoin usage to other inet traffic and/or they could sell
information to statistics company like google.

Also, an attacker controlling a WiFi router or any other network peer
between your SPV node and the remote full node could censorship
transactions.

Etc. etc.

An encrypted channel together with a trusted full node would finally
allow to have a secure and save SPV communication.


>>> * Why do you want to do a per-message encryption (wrapping the origin=
al)?
>>> Smaller messages that contain predictable content and are able to be
>>> matched to the unencrypted versions on the wire send to other nodes w=
ill
>>> open this scheme up to various old statistical attacks.
>>
>> It's probably extremely inefficient to create a constant time stream.
>=20
> Your use of "probably" makes me wonder if you already have an implement=
ation.=20
> Doing any encryption and handshaking design *without* actually having i=
t coded=20
> and gone though testing yet makes no sense.
> I do not belief Bitcoin will benefit from "design by committee" where a=
=20
> specification is drawn before an implementation is written.
>=20
> Also, you didn't actually address the attack-vector.

Which attack-vector? MITM? Is conceptual solved with the auth BIP (that
requires encryption).

There is no implementation done yet.
It would be a waste of time to start writing a such implementation
_before_ having this discusses and improved by the community.

But the encryption BIP now recommends Chacha20-Polay1305 as AEAD which
is widely used.

I'm ready to write an implementation as soon as I have some signs that
the BIP does make sense.

Also, auth and enc is not something we will have in the next couple of
weeks. This might require a couple of months until its stable and ready
for production.

>=20
> =20
>>>> 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 resourc=
e
>>> attacks.
>>> Why 5? Do you want to allow a node to make a typo?
>>
>> Good point. Maybe one false try should lead to ignoring the peer.
>=20
> That doesn't take away the resource attack at all.
>=20
> =20
>>>> To ensure that no message was dropped or blocked, the complete
>>>> communication>=20
>>> must be hashed (sha256). Both peers keep the SHA256 context of the
>>> encryption session. The complete <code>enc</code> message (leaving ou=
t
>>> 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 messa=
ge
>>> has a hash of the state until it is at that point.
>>> I think you need to explain how that works specifically.
>>
>> This is a relative simple concept and does not require rehashing the
>> whole communication.=20
>=20
> Apologies, I should have been more clear; the BIP should specify the ac=
tual=20
> algorithm, otherwise you can't create an implementation from just readi=
ng the=20
> BIP.

The sha256 context is gone now and replaced by a proper MAC.

>=20
> Also, this may be a good time to ask why you want to have a per-message=
=20
> encryption?
> Practically every single popular end-to-end encryption uses one approac=
h or=20
> another were it just encrypts as another layer. (the  L in ssl). You ar=
e=20
> mixing layers, and unless you do that for a very good reason, or have a=
 very=20
> good reason why everyone else is doing it wrong, I suggest using a laye=
red=20
> encryption approach.

Like most other encryption layers, we would still use messages. But we
call them "encrypted messages", the have a tiny header of plaintext data
(message length, AEAD-tag) and they will contain <n> plaintext p2p
messages _after_ decrypting. The plaintext messages have a much simpler
header (removed the 4 bytes sha256 checksum, removed the 4byte network)

</jonas>


--mrGixo64MLljSDbmLc3wX57lJU3m8bdrC--

--PTiC416NeDLALWvVr79LdWip7HRX9AKpR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW9Ya1AAoJECnUvLZBb1PslyIP/3ZIjtO9SBO0mSR56RydkcAj
3Khzw3AXE43PWWRbGd4kWpbYwVjj7jsudi6xaUpMieOtTx2/UMCriXTmAVvle6FB
PDFOt0cevQFziSO+SWYxzYth1eTgmX/Oy8qhiR8iP8+Gb3IBNEibo5KueX/K3w9J
L1hKa5L7wZ0BugOeMyEhGUabCxF8iDdc1bTMddjWaFm/4rs83oWI/Eq/dVkNdjwU
mXbKpPo+v6EKIMgnEMxoWA66oBapvHVGtrTSfK9CFMgxZoDK55l8STajlNy7phHW
ipFPLVh24yvxI00S50JCGZcB7mn+fiWpGGP9QXYZOOClkRWkvVMohHXrCsDt5e03
VM0G65psaBRz2AL67kXrujEseVdN0fqTCLMaPbwrfS3ul3lNfrNciCvwr/DJdA+k
VuE8nxz8pvOrBwQMcinzH12aM28yh61sh0Zj66Mknz3vR0XvdaN3GBgqw5vkv9K3
WHR9rEI2oDEDLYujx30HUyaFzWfik/k20xIKVIKDLS27CKx7c/+QjPa0IkPl5Qq/
dPJRx+SLAZiIIjdVBpTY0wnzfWtDnrPdxFyOYxKiIi82AYwR6ovDuv8ehs0HtIAK
LuzHkBJDl/VgOvAqQCv8a8VGKpAFFdPItuGQ2c7KKtmoLbIAoIfG+5RS011QBiDW
kM3TTtx/yToLAvnIYafB
=z/QP
-----END PGP SIGNATURE-----

--PTiC416NeDLALWvVr79LdWip7HRX9AKpR--