Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DBFA7411 for ; Wed, 22 Jul 2015 23:07:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9484112A for ; Wed, 22 Jul 2015 23:07:23 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so124029369wib.1 for ; Wed, 22 Jul 2015 16:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=SzdsDtH0vI2Wm6RowJf4msj9GtVYHsbHKAWXPGifRig=; b=ZoiLHB77hC30dS+nT9EmnJFYvglfl/nv2jU3QdRmSQJoORAZWZ2C/yCR9J8GsBTkI4 kIaWHWsMA3zkV916RfAABbvV7uk1vqJQhmilCN9R2qLLUYVUhOnGY1+zGqIhKz9+KbkZ YV9CjII2ZruZ/OMQ+rbeuu5yeKM8AvVw5vgEdcA3fLiTARt6o7mJbYILL7G7hBj2Ush+ lTNkNtshSXnsN516vUw0L8wXJZ+8+NVAKYqyBO+g2Y/UzxfwpH/nqg6AMrgGQGDuN2yn CO35Dy5jfTplvEQwlBLLaFr1X9DoX4v3GKRFGuorHrq00R8Pc35FMEnqhIQ+Xa6RLQQ+ oO2A== X-Received: by 10.194.87.102 with SMTP id w6mr9160448wjz.111.1437606442205; Wed, 22 Jul 2015 16:07:22 -0700 (PDT) MIME-Version: 1.0 References: <55AFBBE6.3060702@electrum.org> <55AFC52C.3010700@voskuil.org> <55B01731.6070306@voskuil.org> In-Reply-To: <55B01731.6070306@voskuil.org> From: =?UTF-8?B?Sm9zZXBoIEdsZWFzb24g4pGI?= Date: Wed, 22 Jul 2015 23:07:12 +0000 Message-ID: To: Eric Voskuil , Thomas Voegtlin , bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=047d7bf19850508a07051b7ed57b X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 23:07:25 -0000 --047d7bf19850508a07051b7ed57b Content-Type: text/plain; charset=UTF-8 I would recommend the following solution as a decent compromise between complexity and privacy: 1) Encourage electrum server operators to have their servers reachable as tor hidden services (.onion addresses) 2) Make sure server discovery works well with .onion addresses 3) Make the privacy a user configurable setting: - None - Allows any server connection type - SSL - Requires SSL at least, no plain text - Tor - Requires tor, no direct TCP - Multi-Tor - Uses a variety of tor paths to reach a variety of servers (maybe configurable number of servers) Default should be 'SSL' probably. On Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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, > > > > 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, > >> > >> 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 > --047d7bf19850508a07051b7ed57b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would recommend the following solution as a decent compr= omise between complexity and privacy:

1) Encourage elect= rum server operators to have their servers reachable as tor hidden services= (.onion addresses)
2) Make sure server discovery works well with= .onion addresses
3) Make the privacy a user configurable setting= :
=C2=A0 - None - Allows any server connection type
=C2= =A0 - SSL - Requires SSL at least, no plain text
=C2=A0 - Tor - R= equires tor, no direct TCP
=C2=A0 - Multi-Tor - Uses a variety of= tor paths to reach a variety of servers (maybe configurable number of serv= ers)

Default should be 'SSL' probably.








On Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev <= ;bitcoin-dev@lists= .linuxfoundation.org> wrote:
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 als= o
don't trust it with your money. So any robust privacy optimization woul= d
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,
>
> The scheme is essentially onion routing. The set of {M} are entry node= s
> 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,
>>
>> Although Electrum clients connect to several servers in order to f= etch
>> 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 t= rue
>> 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 cre= ate
>> subsets of wallet addresses, and to send them to separate servers.= In my
>> opinion, this does not really improve anonymity, because it requir= es
>> trusting more servers.
>>
>> Here is an idea, inspired by TOR, on which I would like to have so= me
>> feedback: We create an anonymous routing layer between Electrum se= rvers
>> and clients.
>>
>> * Each server S publishes a RSA public key, KS
>> * Each client receives a list of available servers and their pubke= ys
>> * 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 co= ntains
>> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i<= br> >> * The client chooses a main server M, and sends the list of encryp= ted
>> requests to M
>> * M dispatches the client's requests to the corresponding serv= ers S_i
>> (without the client's IP address.)
>> * Each server decrypts the requests it receives, performs the requ= est,
>> 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 appr= oach?
>>
>> (Note: this will not work if all servers, or a large fraction of t= hem,
>> are controlled by the same entity that controls M)
>>
>>
>> Thomas
>> _______________________________________________
>

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--047d7bf19850508a07051b7ed57b--