From: Jonas Schnelli <dev@jonasschnelli.ch>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_6D3B5CA4-700E-49B0-8095-9312DEFF60E8";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <640D015D-3DDB-43C4-9752-96ADABF64C91@jonasschnelli.ch>
Date: Mon, 3 Sep 2018 14:16:19 +0200
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Overhauled BIP151
Precedence: list


--Apple-Mail=_6D3B5CA4-700E-49B0-8095-9312DEFF60E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi

During work on the implementation of BIP151 [1] I figured out that the =
current
published proposal could be further optimized.

I wrote an overhauled BIP151 specification with some =E2=80=93 partially =
radical =E2=80=93
changes.

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 =
be
done (which somehow indicates we should alter 151).

The only BIP151 implementation I=E2=80=99m aware of is the one from =
Armory [2].
BCoins implementation has been removed [3].

The new proposal draft is available here:
https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52

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 anything 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.) =
which result in
  some v2 messages require less bandwidth then v1
- rekeying doesn=E2=80=99t require a message and can be signaled in the =
most
  significant bit in the packet-size field


Points that are in discussion and may be added to the BIP (or to a new =
one):

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 =
and is thus not
considered quantum-safe.
Following TORs approach [4] by adding a NewHope [5] key-exchange the =
handshake
protocol would very likely make the encryption PQ safe with little =
costs.
There is also a straight forward implementation [6] from the NewHope =
team that
has been submitted to NIST PQC project.

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=9Ethrows away=E2=80=9C
32 bytes).


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].

I hope we can limit this thread to discuss further ideas for =
optimisation as well as
technical details of the published proposal or its implementation.


[1] https://github.com/bitcoin/bitcoin/pull/14032
[2] https://github.com/goatpig/BitcoinArmory/pull/510
[3] =
https://github.com/bcoin-org/bcoin/commit/41af7acfd68b0492a6442865afd43930=
0708e662
[4] =
https://gitweb.torproject.org/user/isis/torspec.git/plain/proposals/XXX-ne=
whope-hybrid-handshake.txt?h=3Ddraft/newhope
[5] https://eprint.iacr.org/2015/1092
[6] https://github.com/newhopecrypto/newhope

[7] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/0135=
65.html
[8] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.h=
tml


Thanks

--Apple-Mail=_6D3B5CA4-700E-49B0-8095-9312DEFF60E8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAluNJhMACgkQHrd2uwPH
ki2k/w//YN3oLrP1nLZcgwq6lxj52NvcVDVACALzQXFathYqeimdFmiETRv00/Pe
4Q/XqiX+fe6DuS4uo2kmFC8LrpW4EXDGDokxPHxqPpVZISksm04D0BC4ul3Ujvek
O7pDJTdhw6xE/7WOwTz2rTi1s4r4De+r2ToZtiOq7GHlJz3YACwZzUfC4NQdPzob
2+GvpA9pQftvfxgde/dCx2Gg7hzgSajguCzAnLIciKiNPR2vXbMpaDX4NDoc8kcR
Ixjh0Unhw/HsHruIgc09isIYv6r4FJnSPpoAL21sa46fia43G5K8o1xzpwtvdPLx
G0vdmq5fE2XI63mDV8qdE42Zsa1I/PmzndVCSc8T2c+f9MQu528aq8VfhvF4g4WS
WHuiOBoCNUkQdqr+u5exRrfGGa/Vk2veWTxLwOYtzJ7Ko5gXi9jAwS73FVE5iBcS
xnycuPplpO7v0/0qWSdKQLiLdevIKo+nIksANd35nk+GA5rqsCzHx+ozD0BTxjQM
TmEgyqqdFyHz+RH3otQInQQ+YqlQAZpMpThjFrixsRBqCvfSWE755UdIN2gCK9RA
BW9GMluSRRvq4yelcZnVa84G0+iCynjhjre6MA22aULn0KYIqwHXX+fxG67T2eZM
NDtqRscO+8n01Pfw+tS1BF7ZiGQG42s+wmK0NPYkXERLZRugots=
=DUHh
-----END PGP SIGNATURE-----

--Apple-Mail=_6D3B5CA4-700E-49B0-8095-9312DEFF60E8--