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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2EBE549F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 16:30:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com
[209.85.192.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A316220
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 16:30:26 +0000 (UTC)
Received: by pdjr16 with SMTP id r16so143608478pdj.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 09:30:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type;
bh=ZLomUzxcUa38csPitwD4kOdBTZJWKMpi34yTXm/yysU=;
b=O6Brap4vwwcflMLo2NC6t69B9EgOdCgmNJBIaLTNtNEBGl6WxtsKFIotwKFuVd3x5H
2bj8827xCNg2q01yezPY0uKZ9ZCI3jxK4kicS0QmgEnPDRAmtJoGKaC/4EvDvi7mmXzQ
45K/KaSvwQ5dM6Dic131lUk98jz6ECur5YtF3w6Bk1gjHbq+mrf+x2JGkAq2Rc6Ed7ZD
hyYhCxwuU2qZg3dY6iAG+t2sOK3JZO1AlcJUHyhoawkYgT5flEno4pjR5Eb0U5nDCHsz
Q0oAHrvb3CbL1vFJquGp6j/g12g7fSn2qHamC2x517aRS+ibNlwOy8ByUP1O0U5nzBRg
TaFw==
X-Gm-Message-State: ALoCoQn/vO1bISjw+87go9oq3loUM18y1QksSR1gDi6MNloyeoytJo6sN/Po1xadjcZBa39sWY5p
X-Received: by 10.70.0.166 with SMTP id 6mr7427285pdf.119.1437582625963;
Wed, 22 Jul 2015 09:30:25 -0700 (PDT)
Received: from [10.0.1.14] (c-67-161-88-20.hsd1.wa.comcast.net. [67.161.88.20])
by smtp.googlemail.com with ESMTPSA id
db1sm4181775pdb.50.2015.07.22.09.30.24
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 22 Jul 2015 09:30:25 -0700 (PDT)
Message-ID: <55AFC52C.3010700@voskuil.org>
Date: Wed, 22 Jul 2015 09:30:36 -0700
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Thomas Voegtlin <thomasv@electrum.org>,
bitcoin-dev@lists.linuxfoundation.org
References: <55AFBBE6.3060702@electrum.org>
In-Reply-To: <55AFBBE6.3060702@electrum.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="R41HAEEXAFJXH6OoxxJqVtLV6HhDkQiDm"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 16:30:28 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--R41HAEEXAFJXH6OoxxJqVtLV6HhDkQiDm
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
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,
>=20
> 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.
>=20
> 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 m=
y
> opinion, this does not really improve anonymity, because it requires
> trusting more servers.
>=20
> 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.
>=20
> * 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 contain=
s
> 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
>=20
> What do you think? What are the costs and benefits of such an approach?=
>=20
> (Note: this will not work if all servers, or a large fraction of them,
> are controlled by the same entity that controls M)
>=20
>=20
> Thomas
> _______________________________________________
--R41HAEEXAFJXH6OoxxJqVtLV6HhDkQiDm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVr8UsAAoJEDzYwH8LXOFORVgIAIKEbkDltsIV7bGwVohuDico
0PSS5hmFhmH2ATCBdLKppqqF3s6GIs07XTPDpofGUZdDxd+Hl2fa4p6+HLlN0pV6
gc9WeXl9FDJJ4YohvoXD1u6oWfEJ27Jfoou29pmoiw9r1vDZThI22TIt9B6sxZjA
XNw7YYT8+YRsBmCuj0iJmpQL1eQb90tSqgoRi+f+f+6AVstpGfWbkAXTiZq9Xy36
G+ZaoJKko8jU3/UrAYK8fTZMMA77lyFZJgm6JshxGauUH0cjRIxqM4kYoo+8uqH4
SDtqB8Pe8LewNoIgUdlqk2WnXNBvGvrfVQkDBddekbRlPHNaX2ImgBX1Dapgoio=
=YIy2
-----END PGP SIGNATURE-----
--R41HAEEXAFJXH6OoxxJqVtLV6HhDkQiDm--
|
