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 9B3FB902 for ; Wed, 25 May 2016 09:36:29 +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 EA3D0101 for ; Wed, 25 May 2016 09:36:27 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 819B92E6017D; Wed, 25 May 2016 11:36:26 +0200 (CEST) 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 BEAC62D002BC for ; Wed, 25 May 2016 11:36:25 +0200 (CEST) To: bitcoin-dev@lists.linuxfoundation.org References: <56F2B51C.8000105@jonasschnelli.ch> <56FEE39B.3040401@jonasschnelli.ch> <20160409154038.4c04dd9b@laptop-m1330> <573C212C.6070604@jonasschnelli.ch> <20160524202250.01db6f61@laptop-m1330> From: Jonas Schnelli Message-ID: <57457218.6060804@jonasschnelli.ch> Date: Wed, 25 May 2016 11:36:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160524202250.01db6f61@laptop-m1330> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe" 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 Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 09:36:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe Content-Type: multipart/mixed; boundary="B08LAIBXFE4TV0JeCjTHRVMG2qKeGwTMU" From: Jonas Schnelli To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <57457218.6060804@jonasschnelli.ch> Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs References: <56F2B51C.8000105@jonasschnelli.ch> <56FEE39B.3040401@jonasschnelli.ch> <20160409154038.4c04dd9b@laptop-m1330> <573C212C.6070604@jonasschnelli.ch> <20160524202250.01db6f61@laptop-m1330> In-Reply-To: <20160524202250.01db6f61@laptop-m1330> --B08LAIBXFE4TV0JeCjTHRVMG2qKeGwTMU Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >> Good point. >> I have mentioned this now in the BIP but I think the BIP should allow >> message > 16 MiB. >> I leave the max. message length up to the implementation while keeping= >> the 4 byte length on the protocol level. >=20 > I expect the implementation defined max size to work (SSH 2.0 does this= > after all), but I want to make sure my suggestion is understood > completely. >=20 > There is a length field for the encrypted data, and length field(s) > inside of the encrypted data to indicate the length of the plaintext > Bitcoin messages. I am suggesting that the outter (encrypted) length > field be reduced, which will _not limit_ the length of Bitcoin > messages. For example, if a 1 GiB Bitcoin message needed to be sent > and the encrypted length field was 3 bytes - the sender is forced to > send a minimum of 64 MACs for this message. The tradeoff is allowing > the receiver to detect malformed data sooner and have a lower max > buffering window **against** slightly higher bandwidth and CPU > requirements due to the additional headers+MACs (the CPU requirements > should primarily be in "finalizing each Poly1305"). Okay. Got your point. The current BIPs assumption is that an encrypted package/message can contain 1..n bitcoin messages (a single bitcoin message distributed over multiple encrypted messages/packages was not specified). But right, this could make sense. Let me think this through.... > An alternative way to think about the suggestion is tunnelling Bitcoin > messages over TLS or SSH. TLS 1.2 has a 2-byte length field and SSH 2.0= > a 4-byte length field, but neither prevents larger Bitcoin messages fro= m > being tunnelled; the lengths are independent. TLS/SSH tunneling is already possible with third party software like stunnel. Also there is promising projects that would encrypt the traffic "on a deeper layer" (see CurveCP). I think what we want is a simple, openssl-independent traffic encryption built into the core p2p layer. IMO the risk of screwing up the implementation is moderate. The implementation is not utterly-complex: OpenSSH chacha20: https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cb= a69011a535f86f6b/chacha.c Chacha20-Poly1305: https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cb= a69011a535f86f6b/cipher-chachapoly.c Sure. Before an implementation will be deployed to the endusers it will require intense cryptoanalysis first. --B08LAIBXFE4TV0JeCjTHRVMG2qKeGwTMU-- --DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe 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 iQIcBAEBCAAGBQJXRXIYAAoJECnUvLZBb1PsnCkP/13tmyamj1c6DeJV89LZbmCa LSEUPqh08sKiiNxV1y3Tqg97NTLwyz436WUEeLlEEa4Nxvkj3dD3ctGh4wQRMYSD onobpBUL33oOM02+r3TznlMYPMwXaif+vfOjOcQZnj54XS/PpoVKGf7oDkrEF1Sh TjiqMe9807gn4Yhg77mTsMTF+H/qjMW+i1Y75OUvcU0C3oPjcSkH+waifggGV9q/ 1W6H/6Kw3JY4Ce0j+u2FA2JrLY2Qti56U5bG+hJ3Qn8SVJlXcTWrNL0gPxGLHBop dVJXYNR0X59OXQg+K6TGvX+Tyf4ErMwN98tzfTD1sWVbso+rfvJxVHQ+2Oi1hOQg Gg7NX+in082+We3ymFVuT4RC31a6kzXSMV21XKJkzJL5HCuzuOqtwA8cTlmeDaub y3WBK39wz4fm8J7tayw3TxuuHCySgR4uJVXK/r+eU9Mz7DEJ4AVIxy1Qt52vxjKc M9vnXAIoOzER/44lldtTaidAG97u1runyMltUNzbmdCLXXqWU+GnIpkemax7B6oP UFD2Htw+Jx5lMSTYOSW04FyS5W4bMjKS0R66scElcj1SI9nPX8l3MxRPTqzteb34 SH5t6HNKKgIA9rQcOIJiK0WyKRLBsjSvTDhYlDChURdzRUuWNn95tZKEPnP2ma12 Ph4fK5DHk+8KfGYQ+FBE =Cvl4 -----END PGP SIGNATURE----- --DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe--