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 89C847D for ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 enc message (leaving ou= t >>> the hash itself) must be added to the hash-context by both parties. >>> Before sending a enc 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 plaintext p2p messages _after_ decrypting. The plaintext messages have a much simpler header (removed the 4 bytes sha256 checksum, removed the 4byte network) --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--