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
|
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 675997A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jul 2015 02:26:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com
[209.85.220.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 151DBE8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jul 2015 02:26:17 +0000 (UTC)
Received: by pabkd10 with SMTP id kd10so5933147pab.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 19:26:16 -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
:cc:subject:references:in-reply-to:content-type;
bh=kZUFEvNVhvydbGiJIrvZpUTbaSW1E3o6vMfRysldhXY=;
b=dBvjUIncS0jSlP4iBjn/3Xw4kIKcyxGyWZd3Ve0oBMrWcTlMGGuzUok3vLYZYLg0/u
CJJzdEvH5SjC3Pn/qMzJBfKVrwJichBOXQ5qwNpLHbxb4dpou+mFqj7p2HE4ftogoWai
/diy8mR6B5f+gCqaMDichx7H7yAbC66DJDnqW3yuqpVk5eUFjiuYhgoK4EtGH7axB02h
wEnZHNJf5RHCNoBk2rQrAHtiu9ejbHhV6xa9CezDpsRcQOmvPGJSFLXpv81kzmwayvhI
cv07V4qYuE6eitlKPk5qdwJpOoNvDOQVfED4o6mZH3RzYokm/kc9smeMbcrxx69qI+nA
YcNg==
X-Gm-Message-State: ALoCoQltovzUjPu0hRxPsRvpnvbtoy95DehCA3EDR3qpUuGj39wDO2hpjGv0rudHrZsMG6ffrl0d
X-Received: by 10.70.140.173 with SMTP id rh13mr25851695pdb.24.1437704776617;
Thu, 23 Jul 2015 19:26:16 -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
y1sm11325231pdy.2.2015.07.23.19.26.15
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 23 Jul 2015 19:26:15 -0700 (PDT)
Message-ID: <55B1A254.6070806@voskuil.org>
Date: Thu, 23 Jul 2015 19:26:28 -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: Stefan Richter <richter@cs.rwth-aachen.de>, gb <kiwigb@yahoo.com>,
Thomas Voegtlin <thomasv@electrum.org>
References: <55AFBBE6.3060702@electrum.org> <1437606706.2688.0.camel@yahoo.com>
<114b2a76-ebc7-461a-b4bc-10873574d6c4@HUB2.rwth-ad.de>
<CAH+=Z+Xt4mja348Rg5Ot0u1VeCnVxm0wkVUA3GVgryZ4Yp4QNw@mail.gmail.com>
In-Reply-To: <CAH+=Z+Xt4mja348Rg5Ot0u1VeCnVxm0wkVUA3GVgryZ4Yp4QNw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="OkmUrvXDCLi6n4xBw3E9VrWIcXFRHViOT"
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
Cc: bitcoin-dev@lists.linuxfoundation.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 02:26:18 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--OkmUrvXDCLi6n4xBw3E9VrWIcXFRHViOT
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
I've looked at IT-PIR for Libbitcoin. It's certainly more elegant than
onion routing for query privacy, but doesn't improve on the collusion
problem. As a result the related directory problem would also remain.
"This protocol sacrifices some level of privacy to gain robustness.
Because of this we need to assume that there is no collusion between
some number of servers. In some settings, it is unclear how this
requirement can be enforced or detected. This uncertainty may make this
protocol less desirable than others with different privacy guarantees."
http://www.cypherpunks.ca/~iang/pubs/hybridpir-pets.pdf
=46rom the same source, regarding aforementioned options:
"An assumption used in many PETs, including mix networks, secret
sharing, onion routing and some voting protocols, is that no more than
some threshold of agents are colluding against the user to discover the
private information."
Another option is computationally-bounded CPIR, but from the same source:=
"The main problem with the CPIR protocols already discussed is that
they do not generally perform queries faster than the trivial protocol."
Where the "trivial protocol" in our problem is full blockchain download.
WRT an alternative CPIR proposed in 2007:
"The idea behind their protocol is to add noise to the query in a way
that the server cannot discover which record the client is interested
in, but with the secret information that the client has, she can remove
the noise from the server=E2=80=99s response."
This is the idea behind stealth prefix queries:
https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-fetch-stealth
=46rom our perspective, another important objective of query privacy is
allowing the caller make the trade-off between the relative levels of
privacy and performance - from absolute to non-existent. In some cases
privacy is neither required nor desired.
Prefix filtering accomplishes the client-tuning objective. It also does
not suffer server collusion attacks nor is it dependent on computational
bounds. The primary trade-off becomes result set (download) size against
privacy.
e
On 07/23/2015 05:23 AM, Stefan Richter wrote:
> This looks like a prime application for this PIR
> library: http://percy.sourceforge.net/apidocs/index.html
>=20
> Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> schrieb am Do., 23. Jul=
i
> 2015 um 02:07 Uhr:
>=20
> This is a good point. I didn't delve into the specifics of
> implementation due to the larger issues that I raised. Libbitcoin S=
erver
> uses CurveZMQ, an implementation of CurveCP.
>=20
> http://curvecp.org
> http://curvezmq.org
> https://en.bitcoin.it/wiki/Libbitcoin_Server
>=20
> e
>=20
> On 07/22/2015 04:11 PM, gb via bitcoin-dev wrote:
> > Why RSA?
> >
> >>
> >> 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 pub=
keys
> >> * 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 encr=
ypted
> >> requests to M
> >> * M dispatches the client's requests to the corresponding server=
s 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 clien=
t.
> >> * The client decrypts the encrypted response with k_addr_i
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
--OkmUrvXDCLi6n4xBw3E9VrWIcXFRHViOT
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
iQEcBAEBAgAGBQJVsaJUAAoJEDzYwH8LXOFOOpgH/jUhkByUd9sDL6f3BTdU4Q1t
HQyQ6NZD+yOrXhFI0nUAmPwBChqKszBHgktcKBH0m26YGLRcb2IQq6DS1swELX8Q
6dXTrQjkRdswUvTeqMSwk+Hx+Tria9CO5CBV89hblhHLAlj04JwgU4IqomeBFPXa
c6+k+WyyBpkm4RueXUpr+qNojgp0uiYA5mXqbN97JfEeSiujm1x7o04R3IOSRb56
jxMb+bF2vCkRE3j6yn0BAqwGnDZq2C+Q0VdtfZgRnSlhK1NaVH0UEgfEbuhKEfn/
24s5i4iVAzCXANMGwkX6lh5WnxM1rsL6uzEnNwFMt8s6uizTMq5ltzOn3LeW0g0=
=c8VF
-----END PGP SIGNATURE-----
--OkmUrvXDCLi6n4xBw3E9VrWIcXFRHViOT--
|
