Status of Network-level Privacy Efforts in Zcash

Technology
1

One of the achille’s heel of Zcash is its lack of network-level privacy guarantees. There has been some thought around this in some of the issues in the zcashd repo. However, it seems like very little of this has been tested or implemented.

As some of you may know, I am working on a mixnet for cryptocurrency transactions dubbed Meson. It used Katzenpost and it’s currently in alpha and only supports Ethereum-based transactions. We are currently in the midst of a refactoring of the plugin library so that we can add support for other chains. I have discussed in private with some Zcash peeps about writing a ZIP for mixnet integration into Zcash and they thought it was a good idea. I’m posting this to gauge the general Zcash communities thoughts around this and whether I should indeed write a ZIP.

Any thoughts?

11 Likes
2

IIRC, mixnet is a required Halo component…?

1 Like
3

Hi, glad you posted here, it sounds really interesting! How does Meson compare to something like Dandelion?

1 Like
5

I would categorize each method into two broad categories. Mixnets are a cryptographic-based anonymous communication procotol whereas Dandelion (and Dandelion++) is a statistical (perhaps rumour)-based routing protocol. As such, Dandelion doesn’t provide the same anonymity guarantees as a mix network or onion/garlic routing (Tor, I2P). Dandelion is really good if you have an existing network and don’t want to spend the extra resources needed to retrofit a more complex anonymous networking protocol like Tor, mixnets, etc. However, for Zcash, Dandelion on its own wouldn’t complement Zcash’s strong on-chain privacy guarantees.

6 Likes
6

Yes! Lot’s of thoughts! :slight_smile:

This is an area Zcash definitely needs to improve in, so I really appreciate the effort. Some background:

  • At ECC this has been on our “wishlist” since the beginning, and we’ve never been able to devote resources to it. (Also, networking is not our forte, per se.)
  • David Stainton demoed delivery of Zcash transactions over Katzenpost a long time ago (maybe 2 years by now?). That never seemed to receive the attention it deserves, IMO, probably because many community members don’t understand the value of mixnets.
  • That demo relied on a transaction delivery plug-in feature @str4d put together, so that can be used to experiment with any variety of mechanisms.
  • From my conversations with the Zcash Foundation engineering team, I believe they’re going to focus much more on networking improvements than ECC has, and they have network privacy experts on their team. You should definitely chat with them about common plans or alternative approaches.
  • IIUC, mixnet privacy improves the more traffic with a similar profile runs across the network. To me that strongly suggests a single mixnet for many cryptocurrencies would benefit them all (assuming the different cryptocurrencies have similar profiles).
  • I think it would be cool if node operators of a mixnet got paid anonymously for service rendered. However, there may be all kinds of dangers there, especially since a surveillance adversary may deploy a large number of malicious nodes and getting paid would make that attack more feasible. (Not sure if not getting paid is better, though?) In any case, there are some fun protocol challenges here for “get paid anonymously, but only by providing legit service” kinds of problems.

Ok, those are the thoughts off the top of my head. Again, excited to hear your interest and effort in this area!

9 Likes
7

Oh, also this should be obvoius, but if this is true then I consider it totally legitimate to seek funding from many projects. Meanwhile I definitely believe Zcash community should contribute funding somehow. (This is my personal opinion and I’m not sure about specifics yet, like how much / where from.)

5 Likes
8

With shielded usage so low, it certainly is grounds for concern in Zcash. But the issue is often misunderstood. For example, if shielded usage was ubiquitous, mixnet based transaction submission would really not do anything. You’d need general purpose network privacy like Tor,

As I said earlier:
"Standalone network layer privacy for cryptocurrency is useless. No matter how good your network privacy is, cryptocurrencies are like Twitter for your bank account… every transaction leaks an amount, source and destination to everyone. Hiding your IP doesn’t fix this.

For any real privacy, you must hide the transaction graph (from, to, amount). Do that and your payment is an opaque blob + an IP address. All the world learns is that your IP made a payment, but not to who or for how much. No big deal. So no network privacy, no problem? Not quite

The party who receives your payment does learn your IP, and, unlike everyone else, they know who it’s to (it pays them after all). E.g., Pornhub learns your IP when you pay them. That’s awkward. So, do you need a network privacy layer? Yes, but not a cryptocurrency only one.

Network privacy for a cryptocurrency doesn’t work. It hides your IP when submitting a payment to Pornhub. But it doesn’t hide your IP when browsing Pornhub’s website, clicking signup, or streaming video. To hide your IP there, you need a general solution. Tor or the like."

4 Likes
10

