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
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
|
Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 159C574
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Mar 2016 17:04:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com
[209.85.218.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 06341AF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Mar 2016 17:04:40 +0000 (UTC)
Received: by mail-oi0-f52.google.com with SMTP id r187so147703597oih.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Mar 2016 10:04:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=LWN4V4Kws3ejpsWizw0vfS09ar+cHwLW7fFLVdUzs5I=;
b=HQVfZxOYeHeBS63bN6Up6hLvZF5+9cPjcTLX/R+MI+7vrE8ETEFWJ/0dmEKqzAFMgq
at5PRrNGyYMsDh79UHBNu5tOcGzGjxAAvDuhn9g4UyJqIllE+tjFFyjpGfHnVULTatmE
PqdViCgiKxOYRiljnv1XrKhaYBggR+uXuMSozUzY8SIrskjo7wjk2XVHAueN0ouR2TEW
cZHodauJ3rl2m3dXul4XJV5BZRWT9+a+7QWyEWsVNsZ2pW0dXAFBSDRgZ/ad6QoT/lPS
sRQASIuHSrLswUXjBEzxp6AJqjAnFdQ38Pdsx+CumoOjDK5ynbA3RgCg4Ype71LEjzNN
kUfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=LWN4V4Kws3ejpsWizw0vfS09ar+cHwLW7fFLVdUzs5I=;
b=e5SduyU3uj+PYXfMY7rKZT2ESBfqs+nxjcktPxj6pJXOFx4vlL16u2/0dmtulXekx4
LpehhayLsbgvNTPU7T4FQIMFzyRUfCGMp/fJV1c6xzZmf2hyz5amzhNLTGg3bXgTRMeq
vCvBUmY7Cwjomn1o5L7QDZG6YDOwHux06S7zjOZJHY89b8wHxVSj9gQFQw/bN3JLjzNb
mMG3vP1cQKsimcy799cY6yBZFY0KTDqfrCWrRJZpqbptuHDI5VWON9cHSKHrgq4uxeu+
vbNlze01ZHaUPfGwIJ54PA/tLjRUEl/4abIkbz0aHiZJEpYzxrw4AODeuKnGXZ4Yfh7l
/mEg==
X-Gm-Message-State: AD7BkJJ7W+ysyS+n4YgYxR2PsJ+pfdnh2rrFw2C+10JiFGgX4Tox/Koqcn24INBC39DLLJpo6ihzOAEikqKVWw==
X-Received: by 10.157.47.181 with SMTP id r50mr505937otb.107.1459098280211;
Sun, 27 Mar 2016 10:04:40 -0700 (PDT)
MIME-Version: 1.0
References: <56F2B51C.8000105@jonasschnelli.ch> <2590065.B4dTBeyc1A@garp>
<56F586B4.8020507@jonasschnelli.ch> <4517402.JLxTDjem5X@garp>
<CAH+Axy7cyZXzAHE7bfGxyMF8oxy=hpOW9nFd5KiLnVab3b=qCA@mail.gmail.com>
<56F7CAD3.9080809@jonasschnelli.ch>
In-Reply-To: <56F7CAD3.9080809@jonasschnelli.ch>
From: James MacWhyte <macwhyte@gmail.com>
Date: Sun, 27 Mar 2016 17:04:30 +0000
Message-ID: <CAH+Axy7RiWtQDZCLq7uwgzTAbKz7sHO6POivrMHag46Z-iFmiw@mail.gmail.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113dc29caf3948052f0aca0d
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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, 29 Mar 2016 14:34:44 +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: Sun, 27 Mar 2016 17:04:42 -0000
--001a113dc29caf3948052f0aca0d
Content-Type: text/plain; charset=UTF-8
On Sun, Mar 27, 2016 at 5:49 AM Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > I guess my question didn't get across.
> >
> > Why would you want to make your usecase do connections over the
> > peer2peer
> > (net.cpp) connection at all?
> >
> > Mixing messages that are being sent to everyone and encrypted
> > messages is
> > asking for trouble.
> > Making your private connection out-of-band would work much better.
> >
> >
> > I agree doing it out-of-band is the easiest solution for people who need
> > this privacy right now, but I do like the idea of adding this feature as
> > the number of SPV wallets is going to increase. I think the best way to
> > organize things would be to give encrypted messages their own port
> > number, similar to how http vs. https works.
>
> I'm not sure if different ports would make sense. I can't see a benefit
> (happy if someone can convince me).
> How would this affect p2p address management (address relay)? Wouldn't
> this require to extend the current address message to support two port
> numbers?
>
> I'm assuming clients that connect with encryption don't want to use
unencrypted connections, and are only interested in other peers that
support encryption. From their perspective, it is quite inefficient to get
a generic list of peers and then have to connect to each one searching for
those that accept encryption. If we use port numbers, we can assume any
connection that comes on the encrypted port is only interested in encrypted
communication, so a getaddr to an encrypted port would only return a list
of other encryption-capable peers.
This isn't an issue if the plan is to require all peers to support
encryption, and we assume the majority of the network will upgrade before
too long.
>
> > We don't want two networks to develop, separated by which nodes support
> > encryption and which don't, so ideally nodes would rebroadcast messages
> > they receive on both (encrypted and non-encrypted) channels. This would
> > essentially double the required bandwidth of the network, which is
> > something to think about.
>
> It can be the same "p2p network". The only difference would be, that
> once two peers has negotiated encryption, the whole traffic between
> _these two peers_, and _only_ these two pears, would be encrypted (would
> _not_ affect traffic to/from other peers).
>
>
You're right, there would not be an increase in bandwidth. Please forget I
said that :) But following the logic I wrote above, it would be possible
for peers to become segregated (those who require encryption would only
connect to each other). It wouldn't be a problem as long as there are
enough peers that provide both encrypted and non-encrypted connections; or,
as I said above, if we can assume every peer will support it. Maybe the
issues I'm thinking of are just growing pains that will be solved once the
majority of people upgrade?
> A simplified example:
> 1. Peer Alice connects to peer Bob
> 2. Alice asks Bob: "lets do encrypted communication, here is my session
> pubkey"
> 3. Bob also supports encryption and answers "Yes, let's do this, here is
> my session pubkey"
> 4. Alice tells Bob (encrypted now): "Perfect. Here I prove that I'm
> Alice by signing the session ID with my identity pubkey"
> 5. Bob checks his "authorized-peers" database and look-up Alices pubkey
> and verifies the signatures.
> 6. Bob tells Alice: "Good! I trust you now Alice, here is my identity
> pubkey with a signature of our session-ID"
> 7. Alice looks up Bobs pubkey in her "known-peers" database and verifies
> the signature.
> 8. Alice response to bob: "Perfect. Indeed, you are Bob!"
> ---
> At this point, the communication is encrypted and the identities has
> been verified (MITM protection).
>
>
> (simplified negotiation [only one-way, missing dh explanation, missing
> KDF, session-ID, cipher suite nego., missing re-keying, etc.])
>
>
> </jonas>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113dc29caf3948052f0aca0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun=
, Mar 27, 2016 at 5:49 AM Jonas Schnelli via bitcoin-dev <<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundatio=
n.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
>=C2=A0 =C2=A0 =C2=A0I guess my question didn't get across.<br>
><br>
>=C2=A0 =C2=A0 =C2=A0Why would you want to make your usecase do connecti=
ons over the<br>
>=C2=A0 =C2=A0 =C2=A0peer2peer<br>
>=C2=A0 =C2=A0 =C2=A0(net.cpp) connection at all?<br>
><br>
>=C2=A0 =C2=A0 =C2=A0Mixing messages that are being sent to everyone and=
encrypted<br>
>=C2=A0 =C2=A0 =C2=A0messages is<br>
>=C2=A0 =C2=A0 =C2=A0asking for trouble.<br>
>=C2=A0 =C2=A0 =C2=A0Making your private connection out-of-band would wo=
rk much better.<br>
><br>
><br>
> I agree doing it out-of-band is the easiest solution for people who ne=
ed<br>
> this privacy right now, but I do like the idea of adding this feature =
as<br>
> the number of SPV wallets is going to increase. I think the best way t=
o<br>
> organize things would be to give encrypted messages their own port<br>
> number, similar to how http vs. https works.<br>
<br>
I'm not sure if different ports would make sense. I can't see a ben=
efit<br>
(happy if someone can convince me).<br>
How would this affect p2p address management (address relay)? Wouldn't<=
br>
this require to extend the current address message to support two port<br>
numbers?<br>
<br></blockquote><div>I'm assuming clients that connect with encryption=
don't want to use unencrypted connections, and are only interested in =
other peers that support encryption. From their perspective, it is quite in=
efficient to get a generic list of peers and then have to connect to each o=
ne searching for those that accept encryption. If we use port numbers, we c=
an assume any connection that comes on the encrypted port is only intereste=
d in encrypted communication, so a getaddr to an encrypted port would only =
return a list of other encryption-capable peers.<br><br>This isn't an i=
ssue if the plan is to require all peers to support encryption, and we assu=
me the majority of the network will upgrade before too long.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<br>
> We don't want two networks to develop, separated by which nodes su=
pport<br>
> encryption and which don't, so ideally nodes would rebroadcast mes=
sages<br>
> they receive on both (encrypted and non-encrypted) channels. This woul=
d<br>
> essentially double the required bandwidth of the network, which is<br>
> something to think about.<br>
<br>
It can be the same "p2p network". The only difference would be, t=
hat<br>
once two peers has negotiated encryption, the whole traffic between<br>
_these two peers_, and _only_ these two pears, would be encrypted (would<br=
>
_not_ affect traffic to/from other peers).<br>
<br></blockquote><div><br></div><div>You're right, there would not be a=
n increase in bandwidth. Please forget I said that :) But following the log=
ic I wrote above, it would be possible for peers to become segregated (thos=
e who require encryption would only connect to each other). It wouldn't=
be a problem as long as there are enough peers that provide both encrypted=
and non-encrypted connections; or, as I said above, if we can assume every=
peer will support it. Maybe the issues I'm thinking of are just growin=
g pains that will be solved once the majority of people upgrade?<br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
A simplified example:<br>
1. Peer Alice connects to peer Bob<br>
2. Alice asks Bob: "lets do encrypted communication, here is my sessio=
n<br>
pubkey"<br>
3. Bob also supports encryption and answers "Yes, let's do this, h=
ere is<br>
my session pubkey"<br>
4. Alice tells Bob (encrypted now): "Perfect. Here I prove that I'=
m<br>
Alice by signing the session ID with my identity pubkey"<br>
5. Bob checks his "authorized-peers" database and look-up Alices =
pubkey<br>
and verifies the signatures.<br>
6. Bob tells Alice: "Good! I trust you now Alice, here is my identity<=
br>
pubkey with a signature of our session-ID"<br>
7. Alice looks up Bobs pubkey in her "known-peers" database and v=
erifies<br>
the signature.<br>
8. Alice response to bob: "Perfect. Indeed, you are Bob!"<br>
---<br>
At this point, the communication is encrypted and the identities has<br>
been verified (MITM protection).<br>
<br>
<br>
(simplified negotiation [only one-way, missing dh explanation, missing<br>
KDF, session-ID, cipher suite nego., missing re-keying, etc.])<br>
<br>
<br>
</jonas><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
--001a113dc29caf3948052f0aca0d--
|