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