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?= <fireduck@gmail.com>
Date: Wed, 22 Jul 2015 23:07:12 +0000
Message-ID: <CA+ASnrFxPtxE2vsDS4dz2FxddAtW5fQK=gkBbrPVp878zeV_Hw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>, Thomas Voegtlin <thomasv@electrum.org>, 
	bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=047d7bf19850508a07051b7ed57b
Subject: Re: [bitcoin-dev] Making Electrum more anonymous
Precedence: list

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

<div dir=3D"ltr">I would recommend the following solution as a decent compr=
omise between complexity and privacy:<div><br></div><div>1) Encourage elect=
rum server operators to have their servers reachable as tor hidden services=
 (.onion addresses)</div><div>2) Make sure server discovery works well with=
 .onion addresses</div><div>3) Make the privacy a user configurable setting=
:</div><div>=C2=A0 - None - Allows any server connection type</div><div>=C2=
=A0 - SSL - Requires SSL at least, no plain text</div><div>=C2=A0 - Tor - R=
equires tor, no direct TCP</div><div>=C2=A0 - Multi-Tor - Uses a variety of=
 tor paths to reach a variety of servers (maybe configurable number of serv=
ers)</div><div><br></div><div>Default should be &#39;SSL&#39; probably.</di=
v><div><br></div><div><br></div><div><br></div><div><br></div><div><br></di=
v><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>I should add that the obvious resolution to this set of problems is to<br>
use a distinct Tor route for each Bitcoin address, not to reinvent Tor<br>
and reproduce its community. So ultimately this is easy to implement,<br>
but the downside is performance.<br>
<br>
But it&#39;s important to keep in mind that poor-performing perfect privacy=
<br>
for address monitoring is trivial to achieve - just sync the full<br>
blockchain.<br>
<br>
Presumably if you don&#39;t trust a server to protect your privacy, you als=
o<br>
don&#39;t trust it with your money. So any robust privacy optimization woul=
d<br>
at least be designed to support partial (SPV) chain clients. It would<br>
also need to support wallet restoration from backup.<br>
<br>
The level of privacy will always be a performance trade-off. The ideal<br>
solution would allow a client to balance privacy against performance.<br>
<br>
e<br>
<br>
On 07/22/2015 09:30 AM, Eric Voskuil wrote:<br>
&gt; Hi Thomas,<br>
&gt;<br>
&gt; The scheme is essentially onion routing. The set of {M} are entry node=
s<br>
&gt; and the set of {S} are exit nodes. The weaknesses are as you would see=
<br>
&gt; in an analogous TOR implementation:<br>
&gt;<br>
&gt; (1) The lack of relay nodes {R} make collaboration between any subset =
of<br>
&gt; {M} and {S} trivial.<br>
&gt;<br>
&gt; (2) OR is a mixnet, so the size of the network matters a lot.<br>
&gt;<br>
&gt; (3) The directory is a perpetual weakness.<br>
&gt;<br>
&gt; (4) Content is visible to the exit node (or the final service). This<b=
r>
&gt; means each address must be passed via a distinct route to prevent<br>
&gt; correlation.<br>
&gt;<br>
&gt; e<br>
&gt;<br>
&gt; On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:<br>
&gt;&gt; Hello,<br>
&gt;&gt;<br>
&gt;&gt; Although Electrum clients connect to several servers in order to f=
etch<br>
&gt;&gt; block headers, they typically request address balances and address=
<br>
&gt;&gt; histories from a single server. This means that the chosen server =
knows<br>
&gt;&gt; that a given set of addresses belong to the same wallet. That is t=
rue<br>
&gt;&gt; even if Electrum is used over TOR.<br>
&gt;&gt;<br>
&gt;&gt; There have been various proposals to improve on that, but none of =
them<br>
&gt;&gt; really convinced me so far. One recurrent proposal has been to cre=
ate<br>
&gt;&gt; subsets of wallet addresses, and to send them to separate servers.=
 In my<br>
&gt;&gt; opinion, this does not really improve anonymity, because it requir=
es<br>
&gt;&gt; trusting more servers.<br>
&gt;&gt;<br>
&gt;&gt; Here is an idea, inspired by TOR, on which I would like to have so=
me<br>
&gt;&gt; feedback: We create an anonymous routing layer between Electrum se=
rvers<br>
&gt;&gt; and clients.<br>
&gt;&gt;<br>
&gt;&gt; * Each server S publishes a RSA public key, KS<br>
&gt;&gt; * Each client receives a list of available servers and their pubke=
ys<br>
&gt;&gt; * For each wallet address, addr_i, a client chooses a server S_i, =
and a<br>
&gt;&gt; RSA keypair (K_addr_i, k_addr_i)<br>
&gt;&gt; * The client creates a list of encrypted requests. Each request co=
ntains<br>
&gt;&gt; addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i<=
br>
&gt;&gt; * The client chooses a main server M, and sends the list of encryp=
ted<br>
&gt;&gt; requests to M<br>
&gt;&gt; * M dispatches the client&#39;s requests to the corresponding serv=
ers S_i<br>
&gt;&gt; (without the client&#39;s IP address.)<br>
&gt;&gt; * Each server decrypts the requests it receives, performs the requ=
est,<br>
&gt;&gt; and encrypts the result with K_addr_i<br>
&gt;&gt; * M receives encrypted responses, and forwards them to the client.=
<br>
&gt;&gt; * The client decrypts the encrypted response with k_addr_i<br>
&gt;&gt;<br>
&gt;&gt; What do you think? What are the costs and benefits of such an appr=
oach?<br>
&gt;&gt;<br>
&gt;&gt; (Note: this will not work if all servers, or a large fraction of t=
hem,<br>
&gt;&gt; are controlled by the same entity that controls M)<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Thomas<br>
&gt;&gt; _______________________________________________<br>
&gt;<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--047d7bf19850508a07051b7ed57b--