Wouldn’t mixnets have mitigated the tx processing leak we saw last year? Re-reading in case I missed something

11

No. Mixnets would provide network-layer anonymity for sending transactions, while the PING and REJECT attacks applied to receiving transactions.

7 Likes
12

The existence of bugs like that does potentially mean mixnets might offer something even in a fully shielded world. I’d have to think about it more. General network anonymity is still better.

But in the case of those specific leaks, mixnets for transaction submission wouldn’t have helped. Presumably you’d use the mixnet to hide the IP source before the transaction is gossiped. But the leak was of the IP of the recipient which was inferred from behavior during transaction propagation through the gossip network and block validation. So again, seemingly, you want more general network anonymity.

4 Likes
13

Hi, this is Harry from Nym, formerly of the PANORAMIX project that funded the Loopix design and Katzenpost codebase. There seems to be some confusion about mixnets from all sides, so I’d like to chime in.

To respond to @Mikerah, yes it would be great if ZCash offered an anonymous communication channel like that offered by a mixnet. Not only ZCash, but many academic works (thinking of fraud proofs in Ethereum) need an anonymous communication channel, and their proofs of security (and privacy) of even their cryptographic constructions like zkSNARKS usually assume a working mixnet. A pretty big assumption :slight_smile:

That being said, while Katzenpost (of which Meson seems to be a rebrand) is an option, we abandoned working on that codebase and recoded everything in Rust at Nym to have better performance (we got 10x to 15x speed up) and abstraction. So, any ZIP should at least be neutral to the underlying codebase.

Katzenpost/Meson is not parameterized (i.e. the timing delays and amount of cover traffic), so it offers arguably worse anonymity than Tor and perhaps Dandelion++ in practice. Nym has built a dynamic simulator that can parameterize network traffic based on anonymity and capacity constraints, but right now it’s not fully integrated, although our default network is parameterized for cryptocurrency use-cases.

There is some misinterpretation in Mikerah’s characterization of mix-nets and Dandelion, as at least the Loopix design (used by Meson/Katzenpost and Nym) is a statistical “stop and go” mix, with the cryptography handled in the Sphinx packet format. Dandelion++ is a fine thing to use now until working mix-nets become more mature and would complement ZCash for now, although the amount of privacy it adds is less than mix-net, particularly if you assume a passive global adversary.

As for @secparam (Ian Miers) original take, it is not exactly correct that “if shielded usage was ubiquitous, mixnet based transaction submission would really not do anything” because a mix-net is a general purpose privacy network like Tor, but more suitable for message-based traffic than Tor’s stream-based traffic. Arguably, a mix-net is better than Tor. You do need both on-chain (i.e. ZCash) and network level privacy to guarantee privacy. While mixnets aren’t magic (and neither are zkSNARKS), unlike Tor mixnets do protect against timing attacks on the network level - and so could have helped on the PING/REJECT attacks. In general, mix-nets and Tor both protect IP address anonymity by design.

Hope that clarifies some things, and we look forward to seeing progress on network-level anonymity in the ZCash and broader cryptocurrency world!

9 Likes
14

Hey Harry, welcome to the forum! I’ve been following Nym for a bit, big fan of the project :slight_smile:

3 Likes
15

Meson isn’t a rebranding at all. In all of our docs, we mention that we use the Katzenpost software libraries. Meson is simply an instantiation of a cryptocurrency mixnet. Further, my post was about writing a ZIP independent of Meson, just Katzenpost. It’s up to the Zcash community to decide who are the mixnet operators, not me. I just wanted to gauge the overall sentiment in the Zcash community about doing this.

For our alpha testnet, there is indeed no parameterization. However, we are currently working independently on better heuristics for doing this. So, I wouldn’t say that Meson offers strictly worse anonymity for our particular use case and future research work.

In my previous reply, when I used the word “statistical”, I wasn’t thinking about the terminology used in the mixnet literature but instead in the rumor/gossip dissemination literature. The definitions are similar but different due to the considerations that both fields need to take into account. As for Dandelion++ being fine to use now for Zcash, I still don’t think this is accurate. I would say that for now, Tor is a better option for Zcash, considering that zcashd already has Tor integration.

1 Like
16

Halo is just a proving system, but network-level privacy is a required component of my full “scalable privacy” proposal.

9 Likes
17

The proposal is to use the mixnet to replace use of the block chain as a broadcast channel for transactions (and in particular note outputs); not just transaction submission. Also we want privacy against a global passive adversary, which Tor does not provide.

6 Likes
18

