Status of Network-level Privacy Efforts in Zcash

Technology
44

@ckomlo and @gtank are there any public write-ups of the threat model that you’re working from?

It seems like the main things we want to prevent are linking otherwise unlinked transactions and being able to know the IP address(es) associated with a transaction, since IP reveals a pile of other information about the user, like location.

Also, @harryhalpin, I think in both cases some protection for transparent transactions is desirable. Like, just because transaction details are known to the world doesn’t mean a user wants their IP address attached to it. It’s pretty much the same as with private transactions, since in that case the user could be transacting with an attacker, who would then know the transaction (despite it being a private transaction) and could figure out the IP from that.

2 Likes
46

I am pretty sure this thread is not supposed to be Nym vs Kazenpost and whatever differences the developers on such projects have with each other.

I will be removing personal attacks and inflammatory remarks from both David and Harrys posts to try to keep the peace.

@harryhalpin seems to have moved on and @david415 needs to do the same. From this point forward please keep on the topic of mixnet solutions for Zcash and leave personal grievances at the door or I will have to begin suspending accounts.

3 Likes
47

@daira @str4d @nathan-at-least could you help more clearly define what the core Zcash team is looking for in a network level privacy solution?

1 Like
48

From this point forward please keep on the topic of mixnet solutions for Zcash and leave personal grievances at the door or I will have to begin suspending accounts.

Thanks @Shawn! Believe it or not, most people can act like adults on the internet. There should be no problem respecting consent about which projects people are actually currently contributing to and plan to contribute to in the future.

Now, here’s some options:

If we only want to obfuscate the IP address, then Tor is fine as long as there is independence of transactions per circuit, i.e. each transaction creates a new oes that Tor circuit. I’m not sure of any wallet that does that (not thinking of just ZCash wallets, but also Bitcoin wallets like GreenAddress).

That being said, it does appear if that is only the goal, then Dandelion might even be preferable to Tor. In fact, it may work better as it would not require the creation of an entire new circuit or have any dependencies on Tor’s currently centralized directory authority system (which, unlike Chelsea, we view as a bug rather than a feature of Tor).

What else besides the IP address should be obfuscated? If there were concerns over other side-channels and more powerful adversaries, then there are concrete documented attacks on ZCash anonymity that take advantage of network-level side-channels. In this world, you may want a mixnet. For example, how seriously does the ZCash community take the likelihood of realistically implementing new kinds of sidechannel attacks like PING/REJECT attacks, which have a network-level sidechannel component?

Now, these are both fixed by, for example, deferring the processing of the transaction. Nonetheless, there may be other similar attacks.

Also, I’d my understanding is that even Chainalysis has trouble with Monero (!!), and al though there were signs they were preparing to do some network-level surveillance years ago, I’d love to see more info if anyone knows what happened to this effort to create false nodes to monitor network-level traffic

So if we can’t get consensus on answers to my above questions on a whiteboard, looking at concrete attacks might be one way to determine what adversaries are realistic.

49

Not speaking for the whole team, but here’s what I want (for a medium–long term solution).

First, let’s consider what things are non-requirements or out-of-scope:

  • It isn’t required to hide that users are engaging in some form of encrypted communication (encoding messages steganographically is out-of-scope).
  • It isn’t required to hide coarse-grained information about the bandwidth of communication to/from a given user – i.e. we assume that high-bandwidth and low-bandwidth users can be distinguished.
  • It isn’t required to hide when a user is online from adversaries that can directly observe that user’s network connection.
  • We assume that users can download an authentic copy of the software initially. The problem of doing so securely from a potentially censoring regime, while important, is out-of-scope.

Define an “wallet device” to be a device that holds Zcash and may create and receive transactions. Define an “intermediate node” to be any network participant that is not a wallet device.

We are interested in protecting (not necessarily equally) from adversaries with the following capabilities:

  • eavesdrop any network communication;
  • divert or modify network communication;
  • introduce intermediate nodes and wallet devices that they control;
  • send transactions to any public address;
  • publish addresses / send addresses to specific users and solicit for transactions to be sent to them;
  • subvert particular intermediate nodes (i.e. obtain their current state, and control their behaviour from that point onward);
  • subvert particular wallet devices.

