diff options
| author | Tier Nolan <tier.nolan@gmail.com> | 2016-03-23 16:44:30 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-03-23 16:44:31 +0000 |
| commit | 8ed176051427ebc957c38ff4eaff7e0d4d372589 (patch) | |
| tree | 41afaaf01e2eac9718d7b28cca684297eda91219 | |
| parent | 608d1a9d72e520584cc2141ce1e5c2c5f1e3b4af (diff) | |
| download | pi-bitcoindev-8ed176051427ebc957c38ff4eaff7e0d4d372589.tar.gz pi-bitcoindev-8ed176051427ebc957c38ff4eaff7e0d4d372589.zip | |
Re: [bitcoin-dev] p2p authentication and encryption BIPs
| -rw-r--r-- | d5/ee9b76644c9015cd391a31a4bd4a938833b2a5 | 114 |
1 files changed, 114 insertions, 0 deletions
diff --git a/d5/ee9b76644c9015cd391a31a4bd4a938833b2a5 b/d5/ee9b76644c9015cd391a31a4bd4a938833b2a5 new file mode 100644 index 000000000..79ba76633 --- /dev/null +++ b/d5/ee9b76644c9015cd391a31a4bd4a938833b2a5 @@ -0,0 +1,114 @@ +Return-Path: <tier.nolan@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 8A38169 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 23 Mar 2016 16:44:31 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-vk0-f41.google.com (mail-vk0-f41.google.com + [209.85.213.41]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2D7DF12D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 23 Mar 2016 16:44:31 +0000 (UTC) +Received: by mail-vk0-f41.google.com with SMTP id k1so26755464vkb.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 23 Mar 2016 09:44:31 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:cc; + bh=3Gx7HrsSJEH8j3F4ASYdSsSUJfkAairZUhU+yHz3Uzw=; + b=zrXFyd6bm5JY8SuQWyro6fGHxj3RYJvqBydLWZa09Y/nBUngBwvKdWG9C34wkxc2vl + EjtICYmpAdTvy2VZpiq97DD/ZoAj+kUGQ3rZ6prJnQsPfqY5BCdWSAnsJIu3lbRrPbi0 + cdXZmgREswRMNEx8tMCFQRTo49fLXxUUbUrZ+HQITIPlzSMqhbcG/4wm6AmCT4qZ6qCD + 3dKUabz+wqbqbIm6ZjvefIKtNm+/pi6P1tnBGMGFsTOLlb+ZUmQV/rKHuqetWdKHI/ak + zRqTe5dicvTNB0k6AwdFlZ2iIcUqzK3nRCUiyYo6PXzSKCH1c9hX342UDcBbdi3FDIqh + R4xg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:date + :message-id:subject:from:cc; + bh=3Gx7HrsSJEH8j3F4ASYdSsSUJfkAairZUhU+yHz3Uzw=; + b=mPy98Rti0qjvTp7jjEB2yXIS1Aau4KX/O8sUOt49royORpKpN3NTF0aRlK+ZRH9kFA + It21tgkPIBbW0peqxrDV1rARckvbel6EJXfRtduwoPWKEFKK8Oo/3fgZqtYONHd7AU3d + y5rdSAX4boKBw+1CxUZVuhW5bbe1+75/vmXq5egmQ+kaYnE+kihVszSNPAdk8QnHoGI3 + zwYgLcbe/BP1304uaYo1fLIYt+4okEWuA+yhpVI/cmVVWf47MofQp5d/etfckbNe+Ib0 + o97NwP/enyvZoH5T7z7rNYyU8YQ++nKiNOQ+731A5xptAutydDvPMhJRZrId3sQA0z04 + jxsA== +X-Gm-Message-State: AD7BkJJefJB1Nh7wa42QpYiip8xyUo4WYenXgpKnfeA9hsAWuicAYIAvycRnrQNrDkGe9LtYO7bvgO6oMppmzg== +MIME-Version: 1.0 +X-Received: by 10.31.161.195 with SMTP id k186mr1819747vke.129.1458751470383; + Wed, 23 Mar 2016 09:44:30 -0700 (PDT) +Received: by 10.176.2.14 with HTTP; Wed, 23 Mar 2016 09:44:30 -0700 (PDT) +In-Reply-To: <56F2B51C.8000105@jonasschnelli.ch> +References: <56F2B51C.8000105@jonasschnelli.ch> +Date: Wed, 23 Mar 2016 16:44:30 +0000 +Message-ID: <CAE-z3OVnh4qJYRqLMQr93S8FQb6iAepk1EL=0s+Qye0nK9Dn4w@mail.gmail.com> +From: Tier Nolan <tier.nolan@gmail.com> +Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=001a1143f36c35720c052eba0b1e +X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, + RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Wed, 23 Mar 2016 16:45:07 +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 23 Mar 2016 16:44:31 -0000 + +--001a1143f36c35720c052eba0b1e +Content-Type: text/plain; charset=UTF-8 + +There is probably not much loss due to per message encryption. Even if a +MITM determined that a message was an inv message (or bloom filter +message), it wouldn't be able to extract much information. Since the +hashes in those messages are fixed size, there is very little leakage. + +You could make it so that the the encryption messages effectively create a +second data stream and break/weaken the link between message size and +wrapped message size. This requires state though, so there is a complexity +tradeoff. + +There is no real need to include an IV, since you are including a 32 byte +context hash. The first 16 bytes of the context hash could be used as IV. + +In terms of generating the context hash, it would be easier to make it +linear. + +context_hash_n = SHA256(context_hash_(n-1) | message_(n-1)) + +As the session gets longer, both nodes would have to do more and more +hashing to compute the hash of the entire conversation. + +--001a1143f36c35720c052eba0b1e +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>There is probably not much loss due to per message en= +cryption.=C2=A0 Even if a MITM determined that a message was an inv message= + (or bloom filter message), it wouldn't be able to extract much informa= +tion.=C2=A0 Since the hashes in those messages are fixed size, there is ver= +y little leakage.<br></div><div><br></div><div>You could make it so that th= +e the encryption messages effectively create a second data stream and break= +/weaken the link between message size and wrapped message size.=C2=A0 This = +requires state though, so there is a complexity tradeoff.<br><br></div><div= +>There is no real need to include an IV, since you are including a 32 byte = +context hash.=C2=A0 The first 16 bytes of the context hash could be used as= + IV.<br><br></div><div>In terms of generating the context hash, it would be= + easier to make it linear.<br><br></div><div>context_hash_n =3D SHA256(cont= +ext_hash_(n-1) | message_(n-1))<br><br></div><div>As the session gets longe= +r, both nodes would have to do more and more hashing to compute the hash of= + the entire conversation.<br></div><div><div><div><div class=3D"gmail_extra= +"><br></div></div></div></div></div> + +--001a1143f36c35720c052eba0b1e-- + |