Consider a world where there only are shielded TXs. There’s no graph analysis. At least if we ignore timing attacks, there are only two things network traffic reveals.

  1. They reveal to the world you made a zcash transaction
  2. They reveal to the recipient of the transaction what your IP is. This could be significant if you wanted privacy from them.

My point is to protect against 2 in the most obvious scenario, you need generic network privacy that can handle web requests. Because you need to hide your IP not just when you submit the transaction, but when interacting with the recipient’s website.

Note, this says little about what you should prioritize without ubiquitous shielded adoption, other than you should seriously consider supporting something that does handle general privacy and web requests.

1 Like
19

@Mikerah: Meson isn’t a rebranding at all. In all of our docs, we mention that we use the Katzenpost software libraries. Meson is simply an instantiation of a cryptocurrency mixnet.

The first principle of anonymity is that anonymity needs a crowd. Strictly speaking, special purpose mix-nets will offer less anonymity than a general purpose mix-net.

So if you fork Katzenpost and make a special-purpose mix-net called Meson for cryptocurrency (or worse, for only ZCash or only Ethereum), Meson will offer less anonymity as its anonymity set will be the number of cryptocurrency transactions over Meson, which would be less than a general purpose mix-net.

That being said, if you made a generic mix-net and had different, interoperable code-bases, that could offer better anonymity by blending active user-bases. However, in practice this hasn’t happened with anonymity networks like Tor. So while you can make an interoperable Tor client in say, Java (as has happened), the core Tor code is developed quite quickly by a large team while Tor-in-Java has had considerable bit rot and been abandoned.

So, what you want is a single general purpose mix-net with the maximum number of users. You want to support not just cryptocurrency, but any kind of traffic. This is where @secparam is correct, although he is incorrect in believing that mix-nets can only handle one kind of traffic (such as cryptocurrency). There’s a space of trade-offs between Tor and mix-net design.

@mikerah: So, I wouldn’t say that Meson offers strictly worse anonymity for our particular use case and future research work.

Unless there is cover traffic and timing delays in the Loopix design, currently an unparameterized mix-net offers about the same anonymity as a VPN (i.e. no resistance to a global passive adversary) with multiple exit nodes, and with lots less users than Tor and so a smaller anonymity set. So that’s why we recommended to efforts like Grin to just use Tor rather than build their own mix-net if they need a solution today.

@mikerah: The definitions are similar but different due to the considerations that both fields need to take into account. As for Dandelion++ being fine to use now for Zcash, I still don’t think this is accurate. I would say that for now, Tor is a better option for Zcash, considering that zcashd already has Tor integration.

Note that you can have mix-nets that are based on cryptographic constructions, such as MCMix that uses secure multi-party computation (it’s just reallly slow and likely can’t scale, like a DC-Net). However, implementations of Loopix such as Katzenpost and Nym are not cryptographic constructions, but “stop and go” statistical mix-nets. You can have “free routing” mix-nets based on p2p architectures, but these are vulnerable to route capture and tons of attacks, and generically less anonymity. I recommend looking at the papers by Claudia Diaz of Nym on these topics.

I would continue to argue that Dandelion++ is fine if your goal is 1) generic hiding of IP addresses and 2) it’s mandatory in ZCash. It gets you the same property, i.e. IP address hiding, and the anonymity set will be as big as the number of implementations of ZCash that support it. The anonymity set of Tor would be larger of course, but how many people turn on Tor with ZCash.

Overall, you only want a mix-net if you want resistance to a global passive adversary on the network level. I support this strongly, as it’s a realistic threat model for cryptocurrencies given say, Chainalysis, and the goals that ZCash is trying to provide.

However, what you want is a generic mix-net infrastructure, not a cryptocurrency-specific mix-net, and one that actually uses the features of Loopix that provide this level of resistance to a GPA. If such a proposal was generic to the underlying codebase, that would be great, but as an ex-W3C employee who did test-suites, formal verification, and specs, don’t underestimate the amount of work in interoperability.

8 Likes
20

@secparam Consider a world where there only are shielded TXs. There’s no graph analysis. At least if we ignore timing attacks, there are only two things network traffic reveals.

Yet preventing timing attacks is exactly what mix-nets provide. I believe timing attacks were used in PING/REJECT attacks on ZCash, and I’m not sure that’s timing attacks in ZCash should be ignored in the future.

@secparam My point is to protect against 2 in the most obvious scenario, you need generic network privacy that can handle web requests. Because you need to hide your IP not just when you submit the transaction, but when interacting with the recipient’s website.

