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 1E65F74 for ; Fri, 25 Mar 2016 10:17:16 +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 1D48FF0 for ; Fri, 25 Mar 2016 10:17:15 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id E406D2E200F5; Fri, 25 Mar 2016 11:17:13 +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 2ADFC2D00182 for ; Fri, 25 Mar 2016 11:17:13 +0100 (CET) To: bitcoin-dev@lists.linuxfoundation.org References: <56F2B51C.8000105@jonasschnelli.ch> From: Jonas Schnelli Message-ID: <56F51026.8010708@jonasschnelli.ch> Date: Fri, 25 Mar 2016 11:17:10 +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: <56F2B51C.8000105@jonasschnelli.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Xjq71CSRInxAr51uMdcalB0f29ap1f8DP" X-Mailman-Approved-At: Fri, 25 Mar 2016 17:29:54 +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 10:17:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xjq71CSRInxAr51uMdcalB0f29ap1f8DP Content-Type: multipart/mixed; boundary="rlted09gewTUMsnajOEVsc3ldwH7EVVkf" From: Jonas Schnelli To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <56F51026.8010708@jonasschnelli.ch> Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs References: <56F2B51C.8000105@jonasschnelli.ch> In-Reply-To: <56F2B51C.8000105@jonasschnelli.ch> --rlted09gewTUMsnajOEVsc3ldwH7EVVkf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > I have just PRed a draft version of two BIPs I recently wrote. > https://github.com/bitcoin/bips/pull/362 Thanks for the feedback and IRC discussions. I have overhauled both BIPs. https://github.com/bitcoin/bips/pull/362/files#diff Main changes for the encryption BIP: * No message wrapping. Once encryption is established, everything is encrypted. No timeout. * Added MAC: proposed AEAD is now ChaCha20-Poly1305 with an alternative for AES256-GCH * Independent ECDH negotiation and independent secrets for the symmetric cipher for both communication directions * Optimized message format and message-batch-option for encrypted data It could be that the p2p performance for Chacha20-poly1305 encrypted message is slightly better then the current plaintext message format (dropping the network magic and the sha256 per message). P2p authentication BIP: * No message wrapping. Peers keep the state once authenticated. * Simplified and auth now requires encrypted channels. Some answers... > How does a peer know what messages the other peer requires to be authenticated? This is not covered by the auth BIP. Peers could agree on a protocol extension outside of any BIP. Once auth is possible, new BIPs could be written. Things like only allowing filtering (or other services) to authenticated peers (and disabling NODE_BLOOM). > How does banning in this specific case enable fingerprinting as opposed to any other banning? Current nodes ignore a unknown message with a command like "auth". Banning would allow a requesting peer to identify nodes that support auth and attack them over different channels ("ah, ... this guy supports auth, they must have some secret data, lets attack over SSH). >> This proposal is backward compatible. Non supporting peers will ignore the auth message. > ... and not process it at all? How is that backward compatible? Depends how we define backward compatibility. :-) Peers supporting this "extension" can still interact with older peers. > This proposal is backward compatible. Non supporting peers will ignore the > enc* messages. Current p2p implementation ignores any unknown command. --rlted09gewTUMsnajOEVsc3ldwH7EVVkf-- --Xjq71CSRInxAr51uMdcalB0f29ap1f8DP 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 iQIcBAEBCAAGBQJW9RAmAAoJECnUvLZBb1PsjnUQAKmyYMzhtU6rQj1nnwiumxEf m4CPZyShbbIC6AWh7+TnMwAqq9Rg2hU2l72T2i/OWWTRODPnNf9D5BwqdJ9kit02 61xdzXqgbZzk4rzT7AgiMJVXyVXzTXmeV+MvIuqvDKiTYcA0pv8RGh3SlXgqlIAC OM7+dMuUu1cUABslv9O1P+NWCzWle5CITC6wnHR9ktwwTEsBuzYlAM6EtJqCaDTe UYmGgKvdUhRfpjQ/mhnEQYyKj7k0tlvmozco7chUt3caCgSQIjsaznNlGw5bMAqx Lefr8gPE5tCaZuHZLuU31pQLDiVCGVLRDzeAtnJUitqGIiDnv22aqLZHi9AoLbWc h0pDoCXCleIHRMz4c68j/672Fjg3JYL1xe2M1C3YgfWx2guxKjdgZcF6TcEKAg7/ aFO43/5nvh/WkfF8jgBB9Y+TMa69nuTd50HCwQVbsTIHS1lRYn1F+OxYRrUPZ3hG NS9CqVi2wbBa9YjOpMRCzpgNX9AuBze4ZjWbjxPk5KG9h9+h2B7BUpmdtACaRG8E obboRoRrcbOGUIy0Ba2ESLHIzILPsyS8U0oHDp/I1jiVWexM2ULi7KKfhUuRAB// GaoRC7eMbKq9ohpFBGvqnQ/RQt15iktGt10JPmz6lCM6VO1qCuX1VfgUj3op3esI 8yOswqm+ODhaCf53tmlB =r+/N -----END PGP SIGNATURE----- --Xjq71CSRInxAr51uMdcalB0f29ap1f8DP--