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
|
Return-Path: <s7r@sky-ip.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8A695279
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jul 2015 11:12:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com
[162.222.225.20])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id A9E0279
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jul 2015 11:12:47 +0000 (UTC)
Received: from [0.0.0.0] (bolobolo1.torservers.net [96.47.226.20])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: s7r@sky-ip.org)
by outbound.mailhostbox.com (Postfix) with ESMTPSA id 42282782B07;
Fri, 24 Jul 2015 11:12:45 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
s=20110108; t=1437736367;
bh=DQ8TeHwdeBxaDalsJCu5SKtNMbIgmMjeRf6FUPtc5lM=;
h=Reply-To:Subject:References:To:From:Date:In-Reply-To;
b=eYN8g9DePqlPrdHtAiaqgn9gyqQtM1NDxldYWyPfdWYCVVFZYJDM7K4dcqsGvgUBa
DqklLZFZPZkt8l4W8etl4V0TtgyPPUKZLmwCgEzLRlgc4p70Xcdsp5CNh7vbjqBLyX
XRHNrQRjBgTCAKqh9AXNxwZC5Jzt8H5w/FffZch4=
Reply-To: s7r@sky-ip.org
References: <55AFBBE6.3060702@electrum.org>
To: Thomas Voegtlin <thomasv@electrum.org>,
bitcoin-dev@lists.linuxfoundation.org
From: s7r <s7r@sky-ip.org>
X-Enigmail-Draft-Status: N1010
Message-ID: <55B21DA7.2020706@sky-ip.org>
Date: Fri, 24 Jul 2015 14:12:39 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55AFBBE6.3060702@electrum.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=I/SYP4Ug c=1 sm=1 tr=0
a=dFCltrIYHCDM1x7031pMDg==:117 a=dFCltrIYHCDM1x7031pMDg==:17
a=ZDnEzkWgAAAA:8 a=-NIMs_s3AAAA:8 a=bvjBBkZ6AAAA:8 a=JAI3OqB5mnwA:10
a=N659UExz7-8A:10 a=ag1SF4gXAAAA:8 a=MRO7xvu3lxBIMu5qaUgA:9
a=q3gmBntzxxUII_ge:21 a=OBT9Xan99dpYmU7y:21 a=pILNOxqGKmIA:10
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,URIBL_BLACK autolearn=no 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: Fri, 24 Jul 2015 11:12:54 -0000
Hi,
I think this would be too complicated in practice and you'd have to
defend against many other types of attacks, including but not limited to
Sybil attacks, misbehaving servers not responding to requests,
misbehaving servers not forwarding requests, you'd need some kind of
directory servers or master servers which sign and authenticate the
public server keys, otherwise someone can poison that data and provide
the clients with wrong server keys.
Secondly, you'd not use RSA for this, but rather Ed25519 which is
faster, more cpu efficient and provides better security.
Last but not least, I don't see this as a major issue and I really thin
it is not worth your time. Better work on electrum server defenses,
hardening them against DoS. After all, Electrum is a SPV based Bitcoin
wallet, so it cannot be more anonymous than Bitcoin itself, which we
already know it is pseudonymous, not anonymous and transactions can
/will be linked to addresses. This is just a limitation of Bitcoin as it
is today, and using SPV you assume the risk of trusting the server, it's
just how SPV should work. As a pro, it gives you the ability to sync
immediately and not download the entire blockchain.
Privacy concerned people should run their own Electrum server and make
it accessible via .onion, and connect the bitcoind running on the
electrum server host only to other onion peers (onlynet=tor). We should
highlight that using Electrum with Tor cannot leak more that some
addresses belong to the same wallet, which is not the end of the world.
On 7/22/2015 6:51 PM, 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
>
|
