Making Electrum more anonymous
16 messages, 22 to 24 Jul 2015. Started by Thomas Voegtlin.
Eric Voskuil (5), Slurms MacKenzie (3), Joseph Gleason ⑈ (2), Thomas Voegtlin, Natanael, Mike Hearn, gb, Stefan Richter, +1 more
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
- Sent from my tablet Den 22 jul 2015 17:51 skrev "Thomas Voegtlin via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org>:
Quoted text (18 lines)
> > 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.
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:
Quoted text (41 lines)
> 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 > _______________________________________________
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:
Quoted text (45 lines)
> 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 >
Quoted text (4 lines)
> > 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
Quoted text (1 line)
>
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.
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:
Quoted text (62 lines)
> 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
>> _______________________________________________
>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:
Quoted text (88 lines)
> 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
>Why RSA?
Quoted text (20 lines)
> > 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 >
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:
Quoted text (21 lines)
> 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
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:
Quoted text (38 lines)
> 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 >
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:
Quoted text (50 lines)
> 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 >
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.
Quoted text (17 lines)
> 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. >
On 07/23/2015 08:42 PM, Slurms MacKenzie via bitcoin-dev wrote:
Quoted text (17 lines)
>> 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.
Quoted text (4 lines)
> 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.
Quoted text (3 lines)
> 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
Quoted text (7 lines)
> 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.
Quoted text (4 lines)
> 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.
Quoted text (4 lines)
> 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.
Quoted text (3 lines)
> 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.
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:
Quoted text (45 lines)
> 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 >
Quoted text (11 lines)
> 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.