From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2EBE549F for ; 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 ; Wed, 22 Jul 2015 16:30:26 +0000 (UTC) Received: by pdjr16 with SMTP id r16so143608478pdj.3 for ; 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 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--