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
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
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 14A2B97
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Mar 2016 21:55:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 36ED0F0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Mar 2016 21:55:40 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id 28CF52E200F3; Wed, 23 Mar 2016 22:55:38 +0100 (CET)
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, FSL_HELO_NON_FQDN_1
autolearn=ham version=3.3.1
Received: from Jonass-MacBook-Pro.local (cable-static-140-182.teleport.ch
[87.102.140.182]) by server3 (Postfix) with ESMTPSA id F21A82D0046E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Mar 2016 22:55:37 +0100 (CET)
To: bitcoin-dev@lists.linuxfoundation.org
References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <56F310D6.2070002@jonasschnelli.ch>
Date: Wed, 23 Mar 2016 22:55:34 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <1983116.UNQS71VxHo@garp>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="fv4CcBhOIQEAQL0isBelQJ3jeGxCheAkH"
X-Mailman-Approved-At: Thu, 24 Mar 2016 00:40:50 +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 <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: Wed, 23 Mar 2016 21:55:41 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fv4CcBhOIQEAQL0isBelQJ3jeGxCheAkH
Content-Type: multipart/mixed; boundary="v1BmlgGGg4mEa9oLwbAVme1qRkJA8Ijkq"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <56F310D6.2070002@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp>
In-Reply-To: <1983116.UNQS71VxHo@garp>
--v1BmlgGGg4mEa9oLwbAVme1qRkJA8Ijkq
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
>> I have just PRed a draft version of two BIPs I recently wrote.
>> https://github.com/bitcoin/bips/pull/362
>=20
> I suggest running a spellchecker ;)
Thanks. Will do.
> * why would you not allow encryption on non-pre-approved connections?
The encryption should be optional.
The proposed authentication scheme does take care of the
identity-management and therefor prevent MITM attacks.
Without the identity management, you might not detect sending/receiving
encrypted data from/to a MITM.
> * we just removed (ssl) encryption from the JSON interface, how do you =
suggest=20
> this encryption to be implemented without openSSL?
The proposed encryption schema is based on ECDSA/ECDH (implemented in
libsecp256k1) and AES256CBC (implementation is on the way see
https://github.com/bitcoin/bitcoin/pull/7689).
OpenSSL is not required.
> * 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.
Most known use-case: SPV.
> * 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.
It's probably extremely inefficient to create a constant time stream.
Even most SSL/SSH application leak information because of the
communication message characteristics.
The current wrapping message proposal is not very efficient.
I will change it so that the p2p message header will contain the
encryption metadata. This should lead to a tiny overhead.
>=20
>> 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?
Good point. Maybe one false try should lead to ignoring the peer.
>=20
>=20
>> 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 <code>enc</code> message (leaving out the hash it=
self)=20
> must be added to the hash-context by both parties. Before sending a=20
> <code>enc</code> 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.
This is a relative simple concept and does not require rehashing the
whole communication. You just append the "new data".
Some pseudocode:
SHA256CTX ctx;
// first com
SHA256CTX_Update(ctx, 1stmessage);
// copy context
SHA256CTX ctxnew =3D ctx;
// finalize the copied context
sha256hash =3D SHA256CTX_Finalize(ctxnew); //use as checksum hash
//////// next message
SHA256CTX_Update(ctx, 2ndmessage);
// copy context
SHA256CTX ctxnew =3D ctx;
// finalize the copied context
sha256hash =3D SHA256CTX_Finalize(ctxnew); //use as checksum hash
=2E.. etc.
</jonas>
--v1BmlgGGg4mEa9oLwbAVme1qRkJA8Ijkq--
--fv4CcBhOIQEAQL0isBelQJ3jeGxCheAkH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJW8xDWAAoJECnUvLZBb1Ps79kP/1oTbMezXCmrJi5D5Q2itvrv
8FFsfVPtAerosmWPC8lYEhh5y+SZMu2jzxLu4icVefSdQg+KOccEQXa678oWX7u/
v3agcHL5iYQ4R4KB2OQyIgVvrnYDyeO7oAGLzrSnXEduUgpN9LBGAHTGN/9pPATy
zKFLfaVnY3xzWt+Imgw+H4er+S3CMeV6xOqrI2lhhcCltQYO9Yg8jYkScOvHydbd
l9J2V70Q0u6+D0VeU6rjDqh9QRqg16hQoC78ADiCSq6RSRFzqvzScueyg5JOuY5c
0Y5Qp+XvyUXyD5Nllqb6VJhWk4nAJp8xAX+AHKrsoCHBFcpSEAo5W6KkOyost/Wm
DiQBPpW92oLZPLj8mfFBL8/iXseucigiCuEvnjn1Bs6bCjcpoq3YG8gTlMf04ndC
PbzxHJD/sFwiXxQ7D6T9p3GQpVBV08qecErl6v/rbcjJUfFU6U3+ieJjNRPgS4Sf
v+H+eSZm/GrXLUlfYONQDZv3SznpjZ9zQSFy++BEiB9ANNsnr054290ZantIV6L4
hIJgYpVXgNQAkBLS/Wupl+z6I+DJpyU0TwD3bem7trKFLSLguLS2rLdb3Wbf05nM
kzR8102aFeAfcbz3Ty5DI0mdAFlGJ4+Da1/YLAe3z9wWRya1W2hXdgPBYUA/fRWH
Iwj3C8kmFATPrVPl73o0
=bAhm
-----END PGP SIGNATURE-----
--fv4CcBhOIQEAQL0isBelQJ3jeGxCheAkH--
|
