Status of Network-level Privacy Efforts in Zcash

The intention of the Meson project is indeed to deploy a cryptocurrency-specific mix net. That being said, once a mixnet is up and running, anyone can add providers that support any kinds of application through the use of plugins. There’s no explicit way for me to prevent people from naturally doing just that as long as everything is sybil controlled in a permissionless way. A recent realization of mine is that the Meson project can be a segway into a more general usage mixnet. In other words, first deploy an application specific mixnet and then see how a community emerges around it. Perhaps, this community might naturally extend the usage of the mixnet to other applications and eventually end up creating a general usage mixnet.

1 Like

Hi Zcash core devs and Zcash community,

My name is David Stainton and I’m one of the authors of the Katzenpost mix network.

It is my understanding that because Katzenpost is under the AGPL, Nym/Harry decided that
in order to cut a deal with their VCs they must provide some alternate license to those VCs to allow them to make proprietary software. I believe this is the true reason why Nym has written their own mixnet instead of using Katzenpost. However I think it’s totally fine for their to be more than one mixnet. I do not think of our two projects as being in competition although I was a bit triggered by Harry’s message because of historical reasons.

When Harry says they have better performance in Rust what he means is that they have better performance than their own Golang mix network implementation. The Katzenpost server side was primarily written by Yawning Angel and thus is very well implemented with great attention being paid to it’s performance. (happy to go into details upon request)

Another thing to note about the history of Katzenpost is that Claudia Diaz and Ania Piotrowska have both contributed to it’s design… and Ania has stated in the past that she would open source her mixnet simulator to aid in the tuning of the Poisson mix parameters. It has always been a development goal of Katzenpost to use Ania’s simulator. However I am aware that Harry has hired Ania and Claudia and perhaps this has somewhat altered our previous spirit of collaboration and sharing because nobody has contacted me about any recent development of Ania’s simulator.

I have tried very hard to make a living researching and implementing mix networks without any help from VC funding. We managed to get a lot of work done with a few grants.

Sincerely,
David Stainton

3 Likes

To add to the above, David has been helping out a lot with explaining, support and advice for Meson. I should have mentioned him in this particular conversation much earlier on.

Further, David has already had many interactions with various members of the Zcash core team, namely @daira and @str4d. He has demo’d a version of a wallet that sends shielded zec transactions through the mixnet. Further, he has offered support years ago for enabling the easy creation of shielded transactions, namely in this github issue.

4 Likes

Hi Chelsea,

Hopefully in the coming years there will also be more people available with experience with mix networks. It’s interesting to note that Zooko and Daira contributed to mixminion design way back some years ago. I guess the only way to gain mixnet experience is to help out with some kind of open source software project that implements a mixnet.

Authority and PKI:

Katzenpost has a “testing” single server authority and a voting authority which works in much the same way as the Tor Directory Authority; mix descriptors are uploaded to each authority and later several voting rounds take place to create a deterministic consensus document. I’m aware that this is not Byzantine fault tolerant just as Tor’s Directory Authority is not. However I think it unfair to call this a centralized system. Let’s improve it. Andrew Miller and I were talking about collaborating to make a better design which should be easy since it’s kind of an established practice nowadays to pick a BFT off the shelf and use it for something like this.

I would prefer that concerns over the Katzenpost design be directed towards me as I’m currently the main developer. I’m glad that Mikerah pointed me to this discussion.

Yes understanding the current state of Nym is important. I have previously audited their golang implementation and found quite a few reasons to raise my eyebrows.

Sincerely,
David Stainton

2 Likes

Hi Chelsea,

I just now noticed that your message has a Scalability section. The point you raise here is correct in that scaling costs are linear relative to the number of mixes. However, unlike Tor, mixnets do not rely on route unpredictability. We therefore do not require 7,000+ nodes in the network to satisfy our threat model. Furthermore if you read the Loopix paper and then notice in the bibliography that mentioned a paper by Claudia Diaz: “Impact of Network Topology on Anonymity andOverhead in Low-Latency Anonymity Networks”

