diff options
| author | Jonas Schnelli <dev@jonasschnelli.ch> | 2016-03-26 10:01:36 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-03-26 09:01:41 +0000 |
| commit | 5e595f1b45d2612b95a461439035a44147c4d8ec (patch) | |
| tree | 761b43e0c69895b0107ef60bb01a3a2cc1b9f0fc | |
| parent | bae4adf4d3d1025a22bfe1fb58bab1125c850997 (diff) | |
| download | pi-bitcoindev-5e595f1b45d2612b95a461439035a44147c4d8ec.tar.gz pi-bitcoindev-5e595f1b45d2612b95a461439035a44147c4d8ec.zip | |
Re: [bitcoin-dev] p2p authentication and encryption BIPs
| -rw-r--r-- | 29/d16892de01daba90859ce926ce1b2429aa2af3 | 162 |
1 files changed, 162 insertions, 0 deletions
diff --git a/29/d16892de01daba90859ce926ce1b2429aa2af3 b/29/d16892de01daba90859ce926ce1b2429aa2af3 new file mode 100644 index 000000000..ba0985067 --- /dev/null +++ b/29/d16892de01daba90859ce926ce1b2429aa2af3 @@ -0,0 +1,162 @@ +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 F2AEA74 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 26 Mar 2016 09:01:41 +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 2BBA4EB + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 26 Mar 2016 09:01:41 +0000 (UTC) +Received: by server3 (Postfix, from userid 115) + id 423A22E200F6; Sat, 26 Mar 2016 10:01:40 +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 7E3582D00182 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 26 Mar 2016 10:01:39 +0100 (CET) +To: bitcoin-dev@lists.linuxfoundation.org +References: <56F2B51C.8000105@jonasschnelli.ch> <2590065.B4dTBeyc1A@garp> + <56F586B4.8020507@jonasschnelli.ch> <4517402.JLxTDjem5X@garp> +From: Jonas Schnelli <dev@jonasschnelli.ch> +Message-ID: <56F64FF0.7060706@jonasschnelli.ch> +Date: Sat, 26 Mar 2016 10:01:36 +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: <4517402.JLxTDjem5X@garp> +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; + boundary="uirTOEHL6u793p52WGICDQ0DUom0bjkte" +X-Mailman-Approved-At: Sat, 26 Mar 2016 09:41:37 +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: Sat, 26 Mar 2016 09:01:42 -0000 + +This is an OpenPGP/MIME signed message (RFC 4880 and 3156) +--uirTOEHL6u793p52WGICDQ0DUom0bjkte +Content-Type: multipart/mixed; boundary="KkoBEibVi0MVj6xuEVO6ESSE3G68I4bFC" +From: Jonas Schnelli <dev@jonasschnelli.ch> +To: bitcoin-dev@lists.linuxfoundation.org +Message-ID: <56F64FF0.7060706@jonasschnelli.ch> +Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs +References: <56F2B51C.8000105@jonasschnelli.ch> <2590065.B4dTBeyc1A@garp> + <56F586B4.8020507@jonasschnelli.ch> <4517402.JLxTDjem5X@garp> +In-Reply-To: <4517402.JLxTDjem5X@garp> + +--KkoBEibVi0MVj6xuEVO6ESSE3G68I4bFC +Content-Type: text/plain; charset=windows-1252 +Content-Transfer-Encoding: quoted-printable + + +> I guess my question didn't get across.=20 +>=20 +> Why would you want to make your usecase do connections over the peer2pe= +er=20 +> (net.cpp) connection at all? + +First, because there _are_ a hight amount of SPV wallets in the field. +SPV wallets are "dumb-clients" with only a tiny value for the bitcoin +network (they don't validate, they don't relay). They already are +decoupled wallets. We need solution that offers higher privacy and +higher traffic analysis resistance. + +Using the p2p channel for communication between full validation peers +and wallet-only-peers makes sense IMO because wallet-only-peers can +slowly validate the chain and create a UTXO set in the background (could +take a couple of weeks) or solve other purposes that increases the +security and/or serving something back to the bitcoin network. + +Sure, you can always use client/server wallets (Coinbase / Copay, etc.) +that offers SSL. +But I strongly recommend to improve the communication and interface +possibilities between wallet-nodes (SPV) and full-validation-nodes. + +Otherwise we will very likely see centralization regarding end-user +wallets (with all the large risks of disrupting the community in case of +attacks/thefts, etc.). + +_If we think Bitcoin should scale, we also need to scale and improve at +the point where users enter the network and start using Bitcoin._ + +> Mixing messages that are being sent to everyone and encrypted messages = +is=20 +> asking for trouble. +> Making your private connection out-of-band would work much better. + +The current encryption BIP requires to encrypt the complete traffic. +Having an option to do analysis resistant communication with a remote +peer within the protocol itself is something that is very valuable IMO. + + +>>> Also, you didn't actually address the attack-vector. +>> +>> Which attack-vector? +>=20 +> The statistical attack I mentioned earlier. Which comes from knowing w= +hich=20 +> plain text messages are being sent over the encrypted channel, So as lo= +ng as=20 +> you keep saying you want to encrypt data that identical copies of are b= +eing=20 +> sent to other nodes at practically the same time, you will keep being=20 +> vulnerable to that. + +The encryption BIP recommends Chacha20-Poly1305 as encryption AEAD. This +is a very broad used encryption scheme (Google uses it to connect +Android phones with their cloud services). + +Completely avoiding side channel on data analysis would probably require +extremely inefficient constant time encrypted datastreams. + +Also, the BIP allows combining of multiple plaintext message in one +encrypted message. + +Additionally we could extend the enc. BIP by allowing random padding of +encrypted messages or other techniques to reduce side channel analysis. + +</jonas> + + +--KkoBEibVi0MVj6xuEVO6ESSE3G68I4bFC-- + +--uirTOEHL6u793p52WGICDQ0DUom0bjkte +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 + +iQIcBAEBCAAGBQJW9k/wAAoJECnUvLZBb1Psg/sP/052T7OPZqSfI8wWQxDDR5Hk +z0mp4ASjY7qE1ePcdBpXsntPeAvhEkxLdZBb4/9MQFyMjx5pa0qu342Nwx6rYOrt +PDb8hWLUD4EMLgvQgGmB2fpAZmcr3CDvoRHZrbbicG07sFMBooxDzxlnEPQZNp14 +RziMhrXww1oCCU0nYuXUJ/uHLWXCQIOP5B6ZcaCoL4atq76dSn2wE6TSdqi5T5KK +l1KMzCMbZ710rGzJ0JKRowSYqx2E2Z9FCceikk0nYYUZGNuT50bhYI5z1T7PLZ/H +iJmnzSwOs0PCVtuKDyHFgY30AF1lCzLxdALDohRf4EKMoTjJeYObshnN5rL5srYJ +kJxBEm0mskpypx/lQbIjMvuGcrJ6waMiG7wtM2VROrBt8jeXPxtBHV52YNaBX6GZ +C9LRckx3lcoEGsoKH3hN1McE+DrKjZxySAmzKBN086XrIGy5vIDpwj+1T2vILkCL +0kDbEsen9Zd9Ldy+PyENI7YDOhCU1OqQUKcVkjF6LUFk1dxTdi5yvrNXkPGD3hTU +UOO0O8atpHLKzGYz7OXYFtSgMtmBKElwdYImHaMG4WF18lLulNPYqfzXdpqfv6RD +aFIhzdjbg1kxI4/QHTSjMnQCR5nnrCmyrsPoJ4stcDT4Y2Ao04oxRBzLyJ5HfTD6 +yL4kzQ8iauQG5lRPTVXH +=nkkG +-----END PGP SIGNATURE----- + +--uirTOEHL6u793p52WGICDQ0DUom0bjkte-- + |