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 14A2B97 for ; Wed, 23 Mar 2016 21:55: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 36ED0F0 for ; Wed, 23 Mar 2016 21:55:40 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 28CF52E200F3; Wed, 23 Mar 2016 22:55:38 +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 F21A82D0046E for ; Wed, 23 Mar 2016 22:55:37 +0100 (CET) To: bitcoin-dev@lists.linuxfoundation.org References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp> From: Jonas Schnelli Message-ID: <56F310D6.2070002@jonasschnelli.ch> Date: Wed, 23 Mar 2016 22:55:34 +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: <1983116.UNQS71VxHo@garp> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fv4CcBhOIQEAQL0isBelQJ3jeGxCheAkH" X-Mailman-Approved-At: Thu, 24 Mar 2016 00:40:50 +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: Wed, 23 Mar 2016 21:55:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fv4CcBhOIQEAQL0isBelQJ3jeGxCheAkH Content-Type: multipart/mixed; boundary="v1BmlgGGg4mEa9oLwbAVme1qRkJA8Ijkq" From: Jonas Schnelli To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <56F310D6.2070002@jonasschnelli.ch> Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp> In-Reply-To: <1983116.UNQS71VxHo@garp> --v1BmlgGGg4mEa9oLwbAVme1qRkJA8Ijkq 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 >=20 > I suggest running a spellchecker ;) Thanks. Will do. > * why would you not allow encryption on non-pre-approved connections? 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/receiving encrypted data from/to a MITM. > * we just removed (ssl) encryption from the JSON interface, how do you = suggest=20 > this encryption to be implemented without openSSL? The proposed encryption schema is based on ECDSA/ECDH (implemented in libsecp256k1) and AES256CBC (implementation is on the way see https://github.com/bitcoin/bitcoin/pull/7689). OpenSSL is not required. > * What is the reason for using the p2p code to connect a wallet to a no= de? > I suggest using one of the other connection methods to connect to the n= ode.=20 > This avoids a change in the bitcoin protocol for a very specific usecas= e. Most known use-case: SPV. > * Why do you want to do a per-message encryption (wrapping the original= )?=20 > Smaller messages that contain predictable content and are able to be ma= tched=20 > to the unencrypted versions on the wire send to other nodes will open t= his=20 > scheme up to various old statistical attacks. It's probably extremely inefficient to create a constant time stream. Even most SSL/SSH application leak information because of the communication message characteristics. The current wrapping message proposal is not very efficient. I will change it so that the p2p message header will contain the encryption metadata. This should lead to a tiny overhead. >=20 >> Responding peers must ignore (banning would lead to fingerprinting) th= e=20 > requesting peer after 5 unsuccessfully authentication tries to avoid re= source=20 > attacks. >=20 > Any implementation of that kind would itself again be open to resource = > 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 >=20 >> To ensure that no message was dropped or blocked, the complete communi= cation=20 > must be hashed (sha256). Both peers keep the SHA256 context of the encr= yption=20 > session. The complete enc message (leaving out the hash it= self)=20 > must be added to the hash-context by both parties. Before sending a=20 > enc command, the sha256 context will be copied and finaliz= ed. >=20 > You write "the complete communication must be hashed" and every message= has a=20 > 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. You just append the "new data". Some pseudocode: SHA256CTX ctx; // first com SHA256CTX_Update(ctx, 1stmessage); // copy context SHA256CTX ctxnew =3D ctx; // finalize the copied context sha256hash =3D SHA256CTX_Finalize(ctxnew); //use as checksum hash //////// next message SHA256CTX_Update(ctx, 2ndmessage); // copy context SHA256CTX ctxnew =3D ctx; // finalize the copied context sha256hash =3D SHA256CTX_Finalize(ctxnew); //use as checksum hash =2E.. etc. --v1BmlgGGg4mEa9oLwbAVme1qRkJA8Ijkq-- --fv4CcBhOIQEAQL0isBelQJ3jeGxCheAkH 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 iQIcBAEBCAAGBQJW8xDWAAoJECnUvLZBb1Ps79kP/1oTbMezXCmrJi5D5Q2itvrv 8FFsfVPtAerosmWPC8lYEhh5y+SZMu2jzxLu4icVefSdQg+KOccEQXa678oWX7u/ v3agcHL5iYQ4R4KB2OQyIgVvrnYDyeO7oAGLzrSnXEduUgpN9LBGAHTGN/9pPATy zKFLfaVnY3xzWt+Imgw+H4er+S3CMeV6xOqrI2lhhcCltQYO9Yg8jYkScOvHydbd l9J2V70Q0u6+D0VeU6rjDqh9QRqg16hQoC78ADiCSq6RSRFzqvzScueyg5JOuY5c 0Y5Qp+XvyUXyD5Nllqb6VJhWk4nAJp8xAX+AHKrsoCHBFcpSEAo5W6KkOyost/Wm DiQBPpW92oLZPLj8mfFBL8/iXseucigiCuEvnjn1Bs6bCjcpoq3YG8gTlMf04ndC PbzxHJD/sFwiXxQ7D6T9p3GQpVBV08qecErl6v/rbcjJUfFU6U3+ieJjNRPgS4Sf v+H+eSZm/GrXLUlfYONQDZv3SznpjZ9zQSFy++BEiB9ANNsnr054290ZantIV6L4 hIJgYpVXgNQAkBLS/Wupl+z6I+DJpyU0TwD3bem7trKFLSLguLS2rLdb3Wbf05nM kzR8102aFeAfcbz3Ty5DI0mdAFlGJ4+Da1/YLAe3z9wWRya1W2hXdgPBYUA/fRWH Iwj3C8kmFATPrVPl73o0 =bAhm -----END PGP SIGNATURE----- --fv4CcBhOIQEAQL0isBelQJ3jeGxCheAkH--