From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F2AEA74 for ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. --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--