Then, the security properties we want are:

  • The strong Ledger Indistinguishability property of shielded Zcash is extended to the network layer. That is, under reasonable conservative assumptions about subversion of nodes, adversaries should not be able to infer information about the activity of any user other than unavoidable inferences.
    • An example of an unavoidable inference would be that if an adversary can observe that a transaction was received at a given time, and that some subset of users were not online during the period when that transaction could have been sent, given the possible range of transmission latencies, then the transaction was not sent by users in the subset.
    • It is highly desirable to have a precise formal model of which inferences are unavoidable.
  • The anonymity and confidentiality of past communications involving a formerly honest intermediate node should be maintained under the same assumptions once that node is subverted.
  • Users should be able to permanently delete particular keys from a given device and then not be vulnerable to future subversion of that device for the authorities that were granted by those keys.
    • This may conflict to some extent with wallet backup usability requirements.
  • The anonymity network is used for all transactions, not only shielded transactions. (It is not desirable to block on greater shielded adoption in order to obtain better network privacy.)
  • Ideally, the anonymity set is shared with other applications / protocols.

Performance, latency, and bandwidth:

  • CPU and bandwidth usage of a wallet device should be reasonable for a typical mobile phone on a consumer data plan.
  • CPU and bandwidth usage of an intermediate node should be reasonable for a typical desktop on a residential broadband connection.
    • I know “typical” isn’t really well-defined and may be lower in some parts of the world.
  • The following latencies are increased by at most a small constant factor:
    • The time from a transaction being sent to it being received. It may be useful to allow the sender to select a non-urgent mode that reduces the information leaked through timing correlation, but that should not be expected to be the default.
    • The time from a transaction being received to it being confirmed, and the received money being spendable in another transaction.
  • The overall bandwidth of cover traffic does not put an unreasonable load on the network.

Engineering and usability requirements:

  • The protocol is well-documented and described in published papers.
  • Only modern conservatively chosen cryptographic algorithms are used.
  • No complex algorithm negotiation (just handshake versioning, which should be downgrade-resistant to the extent possible).
  • The software implementing the anonymity layer should be written entirely (given reasonable assumptions on the TCB) in languages that are memory-safe and have some significant adoption.
  • The anonymity software should not usually require manual configuration by end-users.
  • The anonymity software can be bundled with a Zcash node or wallet implementation and controlled in a not-terrible way from a program written in Rust.
  • Multiple apps that bundle this software (even different versions) should be able to coexist nicely on the same device.

I would also like a pony. More seriously, if some of these requirements can’t be met, then a thorough explanation of why they can’t be met would be a good substitute.

12 Likes
50

Well, this thread seems to have gotten … lively. The forum software is telling me I had a draft post partially written I think in January. Depressingly, it’s still just as relevant now as then.
You all are 1) going in circles 2) ignoring that a major requirement of an effective end-to-end system is supporting privacy for web requests
What I had drafted in late January:
" Again, what threat is it we are protecting against? We established up thread that the side channel attacks on discovering the IP of a recipient wouldn’t be protected by privacy for transaction broadcast.

I agree, if you want to just anonymize the source of a transaction when it’s broadcast, mixnets are the best solution at least in theory. But, we need to articulate what end-to-end security and privacy goals we want. Transaction broadcast privacy is not, in and of itself, an end-to-end goal if z2z only. it seems the main thing we care about is hiding your IP address from the recipient of the transaction. No one else really learns much at least in a z2z only world.

If thats the case, it seems there’s almost no point in only doing that only for transaction broadcast, we also need to have solutions that cover other traffic like communication between a customer and merchant, e.g., over the web. This is hard "

Of course, the world isn’t black and white. Things like Dandelion (as abjectly ineffective as it is) are worth doing because it’s simple, doesn’t require engineering resources or make the network less reliable, and might help the situation. But the type of large scale engineering efforts required for a completely new privacy solution are only justified if you solve it for the use cases zcash has. If your system isn’t generally able to handle web traffic, it does’t do that.

Importantly, even if your system can, in theory, handle web traffic, it needs adoption for that to happen. Zcash won’t be the thing that causes that to happen. So it’s a catch 22. Bottom line, zcash is not going to be the coat tails that drives adoption of your new anonymity tech no matter how good it is (and in the case of Katzenpost, etc I think it’s very good).

1 Like
51

I have two small things to add to this. In the product I’m working on, Zbay, that merchant / seller conversation happens over memos in z2z transactions themselves, so web privacy is not as much of an issue, and potentially not an issue at all.

Also, another way of thinking about other more normal use cases is that we can assume a user uses Tor to address IP address privacy on the web, since that’s what activists, journalists, whistleblowers, and anyone with intense IP privacy needs uses now. In this case we want to give them a way to transact that does not weaken their security posture, at least any more than their use of Tor does.

In this second case, using Tor in a smart way seems like the best solution because we can assume the user is already using Tor, so at least at some level they’ve decided Tor meets their needs and ‘as good as using Tor without zcash’ becomes the bar we need to reach.

