Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 60B64ACD for ; Tue, 4 Sep 2018 01:37:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A1EB2C4 for ; Tue, 4 Sep 2018 01:37:35 +0000 (UTC) Received: by mail-pg1-f194.google.com with SMTP id b129-v6so798198pga.13 for ; Mon, 03 Sep 2018 18:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=QoYwVk6OFPQk3nNCfMxSsqfldYIuw5MQMEwWwwysI80=; b=eaMA6LI7qm9c88u9H2BKyyTp5DaDH0i0ExuGp+5oSpYjffN66ht2DJCLMUwWDw1xvS 8JQwoVxR7s6mkjwaV2v6NBMPYcVHU4E7kCbQ3KVZw61iUKrsZgRAbJ9AbSQklnTajAae d364leEyGhyegFB5am4cZ9+2caK/xljOsnabUcxUNFx864BHlYA8h39bWvb9NopFevZE 2tvd7d8B4Cl3d7ylwLwAepxL8AOxogXefNLtzswpcLGkKNymTzhMbdbjNwJn79i2GW+O bb/VbE8vOMn1AhIcVCF5Cy2qMFcJz6hXZlrQekX04u8ulP16nzsRDU0O7LyPNvNQNODT +OcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=QoYwVk6OFPQk3nNCfMxSsqfldYIuw5MQMEwWwwysI80=; b=oPxOI7GOXFZO9MZBeYY04ZmaMdwJSrupUIWmGU2JxIj/wnrlDtYpLiN/xRoaFQWaXk iwjz8aT15OdDhDZlrc7khxd5dxLwjkbKyWq09b2zuzzcAROB0qR301jp/eG9BUnl80pi K65W8J7ZsxOYKED54zjNFoGgvI5W5OxP/F5xaZs5PSAMh4qDavvCR6/QmBMypXWdO9Z3 eeTUx6Px90mG8++nPQKxtrrIO3mx9MqGKVKb5AFzKjSP7VZ2U1FeYQ7C/T+R9g/Vg8UY kZtH4WcoJD64W3hwHX8Sd4xh9qYAR27BKNb2B/o3HMVDvg+C/WR6fd7leuZNeoOtg9re /fEw== X-Gm-Message-State: APzg51Ckorox5S3RZrWqfHQb1ZcgMJxz8Qq5/3CGRoFlia/h51xlPQ6Y VRgCot5tjnoqqM5cFXNXo+xJWUn7J0wHAg== X-Google-Smtp-Source: ANB0VdaiA7veDHkIghuTvlgyTyBAMkw2w1/yGFpLjtDDSVzMh7FEQijQSgsQonWFGy33q05wMe/ftg== X-Received: by 2002:a62:c0a:: with SMTP id u10-v6mr32474052pfi.43.1536025054870; Mon, 03 Sep 2018 18:37:34 -0700 (PDT) Received: from ?IPv6:2600:380:446d:ccf4:a42c:4fae:e0c5:87fb? ([2600:380:446d:ccf4:a42c:4fae:e0c5:87fb]) by smtp.gmail.com with ESMTPSA id z17-v6sm32795120pfl.146.2018.09.03.18.37.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 18:37:34 -0700 (PDT) From: Eric Voskuil Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Tue, 4 Sep 2018 10:37:30 +0900 Message-Id: <3AA959AE-B0F5-459F-A6BA-50D91C746B5D@voskuil.org> References: <640D015D-3DDB-43C4-9752-96ADABF64C91@jonasschnelli.ch> In-Reply-To: <640D015D-3DDB-43C4-9752-96ADABF64C91@jonasschnelli.ch> To: Jonas Schnelli , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (15G77) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE 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: Tue, 04 Sep 2018 01:41:10 +0000 Subject: Re: [bitcoin-dev] Overhauled BIP151 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 01:37:36 -0000 Without commenting on the other merits of either proposal, the addition of t= he service flag resolves bip151=E2=80=99s previously-discussed lack of backw= ard compatibility. e > On Sep 3, 2018, at 21:16, Jonas Schnelli via bitcoin-dev wrote: >=20 > Hi >=20 > During work on the implementation of BIP151 [1] I figured out that the cur= rent > published proposal could be further optimized. >=20 > I wrote an overhauled BIP151 specification with some =E2=80=93 partially r= adical =E2=80=93 > changes. >=20 > Now it=E2=80=99s unclear to me if this should be published under a new BIP= nr. or if it > is acceptable to change the existing 151 proposal. > If a new BIP number would be required, I think withdrawing BIP151 should b= e > done (which somehow indicates we should alter 151). >=20 > The only BIP151 implementation I=E2=80=99m aware of is the one from Armory= [2]. > BCoins implementation has been removed [3]. >=20 > The new proposal draft is available here: > https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52 >=20 > Major changes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - the encryption handshake no longer requires the v1 protocol, it=E2=80=99= s a pure > 32bytes-per-side =E2=80=9Epseudorandom" key exchange that happens before a= nything else. > - the multi message envelope has been removed. > - a new NODE_ENCRYPTED service bit > - the key derivation and what communication direction uses what key is now= more > specific > - the length of a packet uses now a 3-byte integer with 23 available bits > - introduction of short-command-ID (ex.: uint8_t 13 =3D=3D INV, etc.) whic= h result in > some v2 messages require less bandwidth then v1 > - rekeying doesn=E2=80=99t require a message and can be signaled in the mo= st > significant bit in the packet-size field >=20 >=20 > Points that are in discussion and may be added to the BIP (or to a new one= ): >=20 > Hybrid NewHope key exchange > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > The current ECDH key exchange is vulnerable to Shor=E2=80=99s algorithm an= d is thus not > considered quantum-safe. > Following TORs approach [4] by adding a NewHope [5] key-exchange the hands= hake > protocol would very likely make the encryption PQ safe with little costs. > There is also a straight forward implementation [6] from the NewHope team t= hat > has been submitted to NIST PQC project. >=20 > Inefficiency of ChaCha20Poly1305@openssh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The proposed AEAD could eventually be further optimized. > ChaCha20Poly1305@openssh uses at least three rounds of ChaCha20 which > eventually can be reduced to two (messages below <=3D64 bytes [inv, ping, > pong,...] only require one round of ChaCha20, but two for the Poly1305 key= and > the message length encryption where the Poly1305 key chacha round =E2=80=9E= throws away=E2=80=9C > 32 bytes). >=20 >=20 > I would suggest that we don=E2=80=99t rehash discussions about the general= > concept of encrypting the traffic. This has already been discussed [7][8].= >=20 > I hope we can limit this thread to discuss further ideas for optimisation a= s well as > technical details of the published proposal or its implementation. >=20 >=20 > [1] https://github.com/bitcoin/bitcoin/pull/14032 > [2] https://github.com/goatpig/BitcoinArmory/pull/510 > [3] https://github.com/bcoin-org/bcoin/commit/41af7acfd68b0492a6442865afd4= 39300708e662 > [4] https://gitweb.torproject.org/user/isis/torspec.git/plain/proposals/XX= X-newhope-hybrid-handshake.txt?h=3Ddraft/newhope > [5] https://eprint.iacr.org/2015/1092 > [6] https://github.com/newhopecrypto/newhope >=20 > [7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/= 013565.html > [8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/0128= 26.html >=20 >=20 > Thanks > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev