From: Eric Voskuil <eric@voskuil.org>
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 <dev@jonasschnelli.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Overhauled BIP151
Precedence: list

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 <bitcoin-dev@list=
s.linuxfoundation.org> 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