\documentclass{article} \usepackage{amsthm, amsfonts, amssymb, amsmath, graphicx, cancel, framed} \usepackage{mathtools} \usepackage{multicol} \usepackage{multirow} \usepackage{amsmath} \usepackage{amsfonts, txfonts} \usepackage{ifsym} \usepackage{commath} \usepackage{amsthm} \usepackage{caption} \captionsetup[figure]{font=small,belowskip=-10pt} \captionsetup[figure]{font=small,aboveskip=3pt} \usepackage{wasysym} \usepackage[hyphens]{url} \urlstyle{same} \usepackage{xifthen} \usepackage[usenames,svgnames,table]{xcolor} \setlength{\marginparsep}{8pt} \setlength{\marginparwidth}{40pt} \setlength{\marginparpush}{5pt} \newcounter{mn} \setcounter{mn}{1} \newcommand{\superscript}[1]{\ensuremath{{}^{\textrm{\scriptsize #1}}}} \newcommand{\roughtext}[1]{\begin{color}{SkyBlue}#1\end{color}} \newcommand{\mntext}[1]{\colorbox{SkyBlue}{\begin{color}{black}#1\end{color}}} \newcommand{\mn}[2][]{{\tiny\superscript{\mntext{\arabic{mn}}}}\marginpar{\scriptsize{ \ifthenelse{\isempty{#1}} {\mntext{\parbox{0.95\marginparwidth}{\superscript{\arabic{mn}}~\raggedright{#2}}}} {\mntext{\parbox{0.95\marginparwidth}{\superscript{\arabic{mn}}#1 says:~\raggedright{#2}}}} }}\stepcounter{mn}} \newcommand\supth{\ensuremath{^{\textrm{\scriptsize th}}}} \title{Zcash Network Privacy Assessment} \author{The Zcash Foundation} \begin{document} \maketitle \section{Introduction} The amount of data leaked about individuals online is ever growing; and financial data in particular provides a highly granular lens about personal daily habits. Zcash is a cryptocurrency that ensures strong financial privacy for users by leveraging zero-knowledge proofs and randomization techniques~\cite{zcash-spec} to protect against data leakage that could otherwise lead to deanonymization of a payer or recipient of Zcash. Use of zero-knowledge proofs in this manner ensures that the raw bytes of a Zcash \emph{shielded} transaction cannot leak identifiable information about the payer, payee, or amount. However, an adversary observing the Zcash network could perform passive or active attacks with the goal of linking users and their end recipients, even if that adversary cannot decrypt the Zcash shielded transaction directly. Consequently, ensuring additional mechanisms to protect against network-level adversaries seeking to deanonymize users is important. In this technical report, we assess the capabilities of such nework adversaries, and present a more formal assessment of network privacy Zcash users, with a focus on \textit{shielded transactions}. We identify what is considered sensitive information in the Zcash ecosystem, potential adversaries, and enumerate several attack vectors. We then consider several network privacy mechanisms and assess the extent to which these mechanisms improve the privacy and security of Zcash users. Finally, we identify near-term and long-term recommendations for improvements. \textit{Organization}. We begin in Section~\ref{background} by discussing background information useful to understanding the network privacy that Zcash ensures for users. In Section~\ref{observations}, we describe the difference between adversarial network models in blockchains as opposed to other applications such as web browsing or email. In Section~\ref{threat-model}, we introduce a basic threat model for Zcash. In Section~\ref{network-privacy-review} we describe the network privacy mechanisms that we include in our assessment, and in Section~\ref{network-privacy-assessment} we perform this assessment. In Section~\ref{future-improvements} we outline furture improvements we are planning to implement, and we conclude in Section~\ref{conclusion}. \section{Background} \label{background} \subsection{Zcash Shielded Transactions} \label{shielded} While Zcash does allow for use of unshieleded transactions, in this technical report we focus on assessing the network privacy for users assuming the use of shielded transactions. However, we will now briefly describe the difference between the two transaction types. As mentioned before, unshielded transactions are similar to Bitcoin transactions, and expose the pseudonyms of the payer, payee, and the amount paid. When this information is exposed to the network and persisted indefinitely to the Blockchain, it is effectively ``Twitter for your bank account''. Shielded transactions, on the other hand, expose what is essentially a “one time pad” to a network observer. Because not only the transaction information is encrypted, the encryption process itself is randomized such that two transactions that have identical payers, payees, and transaction amounts result in bytes that are completely indistinguishable from randomly-generated bytes. In other words, given only a series of shielded transactions, an adversary would not be able to gain enough information to distinguish any \emph{personally identifiable} information about the transaction plaintext. In other words, while nodes \emph{can} observe information about transactions such as timing or other fingerprintable network-level anomalies, we are concerned with the capability of an attacker to use information to tie a \emph{particular} transaction to \emph{both} its sender and receiver's real-world identities. \subsection{Comparison of Zcash Privacy Expectations to Bitcoin} While Zcash provides the ability to make shielded transactions to completely hide the information contained within a transaction, users of Zcash can also make non-shielded transactions. Because Zcash is a fork of Bitcoin, non-shielded transactions consequently have effectively the same expectation of privacy as plain Bitcoin transactions, which had been proven to be insecure against deanonymization attacks~\cite{anon-bitcoin}. In this post, we will focus on evaluating the setting when shielded transactions. While both Zcash and Bitcoin have future goals of stable Tor integration and other network-privacy mechanisms, this routing via an anonymity layer does not prevent attacks that examine the bytes of the transaction itself. So unshielded transactions in Zcash and all Bitcoin transactions leak information to a network observer, which can be exploited to perform deanonymization attacks. Further, use of network privacy tools may not completely mitigate deanonymization attacks against unshielded transactions~\cite{JAWAHERI2020101684}. \subsection{Zcash Protocol for Producing and Receiving Transactions} \textbf{Producing a Transaction (Spending Funds)}. A user wishing to spend funds can publish a new transaction to the network in several ways. The user could operate a \emph{full node}, meaning this node also participates in all network behaviour, such as gossiping transactions, responding to queries for the current state of the network, etc. The user can also spend funds via a \emph{light client} by publishing their transaction to a \emph{light wallet node}, which itself is a full node which additionally can handle light wallet functionality. Note that while publishing a transaction to a light wallet, the user exposes the fact that they are making a Zcash transaction (as the light wallet learns a particular transaction, along with the IP address of the user). However, the light wallet will not learn the identity of the receiver of the funds~\cite{light-wallet-spec}. \textbf{Receiving a Transaction (Accepting Funds)}. A user receiving a transaction similarly has two options for how to receive these funds, either via a full node or via a light wallet node. An important point to emphasize that because Zcash is a broadcast protocol (all full nodes sync the full state of the network), a user receiving transactions via a full node will not expose which transaction they are interested in receiving. In other words, because full nodes maintain the complete blockchain, they will not leak to any external party which blocks they require in order to process receiving of funds. Similarly, a user fetching transactions from a light wallet will also fetch all block headers and therefore not expose which transaction they are interested in. However, one slight exception exists for clients that wish to learn the full details of a transaction (such as the memo field). For this case, they must query the light wallet for those details separately. As such, the light wallet can link a recipient to a particular transaction in the case the user queries for extended transaction fields for a specific block~\cite{light-wallet-spec}. \section{Observations on End-to-End Network Attacks against Blockchains} \label{observations} We now describe several observations that we made while assessing the end-to-end network privacy of blockchains, where network state is published and synced to a globally consistent data store such as a blockchain. We contrast these observations with threats that are typical for a applications where users are browsing the web, exchanging email, or engaging in a messaging platform, for example. As stated previously, we assume the use of \emph{shielded} transactions for the below analysis. \textbf{Observation One: PoW Consensus adds more significantly more end-to-end latency than web application traffic.} While different cryptocurrency networks have a range of consensus mechanisms, in Zcash and other proof-of-work (POW) networks today, the latency between when a transaction is published and when that transaction is included into the Zcash blockchain is upwards of one minute~\cite{zcash-faq}. Hence, network privacy mechanisms that are tuned for lower-latency applications such as web applications will not meaningfully protect against end-to-end timing attacks in blockchains that use a PoW-based consensus. While such network privacy mechanisms may frustrate an attacker seeking to deanonymize only one end of the transaction (such as a mixnet preventing a node from identifying the source node that published the transaction), this use case in the setting for Zcash does not allow for end-to-end correlation. Hence, unless network privacy mechanisms that are indended to frustrate end-to-end timing attacks (such as mixnets) impose more latency than the blockchain consensus protocol itself, such mechanisms do not add additional meaningful protection against \emph{end-to-end} timing correlation attack. Such an observation extends to any network privacy mechanism that adds noise, such as generating dummy packets or transactions, as it is unclear how noise can be generated and distributed in a truly end-to-end setting. \textbf{Observation Two: Performing end-to-end correlation attacks in blockchains require attacking a broadcast network, not a point-to-point link.} In a setting such as accessing content online or sending messages or emails, application traffic is sent from a sender to receiver, proxied through a series of servers. In this setting, an adversary could perform end-to-end correlation attacks in a number of ways, such as observing distinguishing identifiable patterns as information enters and leaves the network. The latency of these applications is important, as faster transmission can increase the possibility for timing correlation attacks, but so are other factors such as the pattern of packets or exposed metadata. However, blockchains create a different landscape for an attacker that wishes to perform \emph{end-to-end} correlation attacks. Namely, blockchains require that transactions are \emph{first} included in the blockchain (the global state of the network), only \emph{after} which the receiver of the funds can learn about the transaction. \textbf{Takeaways} While adversaries can certainly perform \emph{end-to-end} attacks in a blockchain setting, the above observations indicate that doing so requires different adversarial models than in other application settings such as for web traffic or email applications. Hence, we do not consider end-to-end timing or packet correlation attacks when evaluating general-purpose network privacy tools such as Tor or general-purpose mixnets in this assessment of network privacy for Zcash in the setting where shielded transactions are used. \section{Analysis of Attack Vectors in Zcash} \label{threat-model} We now assess attack vectors relevant to Zcash. We define the information of interest to an attacker as the below tuple. \textbf{Information of interest: learning the tuple (sender network identity, transaction, receiver network identity).} This three-tuple of sender network identity, transaction, and receiver network identity allows for an adversary to link the fact that a specific sender of Zcash made a payment to a specific receiver, even though the amount of the payment is not disclosed. By ``network identity'', we mean the IP address of a sender or receiver, or other distinguishing information that is not included in the transaction itself. This differs from the ``on-chain'' identity of a sender or receiver, which Zcash shielded transactions hide by randomizing addresses. While the sender and receiver public keys (on-chain identity) are not exposed by the Zcash transaction itself, an adversary could learn their network identity by observing or participating in the network. \subsection{Adversarial Model} We begin with a brief review of possible adversaries, whom we will consider in our analysis of attack vectors. \textbf{Regular Zcash user:} Allowed to send and receive transactions and act outside the protocol, just as a real user. \textbf{Regular Zcash Node Operator:} Can operate one (or many) full Zcash nodes, and can store and forward all traffic that is sent through the node. Can query for network information, and store and examine all information it receives. \textbf{DNS seeder operators:} Operates the node that is used by new nodes when bootstrapping to the Zcash network, in order to learn about other nodes in the network to begin communicating with them directly. \textbf{Internet Service Providers (ISPs):} Can view traffic sent and received from either users or Zcash nodes. Can store observed traffic, forward traffic to other parties, and compare traffic with other traffic. \textbf{Government actors:} Can issue secret subpoenas and force ISPs and regular Zcash users to take actions they may not wish to take, such as turning over secret keys or server logs. \subsection{Attack Vectors Against Shielded Transaction Use} As described in Section~\ref{shielded} an adversary could gain more information about a shielded transaction by observing information exposed to the network. Keeping this in mind, and assuming that a transaction is shielded, we now review sensitive information that could be exposed and used for malicious purposes by a adversary. We divide attack vectors an adversary can employ using these information leaks into \emph{in scope} to our immediate network privacy assessment, and \emph{out of scope}. \subsubsection{In Scope} \label{in-scope} Note that an adversary has the ability to observe both \emph{on-chain} visible data as well as information or behaviour that is exposed to the network during the process of submitting a new transaction or receiving a transaction. \textbf{On-Path end to end correlation attacks:} This attack could occur by an adversary that can obtain the (sender identity, transaction, receiver identity) tuple discussed in Section~\ref{threat-model}. By \emph{on-path end to end correlation}, we include attacks performed by nodes that are directly on the path between a sender and receiver when publishing or receiving a transaction. In the current model of Zcash, such an attacks are practical only when the recipient uses a light wallet in such a manner that leaks the transaction that the sender or receiver is publishing, as further described in Section~\cite{light-wallet-spec}. \textbf{Block access patterns:} Even if a user accessed information about the Zcash blockchain using an anonymity tool such as Tor, the access patterns for specific blocks could leak information to network adversaries, such as the time of day that users requested information about that block, or its popularity. \textbf{Denial of Service attacks:} such attacks could be performed against Zcash nodes, such as DNS seeders refusing to respond to certain queries, or against Zcash users, such as light wallets refusing to service certain classes of IP addresses. \subsubsection{Deferred Threats for Future Improvements} \textbf{Malicious senders or receivers of Zcash:} Senders or receivers of Zcash can act honestly within the protocol but maliciously outside of the protocol (such as creating a ``honeypot'' for which Zcash users are tricked into sending valid transactions to). Such an attack would require the malicious receiver (or sender) to deanonymize the sender by one of the following methods: \begin{enumerate} \item Gaining identifiable information from the transaction itself. \item Using known network analysis methods to trace a transaction back to its source. \item Operating a node used as an entry point (such as a light wallet). \end{enumerate} While preventing malicious senders or receivers of Zcash from compromising the other part is certainly within the threat model of Zcash, we defer addressing this category of threats for future improvements. \textbf{Learning the tuple (sender or receiver identity, transaction):} Note that a network observer can also gain a subset of sender/receiver linkability information by observing just a sender \emph{or} receiver's identity linked to a specific transaction. Note this information is more valuable in an unshielded setting, as learning the unshielded transaction can give the attacker useful information. However, learning this information in a shielded setting simply gives the attacker enough information to learn that they are sending a Zcash transaction, but no additional information. As such, we consider this a deferred threat that we can consider in the future. \textbf{Partitioning attacks:} The Zcash network itself could be partitioned, such that some nodes think they are aware of the entire network, but only instead be aware of a small subset of nodes. Such attacks could be performed by DNS seeders (again, by lying about the state of the network), or even by highly-connected nodes. Such attacks are well-known in the literature and in practice and demonstrated to be practical for small-scale networks without a centralized mechanism for distribution about network state. However, we defer this threat for future improvements, as it requires designing a fully-decentralized but fully consistent network information distribution mechanism. \subsubsection{Out of Scope} \label{out-of-scope} \textbf{Unforeseen software flaws:} While our team at the Zcash Foundation works diligently to prevent software bugs and vulnerabilities to the best of our ability, we do not consider such flaws in scope, as such cases are unforeseen and we cannot rule them out completely. As such, when we become aware of vulnerabilities or flaws, we will fix them, but we cannot claim such occurrences will not occur in the future. \textbf{User behavior Outside of the Zcash protocol:} Zcash is not used in a vacuum; spending and receiving Zcash is linked to real-world value. As such, we do not consider user behavior outside of the Zcash protocol to be in scope, even if that behavior results in spending or receiving Zcash. For example, someone who goes to a website and wishes to purchase an item in Zcash may be unlinkable purely when observing the Zcash network, but their behavior when browsing the website can still be observable to a network attacker. In order to spend Zcash in a \emph{truly} private way, the user must use another privacy-preserving technology to hide their spending behavior outside of Zcash, such as accessing that website over Tor. \textbf{Sybil attacks:} In small decentralized networks, adversaries can control a larger percentage of the total network and consequently gain more advantage over collective network functions. However, we do not consider such attacks as in scope to our assessment; we assume an adversary with sufficiently limited resources as to require participation akin to honest users. \subsection{Attacks Less Applicable to Shielded Transactions} \textbf{Epistemic attacks:} A network observer could perform an epistemic attack by observing unique routing information that allows for eventual deanonymization of that user. Again, such attacks are possible in Zcash because users do not control routing information for their transaction. One example of epistemic attacks against cryptocurrency networks involve the probability of ``super-connected'' nodes that can link the node from which a transaction originated~\cite{dandelion, fanti2018dandelion}. However, in the case of a blockchain, all transactions are first synced to the blockchain (and become part of the global state of the network) before the receiver can learn the transaction. Hence, an adversary will not be able to learn the sender, receiver, transaction tuple simply by passively observing network traffic (unless the receiver is using a light wallet, and this query is made in the clear). \textbf{End-to-end timing fingerprinting attacks:} While an adversary can perform timing fingerprinting attacks on the sender of a transaction, the adversary still must be able to correlate this information to the receiver of the transaction in order to learn the full tuple of value. However, again, deanonymizing the receiver is possible \emph{only} in the light wallet setting when shielded transactions are used, as otherwise the receiving protocol is a full broadcast protocol. While light wallets could attempt to perform end-to-end timing attacks to link the sender and receiver of a transaction, we consider such attacks out of scope considering the latency and batching that is added in the time required for a transaction to be included into the blockchain, as further described in Section~\ref{observations}. \textbf{End-to-end behavior fingerprinting attacks:} Fingerprinting user behavior such as the frequency and number of transactions made could in theory allow for end-to-end linkability of senders and receivers in the setting where light wallets are used. For example, a malicious light wallet node could observe the frequency and pattern of a user’s transactions, and build a pattern to match against over time. However, as described in Section~\ref{observations}, it is unclear how end-to-end behavior correlation could occur in practice, even if an adversary has a complete view of the network, as all transactions must first be published to the blockchain before a receiver can receive the funds. At minimum, a transaction will have the anonymity set of the size of one block, but this assumes a transaction is immediately synced to the blockchain. In reality, ordering is not preserved for transactions included in the blockchain relative to when they were published to the network, due to proof of work requirements or variances in network topologies. \section{Review of Network Privacy Approaches} \label{network-privacy-review} Ideally, some of the attacks described in Section~\ref{attack-vectors} could be mitigated by using a network privacy layer. We now review three classes of network privacy approaches, and then in Section~\ref{network-privacy-assessment}, determine how these approaches address the existing described attacks against Zcash. For brevity, we only review Dandelion~\cite{Fanti:2018:DLC,BojjaVenkatakrishnan:2017:DRB}, Tor~\cite{tor-specification}, and general-purpose Loopix-based mixnets~\cite{Piotrowska:2017:LAS}. Further, we review private information retrieval (PIR) as a method which can be used in conjunction with the above systems. \subsection{Dandelion.} Dandelion~\cite{BojjaVenkatakrishnan:2017:DRB} and Dandelion++~\cite{Fanti:2018:DLC} is a lightweight gossip protocol aimed at adding additional network privacy for distributed networks such as cryptocurrencies. Dandelion protects against \emph{passive} deanonymization attacks, but does not consider active or targeted attacks. Such passive deanonymization attacks could be conducted by a ``super node'' that has a high degree of connections to other nodes (and could either be a single node or a botnet where adversarial machines share information). As such, it is assumed that this adversary is honest-but-curious, following the gossip protocol but wishes to learn as much information about users as it can directly observe. However, Dandelion++ does consider a stronger adversarial model where nodes are allowed an arbitrarily-number of connections to other nodes (acting outside of the Bitcoin gossip spec which only allows 8). Both Dandelion variants follow a randomized design for how transactions are gossiped to the network, differing from the Bitcoin design where nodes publish transactions as widely as possible as quickly as possible. In the Dandelion design, whenever a node receives a transaction from a neighbor, it first flips a coin to determine if the traffic is sent to a single neighbor (constituting the ``stem'' phase) or to all the node's connections (constituting the ``fluff'' phase). Such an approach frustrates the ability for a super node to link a specific transaction to the node which originally published that transaction. \subsection{Tor.} \label{tor-intro} Tor~\cite{tor-specification} is an anonymity network that today has over 2.5 million users and a network size of over 6,500 nodes. Tor supports applications that require low latency, such as browsing the Internet anonymously or streaming videos. In order to support such a use case, Tor assumes that it is hard for network adversaries to gain an end-to-end view and provide correlation attacks, such as by injecting timing or dropping packets to test if the traffic it can view entering the network is the same as the traffic it can view leaving the network. Tor distributes its routing information (i.e, information about each relay) via an authenticated document called the \emph{consensus}, which is signed by a threshold number of trusted servers called \emph{directory authorities}. In doing so, Tor ensures that all clients and relays have a consistent view of the network. By distributing a global authenticated document to all network participants, Tor avoids epistemic or routing attacks unlike completely decentralized networks which cannot guarantee a user or relay's view of the network is authentic or that all users fall within a global anonymity set. In Zcash, Tor integration can be implemented at several points: between senders and the Zcash network, between Zcash peers, or between receivers and the Zcash network. Because our focus is on preventing \emph{end-to-end} correlation attacks, we focus our attention on integrating Tor to submit and receive transactions only. While integrating Tor between Zcash peers could have some utility, as demonstrated by our analysis, this protection can easily be circumvented by malicious peers handling entry/exit traffic to the network. \subsection{Loopix-based Mixnets.} While a range of mix network designs have been introduced in the literature, in this assessment we consider only those which instantiate the Loopix~\cite{Piotrowska:2017:LAS} design, which provides improved latency guarantees over prior designs. Similar to other mix network designs, Loopix uses dummy packets and message delays in order to protect against adversaries performing fingerprinting and end-to-end attacks of user traffic. While Loopix specifies how messages are routed through a network, Loopix-based networks still require safely distributing network information to users and nodes. As one example, Katzenpost~\cite{katzenpost}, a mix network which implemented Loopix, used a similar model to Tor by leveraging trusted network authorities to sign and distribute the state of the network. However, alternative network distribution mechanisms can be used, but similarly may be subject to epistemic and path-routing attacks similar to other distributed networks. \subsection{Private Information Retrieval (PIR).} Even though the above network anonymity systems disassociate a sender or receiver's identity from the transaction, nodes can still observe which blocks are being fetched and perform fingerprinting attacks using this information. One mechanism that can be used in conjunction with network anonymity tools is private information retrieval (PIR)~\cite{pir}, which allows users to query information while preventing the service that hosts this information from learning the query. Note here we do not specify \emph{which} PIR design to use, we simply assume the properties of a PIR implementation, for which the content of the user's query is hidden from the service tasked with responding to that query. \section{Assessment of Network Privacy Approaches to Zcash Privacy (Assuming the Use of Shielded Transactions)} \label{network-privacy-assessment} We now review the extent to which Dandelion++, Tor, some generic PIR mechanism, and a \emph{general-purpose} Loopix-based mixnet protect against the existing network-based attacks against Zcash described in Section~\ref{threat-model}. Note again that we assume an attacker does not control either the sender or receiver of funds, and assume the attacker is limited in resources such that they cannot perform a Sybil attack. We summarize our results in Table~\ref{network-zcash-assessment}, but describe our findings here. \textbf{Assumptions.} We assume the mixnet is a separate anonymity network entirely, and is \emph{not} part of the cryptocurrency network itself (meaning that the initiator of a transaction forwards this transaction through the mixnet first before it is published to the cryptocurrency network). We assume that the PIR mechanism is used by the user to look up transactions in such a way that the node serving that transaction cannot infer the contents of the user's query. \begin{table}[t] \caption{Effectiveness of network privacy mechanisms for Zcash security and privacy, assuming the use of shielded transactions} \label{network-zcash-assessment} \footnotesize \CIRCLE=protects against; \Circle=does not protect against; $\bigstar$=Not a threat in this setting; Mixnet=General-purpose Loopix-based routing tuned for lower-latency applications such as messaging or web-application traffic. DoS=Denial of Service; On-Path Correlation=End to end correlation attacks where one node in the path is participating in the attack. \medskip \begin{tabular}{ p{4.5em}| c | c | c | c | c | c | c} & & & & & \multicolumn{3}{c}{PIR} \\ & Attack & Dandelion++ & Tor & Mixnet & Only PIR & Tor & Mixnet \\ \hline \multirow{2}{*}{Full Node} & DoS & \Circle & \Circle & \Circle & \Circle & \Circle & \Circle \\ & On-Path Correlation & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ \\ & Block Access Pattern & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ \\ \hline \multirow{2}{*}{Light Client} & DoS & \Circle & \Circle & \Circle & \Circle & \Circle & \Circle \\ & On-Path Correlation & \Circle & \CIRCLE & \CIRCLE & \Circle & \CIRCLE & \CIRCLE \\ & Block Access Pattern & $\Circle$ & $\Circle$ & $\Circle$ & $\CIRCLE$ & $\CIRCLE$ & $\CIRCLE$ \\ \end{tabular} \end{table} \subsection{Analysis for Use of Full Nodes} \textbf{Dandelion++.} In the full node setting when shielded transactions are used, Dandelion++ does not meaningfully change privacy guarantees for users, as Dandelion++ provides privacy in the setting of a super node with knowledge of the network graph. In other words, knowledge of the originating node when using shielded transactions does not result in a meaningful information leak without additional knowledge of the receiver. Further, the protocol does not add any protection against denial of service attacks or the ability for nodes to observe block access patterns. \textbf{Tor.} As previously discussed, in the setting where full nodes are used, the receiver cannot be linked to a specific transaction, unless the receiver themselves is malicious and colludes with other parties. As such, the use of Tor does does not meaningfully change user privacy. \textbf{General-Purpose Mixnet.} While the use of a general-purpose mixnet raises the cost to an adversary to conduct fingerprinting attacks that could result in end-to-end linking of senders and receivers, this protection does not meaningfully increase user security in the full node setting. Most specifically, because receivers operate in a full-broadcast mode, end-to-end linking of senders and receivers is not possible when full nodes are used, unless the receiver themselves is compromised or malicious. \textbf{Only PIR.} Because the receiver in a full node setting receives all transactions, use of PIR does not add any additional meaningful protections when shielded transactions are used. This is because the receiver has the full set of transactions themselves and consequently will not expose a specific query to any external party. \textbf{Tor + PIR.} Because receivers of Zcash when using a full node operate in full broadcast receiver mode---meaning that the user does not leak which transaction they are interested in---use of PIR in this setting does not meaningfully add privacy or security protections. \textbf{General-Purpose Mixnet + PIR.} Again, because users operate with full nodes, even though the sender's identity is hidden and so are any timing or behavior leaks, use of mixnets with PIR does not add meaningful security when shielded transaction are used. \subsection{Analysis for Use of Light Wallets} \textbf{Dandelion++.} Similarly to the analysis for use of useful in a non-shielded context, Dandelion++ does not protect against end-to-end correlation attacks in the setting where light wallets are used. Specifically, while Dandelion++ protects against super nodes that can observe in-network gossip messages, Dandelion++ does not provide ``last-mile'' privacy, meaning that users can still be deanonymized by the light wallets they use. \textbf{Tor.} Tor protects against a light wallet directly distinguishing between receivers in a light wallet setting, as the light wallet will not be able to learn the network identity (IP address) of a receiver. Because Tor is a low-latency network, even if the receiver IP address is hidden from the light wallet, the light wallet or a network observer can still observe the user's timing and behavior when fetching transaction details. However, because a user's transaction is published to the Zcash network, and then published as the next block in the Zcash blockchain with a series of other transactions, it is unclear how much of an advantage an adversary has to perform end-to-end timing-based attacks in this setting (as further discussed in Section~\ref{observations}). Typically end-to-end timing attacks require performing packet correlation on the order of seconds, whereas the latency in a network like Zcash is on the order of minutes. As such, we deem timing-based attacks to be not applicable even when light wallets are used for Zcash. However, the light wallet can still observe which queries a receiver wishes to fetch, even if the light wallet cannot observe that receiver's network identity. Hence, we do not grant the property of protecting against block access patterns from receiver queries. \textbf{General-Purpose Mixnet.} Because blockchains require publishing transactions to a global immutable data store (the blockchain), the property of mixnets to inject dummy packets to help discourage end-to-end packet correlation in a web traffic setting is less relevant in a blockchain setting. Further, as described in Section~\ref{observations}, the ability of an adversary to use timing of transactions to infer information about the sender, receiver, and contents is less relevant in a blockchain setting due to the inherent latency incurred when publishing a transaction. While mixnets do hide timing information for packets by delaying messages sent through the mix network, in general-purpose mixnets that are tuned for web or messaging application traffic, such delays are on the order of seconds or even microseconds, where as we observed above, the Zcash network itself imposes delays on the order of minutes as transactions are added to the Zcash blockchain. Performing an end-to-end correlation attack simply by observing the endpoints (nodes servicing the sender or receiver of the transaction) will have difficulty performing such a timing correlation even in Zcash today. Similarly to the description of Tor above, a light wallet can observe which queries a receiver wishes to fetch, and so a malicious light wallet could use additional information to perform linking attacks. Hence, we do not grant the property of protecting against block access patterns. \textbf{Only PIR.} PIR in the setting of Zcash ensures that a receiver can hide which transaction they are interested in learning. However, a malicious on-path light wallet could still perform end-to-end correlation attacks by observing the sender and receiver's identities, as well as link the sender to a specific transaction. Hence, we do not grant full protection against on-path correlation attacks when only PIR is used. However, we do grant protection against the light wallet observing block access patterns due to the use of PIR. \textbf{Tor + PIR.} In the setting where senders and receivers use Tor along with PIR, we grant a full circle for protection against on-path correlation attacks. While nodes can learn that \emph{someone} is sending and receiving a transaction, nodes cannot learn either \emph{which} transaction, \emph{nor} who the sender or receiver are. Again, block access patterns are protected against due to the use of PIR. \textbf{General-Purpose Mixnet + PIR.} We grant a full circle for protection against on-path correlation attacks when a mixnet used in conjunction with PIR, as the use of PIR should only increase protection to users. Finally, block access patterns are protected against similarly to in the Tor + PIR case. \section{Future Improvements for Zcash Network Privacy} \label{future-improvements} \subsection{Network Privacy Improvements for Unshielded Transactions} While the end goal for Zcash is to move all users to use shielded transactions, the reality today is that only a very small percentage of Zcash is transacted using shielded transactions. In the interim to achieving the goal of ubiquitous shielded transactions, we can take intermediate steps to improve the privacy for Zcash users in the unshielded setting. With that said, incorporating a variant of the Dandelion++ gossip protocol is a lightweight and immediate first step to improving the privacy of unshielded transaction. However, we recognize that stronger protections are required in following steps to provide stronger security and privacy guarantees. \subsection{Network Privacy Improvements for Shielded Transactions} In looking at Table~\ref{network-zcash-assessment}, the strongest protections are offered by the combination of PIR along with a network anonymity tool such as Tor or a mixnet between senders and receivers and the edges of the Zcash network. Because use of an anonymity network protects against directly leaking the network identity of a user, and PIR protects against disclosing the contents of a user's query, the combination of these methods leaves little room for an attacker to gain advantage. While typically the ability for mixnets to offer protection against timing or behavior fingerprinting attacks is desirable, in the setting where shielded transactions are used along with PIR for receiver queries, this advantage becomes minimal as mixnets tuned for general application traffic (such as web traffic) will not meaningfully increase end-to-end latency beyond that already induced by the blockchain itself. Again, this observation requires that the receiver can hide the contents of their query. As such, our immediate-term plan to proceed with Tor integration to facilitate sending and receiving transactions over Tor, and will assess PIR to improve receiver query privacy as a second step. We will continue to observe the development of production-ready mixnets as a possible option in the future, with an eye towards large-scale adoption in order to ensure sufficiently large anonymity sets for users. As discussed in Section~\ref{tor-intro}, sending Peer-to-Peer traffic between Zcash nodes may frustrate some attackers' ability to perform end-to-end correlation attacks, but has no effect on other adversaries such as malicious light wallets. As such, we deem integrating Tor in the P2P gossip protocol for Zcash as low priority. \section{Conclusion} \label{conclusion} In this technical report, we sketched out a more formalized assessment for the network privacy of users of Zcash, and identified how this threat model differs between a setting where users exchange shielded versus unshielded transactions. We then assessed the extent to which well-known network anonymity tools improve protections for Zcash users in the setting where \emph{shielded} transactions are used. Finally, we described next steps to improve user privacy in both a shielded and unshielded setting, starting with lightweight improvements to further longer-term structural changes. \section{Acknowledgements} We would like to thank Holmes Wilson from Zbay for his insightful discussion and feedback on this technical report. \bibliographystyle{plain} \bibliography{network-privacy} \end{document}