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 89B4392 for ; 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 ; Wed, 23 Mar 2016 21:40:45 +0000 (UTC) Received: by mail-pf0-f173.google.com with SMTP id 4so40333881pfd.0 for ; 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Tom , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. 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--