In this paper Claudia points out that when we have a layered or stratified topology as Loopix and Katzenpost do then when we add mixes to each layer this effectively reduces the entropy in each mix. Therefore these kinds of mix network topologies cannot simply grow upon any conditions such as someone “feels like running a new mix”… but rather must have mixes added to the network if there is enough traffic to justify it and new mixes are needed for the load balancing effects.

Mixnets scale really well.

The issues with the PKI/authority can be dealt with. Currently the consensus documents are cached at every Provider where clients connect directly, similar to a Tor Guard caching the Tor consensus document.

Sincerely,
David Stainton

3 Likes

–thx, all, for posting your discussion here. It has given me some good leads on the keywords to start learning about these areas.

2 Likes

I’m late to this thread, but as a Zcash supporter, an online privacy advocate and a wallet developer (https://zbay.app) this discussion seems important, somewhat neglected, and really likely to get stuck in an “important but neglected” state.

Reasons why it might stay neglected:

  1. @nathan-at-least’s point above about “networking is not our forte, per se” even if an overstatement I think points to an issue where this question spans multiple domains. projects often get stuck on questions that span multiple domains and areas of expertise.
  2. being part of the plan for scalability makes it tempting to address it only as part of a major future upgrade. projects often get stuck on objectives that are linked together in a major future upgrade, as opposed to when objectives can be pursued in parallel, incrementally.
  3. there are efforts by other teams like Nym in the works that seem promising but don’t have traction yet. projects often get stuck in the mud waiting for outside teams to solve a problem, as opposed to tackling it internally.

It’s too hard for me to tell if any of these things are happening as a relative newcomer and as someone standing outside both ECC and ZF, but it seems like there’s a lack of urgency here, given what’s at stake. No reputable centralized payment platform would ever consider it acceptable that their users’ physical location be this public, or easily made public.

If Tor is the best solution right now, Zcash should use Tor. If that’s not considered safe enough to be the default, then there should be some lesser level of protection analogous to a centralized service or VPN. A trusted node that could relay your transactions—run by a known entity like Zcash Foundation with now-standard policies like a “no logs” data retention policy and a warrant canary—could foil the blockchain analytics companies, no? And it would be better than leaving users and wallet developers on their own to figure this out.

8 Likes

We are working on this, as it’s part of the Zcash Foundation’s roadmap for the year. We’ve been developing a more detailed threat model and investigating other projects’ transaction-source anonymity solutions (like Dandelion and of course Nym), but the first pass at this is certainly just going to use Tor.

The ZF team has people who are familiar with the problems of applying Tor to a novel application, but there are details to work out and software to write so it isn’t an instant solution. For instance: the existing Tor support in zcashd just routes everything over Tor, but how anonymous is that if a rapid series of transactions happen to share a circuit? How should inbound p2p traffic or block requests (as opposed to transactions you’ve originated) be handled, and what guarantees do you get from using a network anonymity layer for each type of traffic?

These are questions we’ve long had sort of gut feelings about, but haven’t formally analyzed. It is ridiculous that this has been a problem for so long, and I’m glad to have resources to address it now. Watch this space!

10 Likes

This is great to hear!

Is your expectation or goal that the result of this work become part of zcashd’s default behavior? Or will it remain something that users have to activate?

Will this functionality be included in zcashd? Or will users / wallet developers have to install Tor as they do now and get the two working together?

3 Likes

In short: “as yet unknown.”

To your first question, I think it would have to be optional. I’m reluctant to make Zcash functionally reliant on Tor since Tor is sometimes blocked or slow for reasons that are totally incomprehensible to most users. “Q: Why doesn’t my Zcash app work on the public wifi? A: Check your Tor bridge settings” implies an odyssey of discovery that I’d sooner avoid than mandate. This is why we’re also interested in Dandelion, which achieves a lesser measure of transaction source obfuscation but in a way that’s completely transparent to the end user. If there’s no silver bullet for privacy, we’ll try several of the normal lead ones :slight_smile:

For the second question: if we’re going to include it at all, ideally I’d like to bundle tor’s (somewhat new) “library” mode rather than requiring users to install and configure two complex distributed system clients to do privacy. I can’t say for sure if that will work yet though, since afaik that build configuration is really new to the little-t tor project.

8 Likes

This is a tricky question for sure.

If Tor can’t be enabled by default (given the risk of introducing some unreliability—which makes sense) I think the priority should be pursuing some meaningful level of protection that can be enabled by default, even if it doesn’t offer protection as strong as Tor.

With Tor offered just as an option, I can’t see it becoming part of the core privacy and security claims that orient Zcash as a community, movement or brand. Ultimately, these core claims are going to be what receive the most attention and scrutiny from developers, auditors, academic security researchers, journalists, and customers themselves. And whatever the default setup is will receive so much more exposure to being tested in real-world scenarios. Does this make sense? Plus there’s the issue where optional levels of protection introduce the possibility that users accidentally disable it, get tricked into disabling it, etc. Being optional is an issue in itself.

We include Tor support now in Zbay where the user has to install Tor separately. So it would be hugely helpful to us if Tor came with zcashd and was pre-configured to offer the best possible protection. We would totally use that. And Tor is the standard right now for the best practical protection available, so being able to say “Zcash is built for Tor” will be very meaningful to users who currently rely on Tor.

So I’d say that optional Tor support is a close second, but ultimately not as valuable as some level of reasonable privacy protection for all users, by default.

3 Likes

Hi David.

It is my understanding that because Katzenpost is under the AGPL, Nym/Harry decided that
in order to cut a deal with their VCs they must provide some alternate license to those VCs to allow them to make proprietary software. I believe this is the true reason why Nym has written their own mixnet instead of using Katzenpost. However I think it’s totally fine for their to be more than one mixnet. I do not think of our two projects as being in competition although I was a bit triggered by Harry’s message because of historical reasons.

Before delving into licensing, what’s the point of creating a mix-net or any anonymous communication network? If only three or four whistleblowers are using the mixnet, then its pointless from an anonymity perspective and even dangerous to create a chat app used only by whistleblowers.

Anonymous communication networks only are as good as the amount and diversity of traffic in the network. This is a basic point that seems to have been missed by Katzenpost/Meson. So you don’t want a mix-net for just Ethereum, for just ZCash, or for just your latest Katzenchat whistleblower cat-themed chat app. You want a generic mixnet infrastructure capable of handling serious amounts of traffic and ideally decentralized as otherwise you don’t get the security guarantees of a mixnet.

So, while Katzenpost may want a free software project where only contributors and apps use the GPL, in the real-world we want to maximize usage under the least restrictive licenses: In order to increase the users and thus anonymity provided by the mixnet. That’s why Tor uses a permissive license and it seems to be a good move. You can try to hack it with dual-licensing ala Moxie’s work on Signal, but that leads to copyright assignment which is hard for open source projects. It’s one reason we at Nym ditched the Katzenpost codebase and that’s why Nym chose Apache2 for licensing. There’s no secret conspiracy involving investors and we aren’t part of a Richard Stallman cult. Any sensible researcher or entrepreneur will ask why one would want to artificially constrain the amount of usage of the mixnet via GPL licensing limiting the amount of people using the mix-net.

When Harry says they have better performance in Rust what he means is that they have better performance than their own Golang mix network implementation. The Katzenpost server side was primarily written by Yawning Angel and thus is very well implemented with great attention being paid to it’s performance. (happy to go into details upon request)

In terms of raw Go plus assembler vs. Rust, the crypto that Nym uses in Rust is more than twice as fast and Sphinx creation is 73% faster, to the equivalent Go and equal when compared to the heavily optimized Katzenpost implementation. These are not surprising numbers for anyone who has compared Go to Rust in terms of crypto support, and would be I would assume why ZCash also moved to Rust. For us, it’s a win-win as we can use the same underlying crypto and optimizations as ZCash.

Lots of very good Go code was primarily written by Yawning Angel, and is of high quality. Unfortunately. Yawning Angel left the project over two years ago. We believe more optimization is possible, but we see no reason to deal with all the legacy code or the artificial constraint of being stuck with Go. Ultimately, at Nym we just built our entire mixnet infrastructure in Rust in 3 months from scratch, launched at CCC, and now have about 30 nodes including Electric Coin Company.

Another thing to note about the history of Katzenpost is that Claudia Diaz and Ania Piotrowska have both contributed to it’s design… and Ania has stated in the past that she would open source her mixnet simulator to aid in the tuning of the Poisson mix parameters. It has always been a development goal of Katzenpost to use Ania’s simulator. However I am aware that Harry has hired Ania and Claudia and perhaps this has somewhat altered our previous spirit of collaboration and sharing because nobody has contacted me about any recent development of Ania’s simulator.

While we all wish Katzenpost good luck, Claudia and Ania are no longer working on Katzenpost. Same to my knowledge with other researchers like Tariq and Aggelos. Katzenpost a perfectly fine free software project with some good implementation details, but we are working on a next-generation design that we hope will answer many of Chelsea’s quite valid concerns about mixnets in general and Katzenpost in particular. We do indeed have a simulator that will be open-sourced when it’s done going through peer review. That being said, building one should not be difficult in general for just entropy estimation (you can deduce the formulas from the original papers of Danezis and Claudia on entropy as an anonymity metric).

I believe could indeed be a problem, which is why we would suggest that a mixnet would be a good solution, in particular the usage of a mixnet as a sort of “VPN” before the p2p broadcast.

You may be able to address this partially by simply forcing new circuit construction over Tor. However, I do not think the problem can be formally addressed and would not put that out as a goal. Formal analysis of Tor is very difficult in terms of entropy or in terms of proofs of the entire network behavior (see papers by Aaron Johnson and Syverson, which never could adequately get it). Mixnets are also difficult, see UC work by Kiayias and some other game-hopping work I’m happy to share.

Instead, I’d aim for simulating traffic based on real data or doing samples of real data to see how useful or not useful particular anonymous networks are (i.e. mixnets, Dandelion, Tor), and seeing how hard it is to de-anonymize using straightforward machine-learning and correlation. We’ve seen work by Patterson, Meiklejohn, and others already show that, but I’m sure it can be done in quite a lot of detail.

From a UX perspective, probably an option to turn it off and on would be OK, That’s what Blockstream’s GreenWallet does with Tor, and it seems fine. Keeping on by default is I think the best unless network is realllllly unreliable.

I would not overestimate the number of ZCash transactions in general and shielded transactions. Currently shielded transactions are I believe about 1% of all transactions, and ZCash transactions themselves are not very frequent. The problem is power users who may do a lot of shielded transactions within a few minutes. Shielded transactions would require being mixed with other traffic to get any network-level anonymity in general due to their infrequent nature.

Dandelion is fine for IP obfuscation on paper against very weak adversaries, although I’m a bit surprised that technique is considered more reliable than Tor. Last time I checked, the BIP was rejected and it does not have as much wallet support as Tor (https://github.com/bitcoin/bitcoin/pull/13947).

1 Like

Hello Harry Halpin,

Oh you mean your Nymtech golang Sphinx implementation?
This one? nym-mixnet/sphinx.go at develop · nymtech/nym-mixnet · GitHub

Let us note that this Sphinx implementation is actually encoding the Sphinx header using Protobufs! And when Christiane Kuhn released her paper ( [1910.13772] Breaking and (Partially) Fixing Provably Secure Onion Routing ) about breaking Sphinx you could not fix it because your implementation always leaks the number of hops by making the header variable size. Furthermore even your recent version of Sphinx uses Lioness for it’s wide-block cipher. And yes this doesn’t matter since your payload is very small whereas our Sphinx payload is 50k so we actually get benefit from using AEZ. Therefore the comparison is not fair. Apples and oranges.

Sincerely,
David Stainton

Oh you mean your Nymtech golang Sphinx implementation?
This one? nym-mixnet/sphinx.go at develop · nymtech/nym-mixnet · GitHub Let us note that this Sphinx implementation is actually encoding the Sphinx header using Protobufs! And when Christiane Kuhn released her paper ( [1910.13772] Breaking and (Partially) Fixing Provably Secure Onion Routing ) about breaking Sphinx you could not fix it because your implementation always leaks the number of hops by making the header variable size. Furthermore even your recent version of Sphinx uses Lioness for it’s wide-block cipher. And yes this doesn’t matter since your payload is very small whereas our Sphinx payload is 50k so we actually get benefit from using AEZ. Therefore the comparison is not fair. Apples and oranges.

Hey David,

No, that Github repo you reference is very old, it was an implementation done in Go was done as part of her internship by Ania Piotrowska, the actual designer of Loopix, for some testing.

She has recently been working with us in Rust - see GitHub - nymtech/sphinx: A Sphinx implementation in Rust. We agree our packet format should do some more optimization,but in general native crypto is faster in Rust, which is why as I mentioned we are using Rust, not Go.

We also wrote a nice blog post about these attacks noticed by Kuhn you could understand: https://medium.com/nymtech/sphinx-tl-dr-the-data-packet-that-can-anonymize-bitcoin-and-the-internet-18d152c6e4dc.

Note the attack do not effect fixed-route packets, but hey, its good to correct. It never effected our Rust implementation.

1 Like

Sorry to play moderator here but @david415 and @harryhalpin should take their argument elsewhere. It’s derailing the topic and it’s a bad look for both of you.

I started this topic to get a discussion started around using anonymizing networks for Zcash, and what needs to be done to rectify the lack of network-level privacy, not to bring up old wounds between the both of you.

3 Likes

Agree. I don’t know the history of what’s behind the apparent friction between the projects but it’s certainly straying away from the intention of the thread.

2 Likes

As former co-workers on the same research project as David, we wanted to be clear that we do share some of Chelsea’s concerns in terms of Katzenpost and we also want to make clear that at least the researchers involved in Loopix and PANORAMIX have stopped contributing to Katzenpost and moved on to the Nym Rust codebase.

I think people can and have the right to be clear about what they are working on currently and what they have decided to stop working on. If any other researchers or implementers wish to continue with Katzenpost Go codebase, they are welcome to do so as its an open source project.

Personally, arguing over codebases is a bit silly if there’s not the fundamentals done in terms of defining the problem and the space of design options. So let’s step back.

As iterated before, in terms of network-level anonymity there’s three options (DC-nets and other non-scalable ones being thrown off) on the table:

  1. Dandelion (again, not sure how heavily implemented, but data points on this would be good).

  2. Tor (working well for Blockstream GreenWallet, but @gtank’s point that multiple bursty shielded transacitons could be in single circuit could, but may not necessarily, be a problem)

  3. Mixnets (Regardless of how one feels about Katzenpost/Go vs Nym/Rust, Chelsea’s point about lack of users is correct, and we’ll see how this continues. However, mixnets can provide larger anonymity guarantees over small sets of users than the above).

As I mentioned earlier, the primary issue is the defense of shielded ZCash transactions, as the rest are kind of pointless. So given their traffic signature, what makes the most sense?

For this, perhaps the first step would be to define:

  1. What the threat model is (where there may be disagreement over if a passive attacker on network-level is realistic)

  2. what the properties should be (in terms of what should be obfuscated)?

  3. Given data on the relatively small amount of shielded transactions makes sense, what of those above three designs accomplishes the goal?

Looking forward to reasonable answers and ideas on these more basic questions! Happy to not mention any codebases - its better not to obsesses over programming language choices etc. until the fundamental problem is well-defined. I fear currently in terms of ZCash it is not, but I’m sure people can define it better in this forum.

1 Like

@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

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