diff options
| author | Eric Voskuil <eric@voskuil.org> | 2016-03-23 14:40:50 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-03-23 21:40:46 +0000 |
| commit | 0ebeda789e61a9032fa81fdc8d1b6c38a8d62926 (patch) | |
| tree | 0f44570650dbf8f4541d855e5c42616b28fb5f6e | |
| parent | 37cddac5b840c4502004f33b1171cc723833781a (diff) | |
| download | pi-bitcoindev-0ebeda789e61a9032fa81fdc8d1b6c38a8d62926.tar.gz pi-bitcoindev-0ebeda789e61a9032fa81fdc8d1b6c38a8d62926.zip | |
Re: [bitcoin-dev] p2p authentication and encryption BIPs
| -rw-r--r-- | 9a/ce1762d6f15c70d4f160cc7a34e7fc05968eb6 | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/9a/ce1762d6f15c70d4f160cc7a34e7fc05968eb6 b/9a/ce1762d6f15c70d4f160cc7a34e7fc05968eb6 new file mode 100644 index 000000000..dfc3842bc --- /dev/null +++ b/9a/ce1762d6f15c70d4f160cc7a34e7fc05968eb6 @@ -0,0 +1,177 @@ +Return-Path: <eric@voskuil.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 89B4392 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 23 Mar 2016 21:40:46 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com + [209.85.192.173]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 043B1155 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 23 Mar 2016 21:40:45 +0000 (UTC) +Received: by mail-pf0-f173.google.com with SMTP id 4so40333881pfd.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 23 Mar 2016 14:40:45 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=voskuil-org.20150623.gappssmtp.com; s=20150623; + h=message-id:date:from:user-agent:mime-version:to:subject:references + :in-reply-to; bh=YCcJeFS3TWJ5EB6LzfDqrJiPDIj/hFzHJnTY+aEWYzM=; + b=JbKUGOu/hwakwJ47GxFWV6ZaY0irmY0ETHB0GdlUQKtFHnE0TMWFtn3vN6rbe8FKkh + UjW0J7quVbYne58czQ3QocqdYhSjV5rxwS/3zUPIWa9iHyjgX+hz/j7QOtYv4MxkIy6Y + 3QHWxrxlqXp+BOBSERRlM/UeYRYo6nFEPBxFLlS38Jtas1g7Xgh1Ir47SewDE87asgTD + LprNbUYL4NzJxvlLl13k39DHjRFawgtZ6nD9zWPGmjjEf7qMKawXfExAcnOeTB4TfSQY + /YW+y/2eQFnRTw+SABsFgEw8wBdNFYjMrqzH8aYzPAkOHhsR4tg4vLpfGvPPGnbRxDv7 + 0//g== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to + :subject:references:in-reply-to; + bh=YCcJeFS3TWJ5EB6LzfDqrJiPDIj/hFzHJnTY+aEWYzM=; + b=hfKlItHmF0RmCJj+Ii4RPLlt2Pqom/r9qhUFRewHCrBNPa9qAt05uy+kp1nXuikEfu + D20uPN1qQhMqKj8lbOYhruY2oj36QQqXTxO8oEv1E8lw6iZ9g9BS4gvLvjBg2xvGfdX/ + eGdd9LQ5eeRliAwF14bzXj8W7tiX0CP1kHiXVvhf5/JOX/yxgZ/PeO5T/Kx85SVqcWfV + t/nNqIQxZa7uRHqCYbp+zCHRmM71DGhJbFmTfOXodcG4fiGBnshXkOvhEYdp/aIWzmcx + 5u1dJ4HiVLM14vixXrr/GKqV6KzMc0e1HTY0pxv/6tXQTZOn17/a/QDjubkdjtXewEQU + nteg== +X-Gm-Message-State: AD7BkJLiZJuHlbc/pE4RRANifpQnupyR252sVqmjSzkEKHVR/fWDshMRZ7E8flZ78CWsFw== +X-Received: by 10.98.76.194 with SMTP id e63mr7553592pfj.89.1458769245624; + Wed, 23 Mar 2016 14:40:45 -0700 (PDT) +Received: from ?IPv6:2601:600:9001:8060:3846:59ef:850d:be23? + ([2601:600:9001:8060:3846:59ef:850d:be23]) + by smtp.googlemail.com with ESMTPSA id + k88sm6325593pfj.0.2016.03.23.14.40.44 + (version=TLSv1/SSLv3 cipher=OTHER); + Wed, 23 Mar 2016 14:40:44 -0700 (PDT) +Message-ID: <56F30D62.4090409@voskuil.org> +Date: Wed, 23 Mar 2016 14:40:50 -0700 +From: Eric Voskuil <eric@voskuil.org> +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:31.0) Gecko/20100101 Thunderbird/31.2.0 +MIME-Version: 1.0 +To: Tom <tomz@freedommail.ch>, bitcoin-dev@lists.linuxfoundation.org +References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp> +In-Reply-To: <1983116.UNQS71VxHo@garp> +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; + boundary="IMtfsljsmCuJiOdpeOw5OeuUdeQEdpAHV" +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Thu, 24 Mar 2016 00:40:40 +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 21:40:46 -0000 + +This is an OpenPGP/MIME signed message (RFC 4880 and 3156) +--IMtfsljsmCuJiOdpeOw5OeuUdeQEdpAHV +Content-Type: text/plain; charset=windows-1252 +Content-Transfer-Encoding: quoted-printable + +On 03/23/2016 01:36 PM, Tom via bitcoin-dev wrote: +> On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:= + +> * why would you not allow encryption on non-pre-approved connections? + +Agree + +> * we just removed (ssl) encryption from the JSON interface, how do you = +suggest=20 +> this encryption to be implemented without openSSL? + +CurveCP + +> * 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. + +Agree, P2P and client-server protocols are distinct use-cases. Missing +this distinction is the root cause of problems with the bloom filters +feature. + +> * 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. + +Privacy cannot currently be achieved unless the server is trusted. In +most wallet scenarios that's not a reasonable assumption unless one +controls the full node. So this is only useful in the case where the +wallet is trusting a remote server, and as you point out - message +encryption is weak in this case. In a trustless server scenario +encryption would be unnecessary overhead. + +>> 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? + +Agree, denial of service protection can and should be much more flexible +than this. It's not necessary to incorporate DoS protection into a +protocol. I think maybe this stems from the ill-advised attempt at +messaging reliability. + +>> 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 <code>enc</code> message (leaving out the hash it= +self)=20 +> must be added to the hash-context by both parties. Before sending a=20 +> <code>enc</code> 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. + +Also, this gets into the area of messaging reliability. This is +certainly not something I would recommend for a P2P protocol optimized +for maintaining a cache of public data. + +e + + +--IMtfsljsmCuJiOdpeOw5OeuUdeQEdpAHV +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: OpenPGP digital signature +Content-Disposition: attachment; filename="signature.asc" + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 + +iQEcBAEBCAAGBQJW8w1iAAoJEDzYwH8LXOFOC4oH/29fZErxnsOsGBGroyQSwab3 +2uBpl4p9ZdXk2gImWUWf7EwsHEoblCjdW62Z1/zRFdCPVj1r9VYNeupgv09tg38E +OgiZgoxZnbmOjfK5VMU5qqX96v31/UOYmlbyYh2AZ1+3MVk1JK5RpamIp8roff2U +uVZ9UBHEUwguyu4xUEShnevmWw7MWMrRPSHQlfsMnnGGis6sU45yaue5SDF+6XMZ +k0lTkM5iptC71V+hOhvo9sK3QPz9Ty2wodOfHbbFDfJEqzCPcWdgulXx558fq5kE +B3TTyLnkMrVe6R+U9Fa5XMmatII9eTUTu69ES0KjzsZvRW9gS1q5SCQFwPq9Fiw= +=qHrZ +-----END PGP SIGNATURE----- + +--IMtfsljsmCuJiOdpeOw5OeuUdeQEdpAHV-- + |