3 Likes
52

I agree with that.,
So the thing to do is support transaction submission over Tor. Even a simple " here, please go paste this serialized TX into torToZ.org or the merchants site." But even tooling for that isn’t supported in zcashd. And that’s minimal, it’s just spit out an encoded TX as a text blob to the command line/GUI. Code exists, but integrating it hasn’t happened because other things took priority.

In Zbay, how does the customer find out what products exist or even what merchants? Is there really no web presence.?

53

In Zbay, how does the customer find out what products exist or even what merchants? Is there really no web presence.?

Yep, no web presence required. Sellers post items by sending encrypted memos to “channels” which are Zcash addresses for which the viewing key has been shared.

Channels, in turn, can announce themselves on a kind of “tip line” about what channels are available that is hardcoded into Zbay. They can also register human readable channel names.

54

Based on the current state of things, I think this might be the best way right now: A few trusted entities (ECC, ZF or perhaps EFF, etc) run nodes, and users who need additional privacy can connect to one or more of these nodes over Tor.

I think this provides the best of both worlds for now, no?

  • You have a strong reason to believe these nodes aren’t acting maliciously to undermine your privacy or steal your funds
  • You aren’t connecting to any other nodes.
  • You can trust Tor to hide your IP from these nodes.
  • These nodes endeavor to retain as little data as possible.
  • If the node operator itself wants a guarantee against having users’ IP address data, they can run a .onion hidden service—though this opens up the node and the user to potential known DoS attacks.

In this model, anything that zcashd or Tor might reveal about you to another node is hidden from the rest of the Zcash network in the vast majority of cases. And in cases where the nodes are somehow compromised, Tor provides an additional layer of protection.

@secparam It could be that this is just for transaction submission, but there have been some attacks that work based on how nodes receive transactions too, haven’t there? Even if they’ve been fixed, I think we can safely say that receiving transactions from malicious peers creates some exposure too. So it might be best for users who need privacy to connect through a node they have some reason to trust—even for receiving transactions. Thoughts on this?

We could also send our transactions to a trusted intermediary as printed QR codes via postal mail, but in addition to being ridiculous I think this might be impossible :slight_smile:

If most users are already going to be interacting with a lightwallet server, perhaps operators of lightwallet servers could perform this role of enhancing privacy as well.

4 Likes
55

I’ve been mulling over distributing multiple use-case focused variant zcashd packages, where the idea is for a specific use case, a package should just work out-of-the-box. So for example, replacing the current zcashd package with alternatives like the following:

  • zcashd-indexer (No wallet, no Tor)
  • zcashd-tor-wallet (Tor-only out of the box w/ wallet functionality)
  • zcashd-tor-relayer (Connects to both Tor hidden services and clearnet IPs (not via Tor) and relays blocks/txns)
  • zcashd-tor-lightwalletd (Tor-only plus lightwalletd, no in-process wallet, to support lightwalletd clients)
  • zcashd-monolithic (This is the new name for the existing package where users can configure/tweak things by hand.)

-and so on. From the perspective of zbay, would that make sense?

From a general perspective, would this make sense?

These packages would need to be self-contained and play well in case a user installs multiple packages. So for example, the tor support should use the library mode @gtank mentioned, or else these packages might come as containers that have an internal / preconfigured tor daemon.

Everywhere we see tor in the future we could also have a new variant for a mixnet.

ps: the zcashd-tor-relayer idea is a public service infrastructure component that is intended to protect against malicious banning of tor exit IPs for zcashd nodes by ensuring there are a sufficient number of nodes connecting to clearnet IPs without going over Tor, then relaying txns/blocks to hidden service nodes and vice versa. This does not protect against hidden service black-holing. These attacks are described in Bitcoin over Tor isn’t a Good Idea in section III.D. (banning tor exit IPs) and III.E. hidden service black-holing.

3 Likes
56

I’d say that if Tor is reliable enough to use it all the time having these pre-made packages would be great. If the user wants to enable and disable Tor how would that work?

Right now I’m thinking that the best solution for Zbay is to focus on making Zbay a working light client, and then getting it to connect to a trusted lightwalletd run by ECC or someone else, over Tor. If these packages make that easier that’s great!

2 Likes
57

@holmesworcester I think the idea of people running nodes that can be used for TX submission and are trusted not to log is a good idea. They can be hit via Tor. This can also be a light wallet. Its what I think the simple immediate solution is.

@nathan-at-least. I think the most important thing to do is merge @str4d’s stand alone TX submission code so people can chose how to submit their data.

