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
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
|
Return-Path: <fireduck@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DBFA7411
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 23:07:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com
[209.85.212.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9484112A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 23:07:23 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so124029369wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 16:07:22 -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
:content-type; bh=SzdsDtH0vI2Wm6RowJf4msj9GtVYHsbHKAWXPGifRig=;
b=ZoiLHB77hC30dS+nT9EmnJFYvglfl/nv2jU3QdRmSQJoORAZWZ2C/yCR9J8GsBTkI4
kIaWHWsMA3zkV916RfAABbvV7uk1vqJQhmilCN9R2qLLUYVUhOnGY1+zGqIhKz9+KbkZ
YV9CjII2ZruZ/OMQ+rbeuu5yeKM8AvVw5vgEdcA3fLiTARt6o7mJbYILL7G7hBj2Ush+
lTNkNtshSXnsN516vUw0L8wXJZ+8+NVAKYqyBO+g2Y/UzxfwpH/nqg6AMrgGQGDuN2yn
CO35Dy5jfTplvEQwlBLLaFr1X9DoX4v3GKRFGuorHrq00R8Pc35FMEnqhIQ+Xa6RLQQ+
oO2A==
X-Received: by 10.194.87.102 with SMTP id w6mr9160448wjz.111.1437606442205;
Wed, 22 Jul 2015 16:07:22 -0700 (PDT)
MIME-Version: 1.0
References: <55AFBBE6.3060702@electrum.org> <55AFC52C.3010700@voskuil.org>
<55B01731.6070306@voskuil.org>
In-Reply-To: <55B01731.6070306@voskuil.org>
From: =?UTF-8?B?Sm9zZXBoIEdsZWFzb24g4pGI?= <fireduck@gmail.com>
Date: Wed, 22 Jul 2015 23:07:12 +0000
Message-ID: <CA+ASnrFxPtxE2vsDS4dz2FxddAtW5fQK=gkBbrPVp878zeV_Hw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>, Thomas Voegtlin <thomasv@electrum.org>,
bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=047d7bf19850508a07051b7ed57b
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
Subject: Re: [bitcoin-dev] Making Electrum more anonymous
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, 22 Jul 2015 23:07:25 -0000
--047d7bf19850508a07051b7ed57b
Content-Type: text/plain; charset=UTF-8
I would recommend the following solution as a decent compromise between
complexity and privacy:
1) Encourage electrum server operators to have their servers reachable as
tor hidden services (.onion addresses)
2) Make sure server discovery works well with .onion addresses
3) Make the privacy a user configurable setting:
- None - Allows any server connection type
- SSL - Requires SSL at least, no plain text
- Tor - Requires tor, no direct TCP
- Multi-Tor - Uses a variety of tor paths to reach a variety of servers
(maybe configurable number of servers)
Default should be 'SSL' probably.
On Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I should add that the obvious resolution to this set of problems is to
> use a distinct Tor route for each Bitcoin address, not to reinvent Tor
> and reproduce its community. So ultimately this is easy to implement,
> but the downside is performance.
>
> But it's important to keep in mind that poor-performing perfect privacy
> for address monitoring is trivial to achieve - just sync the full
> blockchain.
>
> Presumably if you don't trust a server to protect your privacy, you also
> don't trust it with your money. So any robust privacy optimization would
> at least be designed to support partial (SPV) chain clients. It would
> also need to support wallet restoration from backup.
>
> The level of privacy will always be a performance trade-off. The ideal
> solution would allow a client to balance privacy against performance.
>
> e
>
> On 07/22/2015 09:30 AM, Eric Voskuil wrote:
> > Hi Thomas,
> >
> > The scheme is essentially onion routing. The set of {M} are entry nodes
> > and the set of {S} are exit nodes. The weaknesses are as you would see
> > in an analogous TOR implementation:
> >
> > (1) The lack of relay nodes {R} make collaboration between any subset of
> > {M} and {S} trivial.
> >
> > (2) OR is a mixnet, so the size of the network matters a lot.
> >
> > (3) The directory is a perpetual weakness.
> >
> > (4) Content is visible to the exit node (or the final service). This
> > means each address must be passed via a distinct route to prevent
> > correlation.
> >
> > e
> >
> > On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:
> >> Hello,
> >>
> >> Although Electrum clients connect to several servers in order to fetch
> >> block headers, they typically request address balances and address
> >> histories from a single server. This means that the chosen server knows
> >> that a given set of addresses belong to the same wallet. That is true
> >> even if Electrum is used over TOR.
> >>
> >> There have been various proposals to improve on that, but none of them
> >> really convinced me so far. One recurrent proposal has been to create
> >> subsets of wallet addresses, and to send them to separate servers. In my
> >> opinion, this does not really improve anonymity, because it requires
> >> trusting more servers.
> >>
> >> Here is an idea, inspired by TOR, on which I would like to have some
> >> feedback: We create an anonymous routing layer between Electrum servers
> >> and clients.
> >>
> >> * Each server S publishes a RSA public key, KS
> >> * Each client receives a list of available servers and their pubkeys
> >> * For each wallet address, addr_i, a client chooses a server S_i, and a
> >> RSA keypair (K_addr_i, k_addr_i)
> >> * The client creates a list of encrypted requests. Each request contains
> >> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> >> * The client chooses a main server M, and sends the list of encrypted
> >> requests to M
> >> * M dispatches the client's requests to the corresponding servers S_i
> >> (without the client's IP address.)
> >> * Each server decrypts the requests it receives, performs the request,
> >> and encrypts the result with K_addr_i
> >> * M receives encrypted responses, and forwards them to the client.
> >> * The client decrypts the encrypted response with k_addr_i
> >>
> >> What do you think? What are the costs and benefits of such an approach?
> >>
> >> (Note: this will not work if all servers, or a large fraction of them,
> >> are controlled by the same entity that controls M)
> >>
> >>
> >> Thomas
> >> _______________________________________________
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--047d7bf19850508a07051b7ed57b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would recommend the following solution as a decent compr=
omise between complexity and privacy:<div><br></div><div>1) Encourage elect=
rum server operators to have their servers reachable as tor hidden services=
(.onion addresses)</div><div>2) Make sure server discovery works well with=
.onion addresses</div><div>3) Make the privacy a user configurable setting=
:</div><div>=C2=A0 - None - Allows any server connection type</div><div>=C2=
=A0 - SSL - Requires SSL at least, no plain text</div><div>=C2=A0 - Tor - R=
equires tor, no direct TCP</div><div>=C2=A0 - Multi-Tor - Uses a variety of=
tor paths to reach a variety of servers (maybe configurable number of serv=
ers)</div><div><br></div><div>Default should be 'SSL' probably.</di=
v><div><br></div><div><br></div><div><br></div><div><br></div><div><br></di=
v><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev <=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>I should add that the obvious resolution to this set of problems is to<br>
use a distinct Tor route for each Bitcoin address, not to reinvent Tor<br>
and reproduce its community. So ultimately this is easy to implement,<br>
but the downside is performance.<br>
<br>
But it's important to keep in mind that poor-performing perfect privacy=
<br>
for address monitoring is trivial to achieve - just sync the full<br>
blockchain.<br>
<br>
Presumably if you don't trust a server to protect your privacy, you als=
o<br>
don't trust it with your money. So any robust privacy optimization woul=
d<br>
at least be designed to support partial (SPV) chain clients. It would<br>
also need to support wallet restoration from backup.<br>
<br>
The level of privacy will always be a performance trade-off. The ideal<br>
solution would allow a client to balance privacy against performance.<br>
<br>
e<br>
<br>
On 07/22/2015 09:30 AM, Eric Voskuil wrote:<br>
> Hi Thomas,<br>
><br>
> The scheme is essentially onion routing. The set of {M} are entry node=
s<br>
> and the set of {S} are exit nodes. The weaknesses are as you would see=
<br>
> in an analogous TOR implementation:<br>
><br>
> (1) The lack of relay nodes {R} make collaboration between any subset =
of<br>
> {M} and {S} trivial.<br>
><br>
> (2) OR is a mixnet, so the size of the network matters a lot.<br>
><br>
> (3) The directory is a perpetual weakness.<br>
><br>
> (4) Content is visible to the exit node (or the final service). This<b=
r>
> means each address must be passed via a distinct route to prevent<br>
> correlation.<br>
><br>
> e<br>
><br>
> On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:<br>
>> Hello,<br>
>><br>
>> Although Electrum clients connect to several servers in order to f=
etch<br>
>> block headers, they typically request address balances and address=
<br>
>> histories from a single server. This means that the chosen server =
knows<br>
>> that a given set of addresses belong to the same wallet. That is t=
rue<br>
>> even if Electrum is used over TOR.<br>
>><br>
>> There have been various proposals to improve on that, but none of =
them<br>
>> really convinced me so far. One recurrent proposal has been to cre=
ate<br>
>> subsets of wallet addresses, and to send them to separate servers.=
In my<br>
>> opinion, this does not really improve anonymity, because it requir=
es<br>
>> trusting more servers.<br>
>><br>
>> Here is an idea, inspired by TOR, on which I would like to have so=
me<br>
>> feedback: We create an anonymous routing layer between Electrum se=
rvers<br>
>> and clients.<br>
>><br>
>> * Each server S publishes a RSA public key, KS<br>
>> * Each client receives a list of available servers and their pubke=
ys<br>
>> * For each wallet address, addr_i, a client chooses a server S_i, =
and a<br>
>> RSA keypair (K_addr_i, k_addr_i)<br>
>> * The client creates a list of encrypted requests. Each request co=
ntains<br>
>> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i<=
br>
>> * The client chooses a main server M, and sends the list of encryp=
ted<br>
>> requests to M<br>
>> * M dispatches the client's requests to the corresponding serv=
ers S_i<br>
>> (without the client's IP address.)<br>
>> * Each server decrypts the requests it receives, performs the requ=
est,<br>
>> and encrypts the result with K_addr_i<br>
>> * M receives encrypted responses, and forwards them to the client.=
<br>
>> * The client decrypts the encrypted response with k_addr_i<br>
>><br>
>> What do you think? What are the costs and benefits of such an appr=
oach?<br>
>><br>
>> (Note: this will not work if all servers, or a large fraction of t=
hem,<br>
>> are controlled by the same entity that controls M)<br>
>><br>
>><br>
>> Thomas<br>
>> _______________________________________________<br>
><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>
--047d7bf19850508a07051b7ed57b--
|
