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
|
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BE31F482
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 15:51:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net
[217.70.183.197])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4AF7416A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 15:51:06 +0000 (UTC)
Received: from mfilter29-d.gandi.net (mfilter29-d.gandi.net [217.70.178.160])
by relay5-d.mail.gandi.net (Postfix) with ESMTP id 05ECD41C06A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 17:51:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter29-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
by mfilter29-d.gandi.net (mfilter29-d.gandi.net [10.0.15.180])
(amavisd-new, port 10024) with ESMTP id Ap9dNrgt4u6q
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 17:51:02 +0200 (CEST)
X-Originating-IP: 178.19.221.38
Received: from [10.10.42.132] (unknown [178.19.221.38])
(Authenticated sender: thomasv@electrum.org)
by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 99E7841C06C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 17:51:02 +0200 (CEST)
Message-ID: <55AFBBE6.3060702@electrum.org>
Date: Wed, 22 Jul 2015 17:51:02 +0200
From: Thomas Voegtlin <thomasv@electrum.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_05,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: [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 15:51:06 -0000
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
|
