summaryrefslogtreecommitdiff
path: root/20/ff50316f1daa29108d85f3d9c2500e48540afd
blob: bb24fb9db26aaf03120c46b64fe9b4e3cd5e4c1c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A28B1D21
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Sep 2018 12:16:25 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch
	[138.201.55.219])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id B4D872C4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Sep 2018 12:16:24 +0000 (UTC)
Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002)
	id 6CA2815E1982; Mon,  3 Sep 2018 14:16:23 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.1
Received: from [192.168.0.9] (cable-static-239-93.teleport.ch [213.188.239.93])
	by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id F17DB15E01F4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Sep 2018 14:16:22 +0200 (CEST)
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>
X-Mailer: Apple Mail (2.3445.9.1)
X-Virus-Scanned: clamav-milter 0.100.1 at bitcoinsrv.jonasschnelli.ch
X-Virus-Status: Clean
X-Mailman-Approved-At: Mon, 03 Sep 2018 23:25:52 +0000
Subject: [bitcoin-dev] Overhauled BIP151
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Mon, 03 Sep 2018 12:16:25 -0000


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