Re: [bitcoin-dev] Making Electrum more anonymous
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making Electrum more anonymous
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 signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making Electrum more anonymous
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
___
signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making Electrum more anonymous
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making Electrum more anonymous
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