Traffic analysis is a world of pain, and there are different types of traffic that go beyond ‘websites’ and cryptocurrency. First, mix-nets can provide generic network privacy. Modern mix-net design (i.e. not Chaumian mixes, but Loopix etc. via Sphinx) provide SURBs (Single Use Reply Blocks) and other mechanisms (service providers with loops) for both receiving and sending generic transactions. For message-based asynchronous traffic like UDP (cryptocurrency transactions, but also instant messaging, email, perhaps Voice-over-IP), mix-nets seem to be way to go. The only question is: Are mix-nets fast enough for web-surfing and is the anonymity set provided for message-based traffic large enough?

For web-surfing (more accurately thought of as stream-based synchronous traffic), it’s trickier as in order to provide bitwise unlinkability, mix-net Sphinx packets use asymmetric crypto more than Tor. That being said, Tor doesn’t provide the level of privacy as mix-nets against a GPA due to not using asymmetric crypto enough.

In the long-run, researchers are moving this infrastructure to the router level and have shown massive improvements so that mix-nets could be perhaps used for web-surfing, but in the short-term the ideal solution is just to use Tor for what Tor already exists for - web-surfing - and to use mix-nets for messaging and cryptocurrency, until the speed/anonymity optimizations are better worked out for the real-world. The transactions on-chain would be resistant to a GPA (and the chain is a huge boon for graph analysis) could your websurfing behavior to your on-chain behavior should remain unlinkable.

7 Likes
21

Hi all,

As someone at the Zcash Foundation with significant network privacy experience, here is my initial assessment of the suitability for integration of Meson as it is today into the Zcash network. Note that this assessment is not exhaustive.

Network makeup and size

  • As with any anonymity network, the security and privacy of clients depend on the network size. Because Meson currently only exists as a test network, it doesn’t make sense to integrate this as a supported anonymity layer to relay application traffic. In other words, the network needs to be at an appropriate size before considering client integration to ensure reasonable security.

Authority and PKI

  • As stated in the Meson project [1], the project requires a centralized authority without stating who runs these authority nodes, and manual exchange of public keys. This clearly is not scalable and could also be considered as a security risk; overall, this is a non-starter in terms of production-readiness.
  • Further, determining what the authority should be is a non-trivial amount of both research and implementation effort. Projects like Tor have a clear and simple concept of an authority- it is a set of trusted community members, where each member constitutes one vote. Any other concept of authority can lead to security tradeoffs such as exposure to epistemic attacks and/or path-routing attacks, depending on the levels of decentralization and consistency of the network view.

Security of the network

  • One requirement to running an anonymity network is performing network monitoring to detect malicious behavior, such as an attacker flooding the network with new nodes or to detect DDoS attacks (and deploy mitigations, where necessary). This is something the Tor project does explicitly (they in fact have a dedicated team specifically for network health and security). Again, as there is no plan in Meson for this kind of ongoing network health maintenance, this is a non-starter.

Scalability

  • Because Meson is a re-branding of Katzenpost, Meson similarly inherits the scalability shortfalls of Katzenpost, notably that clients must maintain an up-to-date network directory (or otherwise maintain undesirable security tradeoffs such as exposure to path-routing and/or epistemic attacks). As such, the bandwidth cost to clients scales linearly relative to the number of relays in the network. This will be a challenge for any mobile wallet client.

Work required before practical deployment:

  • As noted on the Meson page, there is a significant amount of outstanding work required before it is ready for practical deployment. Tuning of parameters for latency versus privacy is a non-trivial amount of work, as is implementing a distributed PKI.

In summary, my assessment is that Meson is too immature as a project to be considered for production use in Zcash. For the short term, I recommend that we use an anonymity network that exists in reality whose existing security properties are well-understood. The largest and most active anonymity network that meets this criteria right now is Tor, which is why Tor is the best short-term option for Zcash in terms of user privacy and well-understood security properties, at least until mixnet alternatives are sufficiently mature.

Further, while Tor currently has a similar globally-consistent network view requirement for clients as Katzenpost (and by extension Meson), Tor has a open proposal [2] to limit client network overhead to a constant amount relative to the size of the network, which makes it a more scalable alternative to Katzenpost.

I would like to better understand the current state of the Nym mix network and consider whether this is a good option for in the future as the project matures, due to the depth of research experience on the team. With that said, I have similar concerns about the maturity and security of the Nym mix network as I describe above, of which I would like to discuss further with Nym developers in the future.

Thanks,
Chelsea

[1] GitHub - hashcloak/Meson: The main Meson project github
[2] torspec/300-walking-onions.txt at main · torproject/torspec · GitHub

11 Likes
22

Relevant:

6 Likes