[bitcoin-dev] Making Electrum more anonymous

[bitcoin-dev] Making Electrum more anonymous

[Thomas Voegtlin]

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

Re: [bitcoin-dev] Making Electrum more anonymous

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

- Sent from my tablet
Den 22 jul 2015 17:51 skrev "Thomas Voegtlin via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> 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.

Why not look at something like Dissent? http://dedis.cs.yale.edu/dissent/

This protocol reduces the impact of Sybil attacks.

[-- Attachment #2: Type: text/html, Size: 1396 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[Joseph Gleason ⑈]

[-- Attachment #1: Type: text/plain, Size: 3375 bytes --]

I've thought about this as well, (in addition to making a java
implementation of the electrum server).

One solution would be for the client to combine all the addresses they are
interested in into a single bloom filter and send that to the server.

It would be pretty expensive for the server to check every address against
the bloom filter, but maybe for recent blocks (client can send how behind
they are) and for new transactions it wouldn't be bad at all.

The client could end up receiving a bunch of transactions they weren't
interested in but it would likely be manageable.

The client would also need to be fairly clever, including a set of static
ruse addresses and dynamic ruse addresses that they include in the filter.
That way a server would have a hard time using the bloom filter as a
fingerprint and figuring out which addresses are the real ones.

An alternative would be the server sending a bloom filter of addresses in
each block and then the client requesting entire blocks.  This would use
more bandwidth, but it seems like it would be pretty simple to implement
and give good anonymity.

Basically the idea is to spend more bandwidth and CPU to keep the server in
the dark on what the client really wants.

On Wed, Jul 22, 2015 at 8:51 AM Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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
>

[-- Attachment #2: Type: text/html, Size: 4138 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

>
> One solution would be for the client to combine all the addresses they are
> interested in into a single bloom filter and send that to the server.
>

<snip extra ideas>

Hey Joseph,

All those ideas are ones we had years ago and they are implemented in the
current Bitcoin protocol.

The trick, as you may know, is this bit:

The client would also need to be fairly clever
>

It turns out making a sufficiently clever client to fool even advanced
observers is a lot of programming work, assuming you wish for the Ultimate
Solution which lets you allocate a desired quantity of bandwidth and then
use it to maximize privacy.

[-- Attachment #2: Type: text/html, Size: 1137 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 3530 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[Joseph Gleason ⑈]

[-- Attachment #1: Type: text/plain, Size: 4501 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5756 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[gb]

Why RSA?

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

Re: [bitcoin-dev] Making Electrum more anonymous

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

This is a good point. I didn't delve into the specifics of
implementation due to the larger issues that I raised. Libbitcoin Server
uses CurveZMQ, an implementation of CurveCP.

http://curvecp.org
http://curvezmq.org
https://en.bitcoin.it/wiki/Libbitcoin_Server

e

On 07/22/2015 04:11 PM, gb via bitcoin-dev wrote:
> Why RSA?
> 
>>
>> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[Stefan Richter]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

This looks like a prime application for this PIR library:
http://percy.sourceforge.net/apidocs/index.html

Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
schrieb am Do., 23. Juli 2015 um 02:07 Uhr:

> This is a good point. I didn't delve into the specifics of
> implementation due to the larger issues that I raised. Libbitcoin Server
> uses CurveZMQ, an implementation of CurveCP.
>
> http://curvecp.org
> http://curvezmq.org
> https://en.bitcoin.it/wiki/Libbitcoin_Server
>
> e
>
> On 07/22/2015 04:11 PM, gb via bitcoin-dev wrote:
> > Why RSA?
> >
> >>
> >> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2770 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 4319 bytes --]

I've looked at IT-PIR for Libbitcoin. It's certainly more elegant than
onion routing for query privacy, but doesn't improve on the collusion
problem. As a result the related directory problem would also remain.

"This protocol sacrifices some level of privacy to gain robustness.
Because of this  we need to assume that there is no collusion between
some number of servers. In some  settings, it is unclear how this
requirement can be enforced or detected. This uncertainty  may make this
protocol less desirable than others with different privacy guarantees."

http://www.cypherpunks.ca/~iang/pubs/hybridpir-pets.pdf

From the same source, regarding aforementioned options:

"An assumption used in many PETs, including mix networks, secret
sharing, onion routing and some voting protocols, is that no more than
some threshold of agents are colluding against the user to discover the
private information."

Another option is computationally-bounded CPIR, but from the same source:

"The main problem with the CPIR protocols already  discussed is that
they do not generally perform queries faster than the trivial protocol."

Where the "trivial protocol" in our problem is full blockchain download.

WRT an alternative CPIR proposed in 2007:

"The idea behind their protocol is to add noise to the query in a way
that the server  cannot discover which record the client is interested
in, but with the secret information  that the client has, she can remove
the noise from the server’s response."

This is the idea behind stealth prefix queries:

https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-fetch-stealth

From our perspective, another important objective of query privacy is
allowing the caller make the trade-off between the relative levels of
privacy and performance - from absolute to non-existent. In some cases
privacy is neither required nor desired.

Prefix filtering accomplishes the client-tuning objective. It also does
not suffer server collusion attacks nor is it dependent on computational
bounds. The primary trade-off becomes result set (download) size against
privacy.

e

On 07/23/2015 05:23 AM, Stefan Richter wrote:
> This looks like a prime application for this PIR
> library: http://percy.sourceforge.net/apidocs/index.html
> 
> Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> schrieb am Do., 23. Juli
> 2015 um 02:07 Uhr:
> 
>     This is a good point. I didn't delve into the specifics of
>     implementation due to the larger issues that I raised. Libbitcoin Server
>     uses CurveZMQ, an implementation of CurveCP.
> 
>     http://curvecp.org
>     http://curvezmq.org
>     https://en.bitcoin.it/wiki/Libbitcoin_Server
> 
>     e
> 
>     On 07/22/2015 04:11 PM, gb via bitcoin-dev wrote:
>     > Why RSA?
>     >
>     >>
>     >> 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
> 
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[Slurms MacKenzie]

Keep in mind this is the similar premise as claimed to be offered by BIP37 bloom filters, but faulty assumptions and implementation failure in BitcoinJ have meant that bloom filters uniquely identify the wallet and offer no privacy for the user no matter what the settings are. If you imagine a system where there is somehow complete separation and anonymization between all requests and subscriptions, the timing still leaks the association between the addresses to the listeners. The obvious solution to that is to use a very high latency mix network, but I somehow doubt that there's any desire for a wallet with SPV security that takes a week to return results. 


> Sent: Friday, July 24, 2015 at 4:26 AM
> From: "Eric Voskuil via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
> To: "Stefan Richter" <richter@cs.rwth-aachen.de>, gb <kiwigb@yahoo.com>, "Thomas Voegtlin" <thomasv@electrum.org>
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Making Electrum more anonymous
>
> 
> From our perspective, another important objective of query privacy is
> allowing the caller make the trade-off between the relative levels of
> privacy and performance - from absolute to non-existent. In some cases
> privacy is neither required nor desired.
> 
> Prefix filtering accomplishes the client-tuning objective. It also does
> not suffer server collusion attacks nor is it dependent on computational
> bounds. The primary trade-off becomes result set (download) size against
> privacy.
> 

Re: [bitcoin-dev] Making Electrum more anonymous

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

On 07/23/2015 08:42 PM, Slurms MacKenzie via bitcoin-dev wrote:
>> From: "Eric Voskuil via bitcoin-dev"
>>
>> From our perspective, another important objective of query privacy is
>> allowing the caller make the trade-off between the relative levels of
>> privacy and performance - from absolute to non-existent. In some
>> cases privacy is neither required nor desired.
>>
>> Prefix filtering accomplishes the client-tuning objective. It also
>> does not suffer server collusion attacks nor is it dependent on
>> computational bounds. The primary trade-off becomes result set
>> (download) size against privacy.
>
> Keep in mind this is the similar premise as claimed to be offered by
> BIP37 bloom filters, but faulty assumptions and implementation
> failure in BitcoinJ have meant that bloom filters uniquely identify
> the wallet and offer no privacy for the user no matter what the
> settings are.

Yes, quite true. And without the ability to search using filters there
is no private restore from backup short of downloading the full chain,
rendering the idea rather pointless.

This is why privacy remains a significant issue. Privacy is an essential
aspect of fungibility. This is a central problem for Bitcoin. The
correlation of addresses within transactions is of course problematic.
Possibly zero knowledge proof will at some point come to the rescue. But
the correlation of addresses via search works against the benefits of
address non-reuse, and the correlation of addresses to IP addresses
works against the use of private addresses.

Solving the latter two problems can go a long way to reducing the impact
of the former. But currently the only solution is to run a full chain
wallet. This is not a viable solution for many scenarios, and getting
less so.

This is not a problem that can be ignored, nor is it unique to Electrum.
The Bloom filter approach was problematic, but that doesn't preclude the
existence of valid solutions.

> If you imagine a system where there is somehow complete
> separation and anonymization between all requests and subscriptions,
> the timing still leaks the association between the addresses to the
> listeners.

Well because of presumed relationship in time these are not actually
separated requests. Which is why even the (performance-unrealistic)
option of a distinct Tor route for each independent address request is
*still* problematic.

> The obvious solution to that is to use a very high latency
> mix network, but I somehow doubt that there's any desire for a wallet
> with SPV security that takes a week to return results.

Introducing truly-random timing variations into the mixnet solutions can
mitigate timing attacks, but yes, this just makes the already
intolerable performance problem much worse.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Making Electrum more anonymous

[Slurms MacKenzie]

> Sent: Friday, July 24, 2015 at 6:44 AM
> From: "Eric Voskuil" <eric@voskuil.org>
> To: "Slurms MacKenzie" <slurms@gmx.us>, bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Making Electrum more anonymous
> 
> This is why privacy remains a significant issue. Privacy is an essential
> aspect of fungibility. This is a central problem for Bitcoin. 

Somewhat under discussed too, really. Peoples money doesn't fly out the window when their privacy is ripped out from under them, as such discussing it seems a little meaningless. As some of the most popular wallets don't even use change addresses, for the comfort of the developers and at the cost of the user. 


> Solving the latter two problems can go a long way to reducing the impact
> of the former. But currently the only solution is to run a full chain
> wallet. This is not a viable solution for many scenarios, and getting
> less so.

Which makes the general clambering for demise of the full node wallet all the more baffling.


> Well because of presumed relationship in time these are not actually
> separated requests. Which is why even the (performance-unrealistic)
> option of a distinct Tor route for each independent address request is
> *still* problematic.

Yep, any leak is a useful leak. Even if you only expose one single address request to me, I now have an idea of what timezone you are in and can eliminate it from other implausible ones. Onion routing is not a solution in my mind, you're just asking for people to sybil attack Electrum clients to capture as much timing data as possible. There's no defending against that.


> Introducing truly-random timing variations into the mixnet solutions can
> mitigate timing attacks, but yes, this just makes the already
> intolerable performance problem much worse.

Realistically this is all too broken to be building wallets on top of. 

SPV clients are neither secure nor private, we should feel guilty for ever promoting them. 

Re: [bitcoin-dev] Making Electrum more anonymous

[s7r]

Hi,

I think this would be too complicated in practice and you'd have to
defend against many other types of attacks, including but not limited to
Sybil attacks, misbehaving servers not responding to requests,
misbehaving servers not forwarding requests, you'd need some kind of
directory servers or master servers which sign and authenticate the
public server keys, otherwise someone can poison that data and provide
the clients with wrong server keys.

Secondly, you'd not use RSA for this, but rather Ed25519 which is
faster, more cpu efficient and provides better security.

Last but not least, I don't see this as a major issue and I really thin
it is not worth your time. Better work on electrum server defenses,
hardening them against DoS. After all, Electrum is a SPV based Bitcoin
wallet, so it cannot be more anonymous than Bitcoin itself, which we
already know it is pseudonymous, not anonymous and transactions can
/will be linked to addresses. This is just a limitation of Bitcoin as it
is today, and using SPV you assume the risk of trusting the server, it's
just how SPV should work. As a pro, it gives you the ability to sync
immediately and not download the entire blockchain.

Privacy concerned people should run their own Electrum server and make
it accessible via .onion, and connect the bitcoind running on the
electrum server host only to other onion peers (onlynet=tor). We should
highlight that using Electrum with Tor cannot leak more that some
addresses belong to the same wallet, which is not the end of the world.

On 7/22/2015 6:51 PM, 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
> 

Re: [bitcoin-dev] Making Electrum more anonymous

[Slurms MacKenzie]

> Sent: Friday, July 24, 2015 at 2:12 PM
> From: "s7r via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Making Electrum more anonymous
>
> Privacy concerned people should run their own Electrum server and make
> it accessible via .onion, and connect the bitcoind running on the
> electrum server host only to other onion peers (onlynet=tor). We should
> highlight that using Electrum with Tor cannot leak more that some
> addresses belong to the same wallet, which is not the end of the world.
> 

It leaks your timezone too. As pointed out in another thread running a electrum-server instance is no easy task and can't really be suggested to another as a sensible thing to run for themselves. Enthusiasts maybe, but they'll just want to run Bitcoin core and skip the behemoth middleman.