Message-ID: <55B01731.6070306@voskuil.org>
Date: Wed, 22 Jul 2015 15:20:33 -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> <55AFC52C.3010700@voskuil.org>
In-Reply-To: <55AFC52C.3010700@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="Dx2wbHuTt4aCnMtbqGxIG0E8qG6MvEwBw"
Subject: Re: [bitcoin-dev] Making Electrum more anonymous
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Dx2wbHuTt4aCnMtbqGxIG0E8qG6MvEwBw
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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,
>=20
> 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:
>=20
> (1) The lack of relay nodes {R} make collaboration between any subset o=
f
> {M} and {S} trivial.
>=20
> (2) OR is a mixnet, so the size of the network matters a lot.
>=20
> (3) The directory is a perpetual weakness.
>=20
> (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.
>=20
> e
>=20
> 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 know=
s
>> 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 server=
s
>> 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 contai=
ns
>> 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
>> _______________________________________________
>=20


--Dx2wbHuTt4aCnMtbqGxIG0E8qG6MvEwBw
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

iQEcBAEBAgAGBQJVsBcxAAoJEDzYwH8LXOFOkf8H/380Gdwosy23lo79N56frILF
qZ7YtDAgtl6Qtg7uXQig+qdbUvQq96bvLhi3U3zFhtojvPtmUl7SZzLzIG+EbrEc
zBG/LOjmeDaNQva4Iv3+Qdzc/iuyzhGj0AiQp/t61LW96XRWazuARGDa+YFTSc00
XS41iz5kDS4ctCf2AVKB87zaUmVcnhL2y8JC+dZma8Qpzn2H7bj7E9kNw3V0a/kE
YiRCj7k7fOQEVG5wgLJFTVvrWeqYbdFtCOuUz7KKew0gmVLxoqvRKSIUaGfT1h13
qwi6ejfAzAe33I+UMggwQWwfPuK3SxROl+vShaiT3ehi7h2Jx5ghV0mn5yYbHcE=
=Jlp6
-----END PGP SIGNATURE-----

--Dx2wbHuTt4aCnMtbqGxIG0E8qG6MvEwBw--