I like the idea of having different versions of zcash with different privacy assumptions. But doing that with zcashd won’t work. This is a system who’s interface is a command line that requires properly quoted raw json to send a transaction. If you’re doing that, you probably can handle Tor.
That’s a change that needs to be done in something with an end user UX that packages zcashd.

58

@daira somehow I missed this post. Thank you for taking the time to lay all this out. It is really helpful, especially the above formulation. Given that most people here think that Tor is the best near-term option, how achievable is all of this with Tor? If people are connecting to all other nodes via Tor, and using a different Tor circuit every time they send a transaction, are there known attacks on that that go beyond known attacks on Tor and TorBrowser? I suppose then the anonymity set shrinks to “people using Zcash over Tor”, which is a problem if it’s not practical to make this the default. Is that the main problem, or are there others?

@secparam I think the useful thing about Nathan’s idea is less that it helps the end user and more that it gives wallet developers an out-of-the-box solution to offering users privacy that comes with a thought-through set of privacy claims and warnings. If setting this up correctly is trivial for a wallet developer then documentation is enough, but I don’t think it is trivial.

Bundling Tor with your app is some work, and the way Tor interacts with zcashd is important too, no? For example, @harryhalpin’s point that you’d want to create a new Tor circuit for each new transaction (and presumably also for each time you ask lightwalletd about a specific transaction.)

It seems like there’s a trade-off between these two things:

  1. If you connect to a single known node you reduce the risk of attacks run by malicious nodes, since it will always be easier to fill the network with malicious nodes than to subvert a particular node. But you shrink the anonymity set to “people using that node.”
  2. If you connect to the peer-to-peer network, you have a larger anonymity set, but you are more open to attacks by malicious nodes.
1 Like
59

The solution is to decouple the node from transaction generation and submission. Then let the app decide how to submit TXs. The app is going to have to decide how to handle that stuff anyway. And things like DNS and network requests by the app may need to go through Tor as well.
So step 1) split out TX submission. Step 2) maybe package tor as a library for app developers.

60

I’ve opened [rpc] -txsend config option for sending transactions via an external command by str4d · Pull Request #4522 · zcash/zcash · GitHub with this code.

4 Likes
61

This issue seems related

Two of the biggest impediments to building on Zcash right now are

1 Like
62

Thanks for sharing!

Can you explain more about how network privacy uncertainty inhibits your plans? What kinds of clarity would help there?

Agreed that fee mechanism is a big area of concern, and this is the next area I personally plan to focus on related to the larger longer priority of scalability.

My personal favorite approach to transaction fees is to adapt something like EIP-1559 for Zcash. I haven’t persuaded others within ECC or broader Zcash community about it yet, but I’m actively researching what that could look like. See also Evaluate alternative transaction fee market mechanisms · Issue #3473 · zcash/zcash · GitHub

2 Likes
63

Fingerprinting harm is compounded by the existence of multiple issues such as tx fees not being enforced, network layer leaks and limited adoption of shielded transactions (a non trivial amount being pass through).

It does appear that some pending issues are being addressed in Zebra, so I am happy about that.

What would I like to see? In the long term mixnet, but in the meantime we need one or both of the following:

txsend config option
Dandelion++

The service I am building will take advantage of the Zcash memo field and is likely to generate thousands of transactions per day shortly after launch. Network layer fingerprinting is a big negative particularly with the transaction volumes I envision compared to current network shielded transaction levels. Mitigations might include generating extra transactions (in order to reduce the ability to fingerprint the data being recorded on the blockchain by my service) but will lead to extra transaction costs for our corporate clients and cannot prevent a competitor from building a similar service and undercutting me on fees because ZIP 313 does not include enforcement.

My service is designed to be sustainable. So far the only solution I can see is to build redundancy (recording data on another chain in addition to Zcash). As a result, what could have led to free publicity of Zcash to corporate clients, will be mostly abstracted away. This can be easily remedied in the short term with fee enforcement and one or both of available network layer improvements mentioned above. Then we can spend more time evaluating long term solutions such as a EIP-1559 alternative for Zcash and mixnets.

64

I’m reviving this thread to announce that we are finally releasing our first testnet for Meson!

The first testnet’s emphasis is on the node operator experience and we provide support for major Ethereum chains and L2s. In subsequent testnet releases, we will be adding support for other chains, implementing our research and other features. We have gotten interest from teams working on Firo, Solana, Cosmos, etc in having support for these chains within Meson. We hope that the Zcash community still has an interest in Meson and would like to have Zcash be supported. Our long-term goal is to be a multi-chain public good that provides network-level privacy to many different blockchains including Zcash!

You can all check it out at mesonmix.net.

11 Likes