Is Zcash actually quantum private?

[Zchurn]

Hi,

First I want to express my admiration for the Zcash team (big fan of @daira especially!).

I’ve been studying the anonymity and privacy aspects of Zcash in detail. I apologise as I’m not a cryptography pro, I’m just a really serious user trying to understand it as well as I can. My goal is to be post-quantum private, i.e. not have my transactions publicly traceable or linkable by a quantum computer, based on what we know so far about QC.

If you do it right, Zcash appears to be by far the most private/anonymous cryptocurrency. Way superior to Monero, though I think using both in tandem is smart for current-day OPSEC. (Take advantage of the far bigger anonymity set of Monero in terms of physical transaction traffic per day, to increase resistance to timing analysis attacks, but still use Zcash’s post-quantum zk-SNARK privacy mechanism as the final layer). After much research, I learned Monero is a sitting duck waiting to be completely stripped naked by a quantum computer, probably in our lifetime. Monero feels like a religion, and Zcash closer to science. Smart to exploit both.

Zcash has so much potential, thank you for the upcoming Halo2 improvements like trust-free setup and reference wallets defaulting to shielded tx by default. I understand your adoption incentives to include AML compliance capability, and that’s OK if it’s transparently and solely in the control of end users.

I know perfection doesn’t exist - human-level factors are the final frontier of any OPSEC - but we need better clarification on Zcash’s technical post quantum privacy, and there are alarming observations about it (if @str4d is right in this thread, which would mean @Daira and @Zooko have been wrong in their statements), indicating that fully shielded Zcash is absolutely not (currently) quantum private, because only 1 of the big 3 identifying components of all shielded transactions is so (the sender address).

This is long post so I thought to make this an OP for easier accessibility. Please merge into other thread if you prefer that.

There are contradictions from members of the Zcash team that need clearing up. Comments saying that fully shielded ZEC is inherently quantum private:

• @daira, Mar 2016: [A future] quantum attacker could ... [on the current Zcash protocol blockchain] break the Curve25519-based encryption **(for known addresses)** and obtain past transaction metadata - my emphasis added - is Daira indicating that if shielded addresses are not known, the Curve25519 isn’t vulnerable or relevant to QC attacking? And in same GitHub issue, as indicated by this other discussion, Daira’s further words: I'd like to reiterate that Zcash as it stands, already is conjectured to be post-quantum forward private **when addresses are kept secret**. (emphasis added)

• @daira, Apr 2017: The overall encryption scheme is post-quantum key-private (Apologies if I’m taking that out of context) but what gives me hope: If the KDF hides its unknown inputs, then it doesn't reveal any useful information about which pk_enc has been used Also see 2019 Daira: Include argument about post-quantum privacy for unknown addresses in the spec · Issue #203 · zcash/zips · GitHub

• @str4d, Oct 2018: They can’t arbitrarily decrypt transactions on the block chain, because what they actually need to do is break the Diffie-Hellman part of the output key derivation, which requires either knowing the address and recovering the private part of the ephemeral public key in each transaction (to then compute DH(pk_d, esk)), or recovering the incoming viewing key from the address (to then compute DH(epk, ivk)). - Is str4d saying that, no matter the type of brute-forcing adversary (quantum or not), the actual, correct ivk correlating to what took place in a transaction can only be derived (AND proved to be such), if the attacker first knows the correct, real zaddr? That would corroborate Daira and Zooko above.

• @daira, Sep 2019: pk_enc varies between diversified addresses for the same ivk [etc.] - is there deniability and not absolute discoverability of original note value / memo contents / recipient address, based on ivk discovery? (It’s extremely low chance if QC stumbles on the actual original values that correspond to the ivk?)

• @daira, Jan 2019: hard to understand but I think it’s Daira showing how the overall encryption scheme is post-quantum key-private after all?

• @daira, Jan 2019: Daira seems sure

• @zooko, Aug 2021: tentative consensus with Daira’s long-standing claims

All the above is contradicted by this very specific comment from @str4d (my emphasis added):

For an unknown payment address, it would naively require 2^88 work to figure out which diversified base ( g_d ) is the one used by a specific note

Based on some brief Internet searching of “google’s quantum computer”, 2^88 (ops per second?) seems not much work at all for an attacker - very quantum vulnerable given the progress being made in QC. Maybe I’m wrong about how many physical qubits are actually needed, but Google’s existing quantum computer has 72 physical qubits - I see that 72 qubit QC means 2^72 values at once. (Per second?) So this means Goog’s QC can already crack any shielded ZEC tx’s recipient address, output value, or memo, in just 18 hours (2^88/2^72/60/60)? Hardly the future, this is today.

Perhaps I’m confusing physical qubits with logical qubits, but clearly QC is quickly evolving: IBM now has 127-qubit computer: First quantum computer to pack 100 qubits enters crowded race. Let’s say there’s 1 million shielded ZEC transactions in the pools. It only takes 4 minutes for a 100-qubit computer to unmask the entire Zcash shielded pools’ output amounts, recipient addresses, and any actual memos inputted into the memo fields (1,000,000*2^88/2^100/60 = 4.07). Or if there’s a second extra step to do, or a third, or six more, you sill get the point: it’s only another 4 mins of crunching on top of that. 1000 qubit QCs are planned in next few years. Maybe we should even be scared about AES-256, they say it only needs a million physical qubits to crack it. 1000 x 1000 doesn’t seem too far.

(Indeed, an existing classical supercomputer right now can already do 537 petaFLOPs, i.e. 537 quadrillion ops per second. To perform 2^88 ops only takes 18 years. (2^88/(537*10^15)/60/60/24/365) ) Shouldn’t key lengths be longer in any case? But because of current QCs like IBM, I am very, very concerned if my calculation assumptions above are correct.

Output values alone (and I assume ‘action’ values in Orchard) being unmaskable by an existing QC is a major and retroactive deanonymisation of Sprout and Sapling (and I assume Orchard) shielded pools. Not only can analysis map out plausible links between many or most transactions in general, but transactions early on in a shielded pool’s launch are especially linkable, even more so than just from the fact that not many transactions will have happened in time yet. If str4d is right, we already have amounts known to powerful adversaries. Can’t we already buy quantum computes on the cloud? When will Chainalysis do that?

So this matter is really important to get to the bottom of. Can Daira and str4d clarify? Even in 2017 @str4d seemed to be disagreeing with @daira about ZEC’s inherent PQ privacy. Who’s correct? QCs are here already.

Also: no amount of off-chain / out-of-band / inherently quantum-secure note transferring (1, 2) would improve PQ anonymity/untraceability, in fact it would probably make it worse. Such modified transactions would stand out from all other (regular) tx unmasked by a QC, and thus be highly linkable. They might be extremely private in terms of having certain impenetrable, quantum-resistant ciphertexts (which is cool for certain uses - likewise one could AES-256 pre-encrypt the text placed inside a ZEC memo - fun and cool!), but unless many people are doing similar modified note tx’ing, and in the exact same way, unlinkability/financial privacy relating to those transactions/zaddrs is severely reduced. No one should trust a potential anonymity set whose size they can’t verify.

At least we can publicly see how big the fully shielded ZEC pool currently is (casually check at https://zcha.in/statistics/usage). It’s about 100 per day right now. I can live with that using certain Zcash churning practices, even with a future quantum unmasking of receiver addresses and note output/action values.

But I hope we don’t have to do that! So clarification is appreciated, please. Thank you for your time.

PS. if str4d is right, then why isn’t the sender address/input note also vulnerable to quantum extraction (or indeed other non-zk-hashed values)?

PPS. do these findings show that some aspects should be tightened generally, and quantum privacy/security should be strongly prioritised for the next version, given the advancement of QC? Zcash should lead the way (QRL seems not to have enough support), it would make waves in crypto world and build on the trustless fix with Halo2. I want to see many move from Monero to Zcash in next two years. The long journey pays off!

[secured2k]

This was a long post and I did not read through all of it.

This has been a looming concern in general because with storage and public blockchain data, 20 years in the future is still within a reasonable lifetime for a quantum computer to be created to expose data stored from the past.

Short answer to the subject: Possibly yes if an attacker was not able to see the private address (zs1…). Probably no, (not quantum safe) until key exchange mechanisms are replaced with something quantum resistant like Crystals kyber and dilithium. I believe Some devs also looked as NTRU based on some other companies’ tests (Google, CloudFlare, TLS 1.3).

These are still new and not finalized as standards. This should be coming next year (NIST goals). When this happens we can probably see work toward a hybrid or a future upgrade to PQ attack resistance.

I have not reviewed the current zcash papers enough to determine if there is any need or possibility of retroactive protection for the current on chain transactions.

[Zchurn]

I mean, there’s probably better ways to launder money than Zcash - if you want to commit a crime of anonymity, the easiest way to do it is commit an existing crime as the context. (E.g. for IP address anonymity, hack into someone else’s network and use their IP address, don’t use Tor. Want to make your car anonymous on CCTV? Steal a car, don’t exhaustively apply OPSEC the legal way.)

Nonetheless, anonymity tools like Zcash and Tor should be as bullet-proof as possible, due to diverse safety needs of its global users. (Ultimately we make these tools to help the little guy.)

(The cost of powerful AND convenient security is the ability for it to be abused. At least it’s difficult to do with highest anonymity, so hopefully that deters most criminals who prioritise efficiency - and yet, our methods are legal! That’s the cypherpunk way, and it’s fun. *Waves to Zooko*)

We should know the answer to this question for certain. Hope devs can chime in and reach a consensus.

[str4d]

@Zchurn

Based on some brief Internet searching of “google’s quantum computer”, 2^88 (ops per second?) seems not much work at all for an attacker - very quantum vulnerable given the progress being made in QC. Maybe I’m wrong about how many physical qubits are actually needed, but Google’s existing quantum computer has 72 physical qubits - I see that 72 qubit QC means 2^72 values at once. (Per second?) So this means Goog’s QC can already crack any shielded ZEC tx’s recipient address, output value, or memo, in just 18 hours (2^88/2^72/60/60)? Hardly the future, this is today.

Side-note: what I meant by 2^{88} work is 2^{88} discrete-log-breaking quantum operations, not 2^{88} classical operations. The qubits in that scenario are already “in use” finding s given P and B such that P = [s] B. As I estimated further down in the thread you reference:

@str4d

If we very generously assume that each “core” / thread / whatever of a quantum adversary could break a single discrete log every 1ns, you’d be looking at around 2^{32} core years to have a 50% chance of finding the ivk for a single address.

That being said:

@Zchurn

All the above is contradicted by this very specific comment from @str4d (my emphasis added):

For an unknown payment address , it would naively require 2^88 work to figure out which diversified base ( g_d ) is the one used by a specific note

@daira and I went back and stared at my comment, and I cannot reproduce my thought process I think when writing my comment I believed that the adversary could figure out ivk from the on-chain data in 2^{88} work, but I now cannot see any pathway via which they could achieve this.

The adversary can take epk from each output and guess esk, landing on the correct one with 2^{88} work. However, they can’t do anything with this information, because without knowledge of pk_d they can’t derive the shared secret in order to confirm their guess against the note ciphertext.

So what can a quantum adversary obtain? Here’s what @daira and I sketched out (these are rough notes, and the “better than” section is my own):

Scenario

Let’s assume we have:

• An efficient discrete-log-breaking adversary (quantum or otherwise).
• Full history of the Zcash block chain (the block data).
• No knowledge of any shielded addresses (other than those generated by the attacker).

This means the following information is available:

• Spends:
  • nf
  • The anchor, which limits the set of candidate outputs.
  • rk
  • spendAuthSig (I’m not sure what this could be used for)
• Outputs:
  • epk
  • cm*
  • encCiphertext, which can be used to test a candidate sharedSecret.
  • outCiphertext, which can be used to test a candidate ock.

The following information is available but useless:

• cv (these are Pedersen commitments, which are perfectly hiding).
• Proofs (we use proving systems with either perfect or statistical zero knowledge).

Quantum brute-force decryption

Given a target shielded output, we can guess ivk and then trial-decrypt with it, using the AEAD ciphertext as a confirmation. With Grover’s algorithm this requires around 2^{127} work.

Similarly, we can use Grover’s algorithm on ock. This requires 2^{128} work (because ock is a 256-bit binary value), but it might be more concretely efficient because trial decryption does not require performing a scalar mul (for KA.Agree). The actual confirmation would likely be:

• Perform a single ChaCha20 block to decrypt outCiphertext.
• Test if the candidate plaintext contains esk as a valid scalar and pk_d as a valid curve point.
• Check the Poly1305 MAC, which requires processing 4 16-byte Poly1305 blocks.

Neither of these is a “break”, because our claimed security level is 2^{125}.

Better than brute-force decryption

This is the scenario I was mistaken about in my earlier comment.

The adversary needs to obtain either ivk or ock more efficiently than brute force.

• ock can’t be improved upon, because it is derived from the 256-bit binary value ovk via a hash function, so our DL-breaking adversary has nothing to work with (and to my knowledge there are no known algorithms that give any quantum adversary an advantage for breaking symmetric primitives).
• ivk is used in the scalar multiplication pk_d = [ivk] g_d, where d, pk_d is the recipient’s address, and g_d is derived from d via a common public algorithm. The DL-breaking adversary doesn’t have the recipient address, and thus can’t recover ivk that way.
• ivk is derived from the full viewing key components (ak, nk) (and rivk in Orchard), so if the adversary could extract these components from the transaction, then they’ve learned the full viewing key and can trivially decrypt outputs. However:
  • ak is linked to rk via rk = [\alpha] ak = [\alpha \cdot ask] G, where G is the spending key base. The adversary knows rk and G, and so can learn rsk = \alpha \cdot ask. But \alpha is uniformly random, and acts as a blinding factor on ask; a specific rsk could correspond to any ask.
  • ak, nk, rivk, and \alpha are private inputs to the circuit, so cannot be extracted from the proof.

Linking outputs without decrypting

What if we weaken the adversary’s goal: now instead of being able to decrypt a shielded output, they only want to know if two shielded outputs were sent to the same address. The rough outline of the attack strategy is:

1. Take two epk values from on-chain outputs (epk_1 and epk_2).
2. Determine that they correspond to the same g_d (even if the precise base g_d is not learned).
3. As long as there are fewer than 2^{44} outputs on-chain, then with high probability, two outputs that correspond to the same g_d were sent to the same address.
   • This will always be the case for the current shielded protocols, as the note commitment trees limit each protocol to at most 2^{32}.

The question is whether we can build a successful gadget for step 2. I don’t know if this is possible, but it would maybe looks something like:

Pick an arbitary base g' (not necessarily a valid g_d) and use the DL-breaking adversary to find the discrete logs of epk_1 and epk_2 with respect to g' (say, a and b).

If the outputs were indeed sent to the same address, then g' = [k] g_d for some scalar k, and:

\begin{aligned} epk_1 = [a] g' = [a \cdot k] g_d = [esk_1] g_d \\ epk_2 = [b] g' = [b \cdot k] g_d = [esk_2] g_d \end{aligned}

The adversary can therefore cancel out k to get:

a \cdot b^{-1} = esk_1 \cdot esk_2^{-1}

If the outputs were not sent to the same address, then g' = [k_1] g_{d,1} = [k_2] g_{d,2} for some independent scalars (k_1, k_2), and:

\begin{aligned} epk_1 = [a] g' = [a \cdot k_1] g_{d,1} = [esk_1] g_{d,1} \\ epk_2 = [b] g' = [b \cdot k_2] g_{d,2} = [esk_2] g_{d,2} \end{aligned}

and the adversary would instead obtain:

a \cdot b^{-1} = esk_1 \cdot esk_2^{-1} \cdot k_1 \cdot k_2^{-1}

The problem now is figuring out what to do with this; esk values are uniformly random, as will be k_1 \cdot k_2^{-1}.

---

Anyway, that’s just some rough thoughts, but I hope it’s helpful!

[Zchurn]

Thanks @str4d for the transparency! AWESOME, man!

So I understand the above settled consensus to be: YES, fully shielded Zcash is quantum private against passive attacks (in terms of tx amount, sender or receiver), as long as no zaddr is known to the attacker. Excellent news. I can now proceed to launder billions in full quantum anonymity, then take over the world. (Just kidding… OR AM I?)

(As a lay internet searcher, I couldn’t easily figure out how many discrete logarithms current-day quantum computers are known to solve per second, based on no. of physical qubits. Bummer. Really wanted to know how capable a 1000-qubit computer is. But I won’t spend more time on it, because @str4d has confirmed above that indeed the no. of problems to brute force (classical or quantum) would be 2^125 or more, not 2^88, meaning much less of a likely concern.)

BTW: 1-million physical qubit computers (it seems 6.6 million is needed to crack AES-256) are projected to be built by IBM and Google by 2030. Frustrating. Imagine trying to do Zcash today with the intention for quantum anonymity in 40 years - we can try, but we just don’t know for sure. There seem too many unknowns to know if Google/IBM 2030 QC goals are realistic. (Error correction barriers, etc. - lots of tech seemed promising then didn’t pan out, or not for another 100 years, like electric vehicles.)

So I conclude that we just don’t know what the future brings and we can only do our best with technology we currently have. Anything could develop in a sudden exponential curve or breakthrough: an advent of new algorithms/mathematics to efficiently break even AES-256, e.g. after certain quantum / ‘AI’ developments after 2030, who knows? Luckily bigger problems will occur than Zcash being unmasked - the data leak chaos would be everywhere, perhaps unexpected social factors will negate the severity of unmasking if everyone’s private sh!t is also unmasked (and deniability can also increase after a long time has passed, and metadata attached to blockchain data more likely to be deleted that would otherwise make it worse - even NSA deletes data after certain time). Nonetheless, high profile blockchains are especially vulnerable as probably the most ‘undeletable’ files on the Internet. And many entities want to know your financial data. Non-digital protection measures should be implemented to mitigate possible future quantum decrypting. With such caution applied I wouldn’t be deterred from transacting millions of USD in Zcash, even with a serious threat model. After all, you have to use something.

---

Off-topic: if we wanted to donate to make Zcash more secure or to analyse it more thoroughly, I wonder what’s better money spent: 1. directly giving a large private grant to ECC (etc.) for the devs to do more work (expand the team and/or hours worked), or 2. directly fund world class public researchers to analyse Zcash as vigorously as a world class intelligence agency would in secret (with responsible disclosure etc.).

Perhaps the community should set up DAOs to fund such things, with specific goals in mind. E.g. 1. to move Zcash to zk-STARK (to make it quantum secure, not just private - fasttrack that goal), at the estimated cost of X mil. Or 2. to directly research all the unanswered questions in this thread, so everyone can hopefully know the answers as transparently as any state actor could.

DAOs could be revolutionary for crowdfunding cryptocurrency dev and security work. Perhaps there’s not enough demand for my example - not enough people are paranoid enough to care that maybe some government secretly knows certain Zcash vulnerabilities because not enough money has been spent on public Zcash research to match it) - in which case, I hope one day I can at least donate myself.

Thank you for the great work and decision-making thus far.

[zooko]

The main issue about retroactive protection from future attackers is just the difference between confidentiality (provided by encryption and by not necessarily posting your z-address to the public internet) and integrity (provided by digital signatures and/or zero-knowledge proofs).

If the threat from hypothetical future quantum computers is that they could forge your signature, then the solution is to have upgraded your tech and migrated your funds to the new signature+ZKP tech before then. If the threat is that they could retroactively decrypt transactions then the solution is to have used a quantum-computer-resistant encryption+confidentiality stack now. As far as I understand, Zcash is probably already fairly good on that second one.

[secured2k]

@Zchurn

IBM wants to break 1000 qubits within 2-3 years.

I wouldn’t get too frustrated with the system not lasting multiple lifetimes. As computing power grows, we can expect older encryption methods to no longer be sufficient. Just like DES/3DES eventually wasn’t strong enough, AES will eventually need to be replaced as technology advances. AES from 1998 eventually will be considered insecure and replaced with Quantum Resistant algorithms that are already in the works now. Right now, the accepted solution is to increase/double the key sizes for AES to extend its life.

If/When this becomes a problem, new encryption/authentication methods can be added and funds moved to a new pool that has those protections.

As for the donation idea, I would rather see something closer to #2 - because the work is something many projects and sectors have to work on for the future.

[kayabaNerve]

STARK R&D is something I’m personally incredibly interested in, and one of the reasons I wanted ZIP 1014 amended as described here: ZIP 1014-1: Proposed Amendment to the “MG Slice (Major Grants)” Section - #5 by kayabaNerve

ZK-STARKS, as of right now, doesn’t further Zcash because Zcash doesn’t use them. That said, I believe post-quantum privacy protocols undeniably benefits Zcash (even if it does also fall under the “furthering financial privacy” exception). I also believe there have been post-quantum SNARKS formed, yet I can’t claim to know nearly enough on how comprehensive they are (would they work for parameters akin to Sapling? How much worse would the performance be?).

As for knowing addresses being enough to break Zcash, I believe that should be assumed. While there is theoretical value in knowing the distinction, any nation state who has access to a quantum computer can easily access either historical traffic, public posts, or exchange records. The only possible advantage is the plausible deniability created if you immediately move the funds to an address only known to your local computer to break the trail (churning). That said, with HDKD, wouldn’t you need an entirely new seed for this to be successful? I don’t know enough about Zcash’s current HDKD scheme to comment, nor on quantum computing application to HDKD schemes.

If a donation pool was established to work on this, I would very much want to donate. I’d also love to see grant work on the topic proposed, though I’m not a member of ZOMG and may never be so that’s a moot point for right now

[Zchurn]

@kayabaNerve

The only possible advantage is the plausible deniability created if you immediately move the funds to an address only known to your local computer to break the trail (churning).

I have thought of this.

What’s left is the discoverability, by one or more other Zcash nodes, that the IP address your node uses (‘node’ meaning node-specific identifier(s) broadcast on the network I assume - nothing to do with zaddr) created a certain shielded transaction (which, if they don’t know a zaddr pertaining to that TX, they can’t glean anything extra than anyone else trying to analyse the blockchain - but they do have a new extra facet of IP address signature).

The source of this in official docs:

When you send a transaction, your node sends the transaction to other nodes that are part of the Zcash peer-to-peer network. By observing that your node was the first to broadcast the transaction, those nodes may learn that your node created the transaction. To prevent this, configure zcashd to use Tor.

If they continually collect this p2p off-chain data directly gleaned by their node(s), advanced Network Graph Analysis, correlating other non-Zcash data (IP address data) could over time perhaps link transactions. (E.g. via pattern of IP address - the fact that 23 of today’s 123 shielded ZEC TXs used a Tor IP is something that links those TXs together. But they would have to directly connect to enough nodes to scientifically make an accurate pattern analysis judgement. But it can be used as a mechanism to potentially link any two TX together in isolation if they are doing continual malicious Network Graph Analysis, and who knows how many others are using zcashd on Tor right now? Maybe it’s rather small number within the shielded ZEC pool at this point.)

Since doc uses plural (sends the transaction to other **nodes**), and it would make sense for efficiency to get TX confirmations as reasonably quickly possible, I assume zcashd by default tries to connect to multiple nodes (keeps directly connecting to more if you leave it running).

Two things I’ve concluded one can do to minimise this particular risk of malicious data collecting nodes:

• Like docs say, connect zcashd via Tor, it’s the best (publicly accessible) IP address anonymity set I’m aware of. (Arguably by this point, Zcash’s quantum anonymity is greater than Tor’s quantum anonymity, to a global passive adversary, who probably has their fingers all through Tor - that’s very impressive BTW, to say that something inherently gives (or can give) more anonymity than Tor itself possibly can. Tor is as quantum-weak as Monero. Zcash is a freak! May it gain more recognition.)

• Minimise this attack surface by turning off your zcashd node as soon as one confirmation is seen in your software. Untested by me yet, but I assume that one adjacent node usually will manage to propagate the transaction themselves without you needing to still be online. Just reconnect zcashd if after time no further confirmations were propagated.

Further things I will privately investigate for minimising zcash node surveillance:

• If there’s any cli argument to limit network connections to X nodes, e.g. only 1 at a time. (If not, one could code up a custom zcashd fork if they have the resources - this would be bit like third-party BitTorrent clients that work with the BitTorrent protocol but don’t follow the usual protocol-intended ‘rules’ (or guidelines) like seeding back and demanding / rewarding certain seeding / swarming behaviour - ‘leech clients’.) This idea is a little like a certain Tor feature BTC: most Tor client software is configured to have client stick to only ONE entry (guard) node (the most immediate node touching your naked IP address) and rarely cycling it, to decrease your probabilistic chances of having a malicious (spying) guard node for any given session.

• This should be obvious to any serious thinker: don’t use the exact same Tor exit node IP address for adjacent transactions. (Reduce linkability of multiple TXs you do to a mere pattern of ‘Tor IP address’, not the potentially unique linkability of ‘THIS specific Tor IP address’. Restart Tor daemon before the next TX, and more hardcore step, only use any zcashd node (broadcasting unique identifiers on the p2p network?) one time, for one transaction only (or two times, one in and one out - i.e. minimally). Appear as multiple people, not one person. Make your zcashd instances disposable. This only matters if you care about malicious Zcashd nodes surveilling by collecting this off-chain data.

• Also I wonder if cli allows an option to ONLY connect to one specific node on the network (specify it by hash etc)? Then you could run a second node yourself, which does the (first) confirmation then spreads it out to others, and which doesn’t collect your original transaction/IP linkage since it’s you performing that confirmation. (You can also run this second node on Tor. I assume Zcash protocol traffic is encrypted and not sniffable by malicious Tor exit nodes.) However, can other nodes probabistically guess that the second node is actually you (even if it’s not the node that created the TX), if you operate such ‘second nodes’ with a repeatable pattern over time (or via some other mechanism - e.g. does protocol announce which node identifiers created which numbered confirmation [which would be terrible for node privacy])? If attacker runs several/many nodes in the network, perhaps they can determine the likelihood a particular node is somehow closely / directly connected to the original transaction sender, because no other node is delivering it to their multiple nodes in real-time? I’ve not studied particulars of Zcash network protocol - is it similar to BitTorrent which makes it possible, via at least one real-time observational technique, for peers to know which specific peer was the original seeder, if they were there at the right time and logged it? (Mitigation perhaps, and not perfect: close off your second node as soon as THAT garners at least one confirmation from someone else. Make a ‘random’ third party node be ‘the source’ after that, which is neither you/your IP address signature pattern, nor the node noted as having created the TX, and will ‘randomly’ be a different node on the network to scramble the IP address signature as randomly as any other transaction already would be - it retains a ‘ghost’ source of the TX on the network, if no one ever saw who the original node was apart from you. But that assumes confirmations on the network don’t broadcast the ‘order’ of confirmers or something similar. (And not perfect mitigation because the ‘randomly’ used third node might still be a malicious collector, who is also operating other nodes watching to analyse Zcash network activity in real-time.) Are these exact details about off-chain real-time metadata documented anywhere, so we can learn how easily an attacker can track the source and flow of confirmations of a TX on the network in real-time? I think I read all of readthedocs; I have not thoroughly read the mighty protocol.pdf, but no instance of the word confirmation in there.) I feel like this advanced Network Graph Analysis security hasn’t been explored properly by public researchers. (I didn’t see a paper so far, unless I forgot.) This is why I mention peer fundraising for such stuff.

Hope someone benefits from me having thought through this OPSEC. I know these are hardcore measures, but some people may depend on them, such as a persecuted dissident in a brutal regime being paid online by an overseas employer with high privacy so they and their family can survive. Their children may want to stay disconnected from such Zcash transactions for the next 60 years, otherwise they are tortured and killed.

[kayabaNerve]

I’d be very interested in seeing adoption of Dandelion++ within Zcash as well. For now, a churn with a separate seed and Tor circuits…

[dontbeevil]

@Zchurn

Hope someone benefits from me having thought through this OPSEC. I know these are hardcore measures, but some people may depend on them, such as a persecuted dissident in a brutal regime being paid online by an overseas employer with high privacy so they and their family can survive. Their children may want to stay disconnected from such Zcash transactions for the next 60 years, otherwise they are tortured and killed.

Thank you for writing it up. There is lot of great information here, would you mind sharing them as tweet threads (quantum resistant & about churn)?

[Zchurn]

@dontbeevil

Thank you for writing it up. There is lot of great information here, would you mind sharing them as tweet threads (quantum resistant & about churn)?

Sadly I have no time to blog (even if someone paid me), at least I’m sharing here.

[secured2k]

I run a zcashd node with tor.

The current assumption is even if an entity was able to track broadcast transactions to the tor exit IP, it would be very difficult to find the true original source. Of course if tor was ever broken or the entity could see the whole tor network chain, then maybe it would be possible to link to the source.

I believe you are correct - a higher level anonymity would require new tor connections and routes to be created after each broadcast to randomize the connection more. I guess we could look for zcashd to receive instruction to broadcast a high-security z-z transaction and be told to execute a script instructing a system to use a new tor circuit and reconnect to a new random node, broadcast the transaction, and then do it again…

Zcashd does support limiting how many connections and which peers to connect to. This is in the zcashd.conf documentation.

I am not sure if Zcash has encrypted the broadcast transactions; I know that if they are or aren’t, the data is still protected by digital signatures. I have previously come to the conclusion that like many private messengers, the application helps with privacy, but not necessarily anonymity. There is a paper that talks about this here.

[Zchurn]

@secured2k

Zcashd does support limiting how many connections and which peers to connect to. This is in the zcashd.conf documentation.

Thanks, noted! So if there is a difference between a node seeing a transaction from the original source (looking for a ‘first confirmation’) vs. another just passing it along - if that’s how the protocol works - then using connect=X.X.X.X to use a specified, sort of second ‘guard node’ to protect a third party malicious node from sniffing your ownership ‘transaction originator node’ is how to plug that.

What then remains to be known by me, first is whether Zcash protocol has nodes tell other nodes whether they’re the ‘1st’, ‘2nd’, ‘3rd’ etc. node to have confirmed the transaction or not. Perhaps what you say below indicates that’s not the case - it’s just a hash once created by first ‘confirmer’ (for lack of better term), passed around to other ones in a way that doesn’t reveal who’s ‘first’, ‘second’, ‘third’ confirmer etc:

@secured2k

I am not sure if Zcash has encrypted the broadcast transactions; I know that if they are or aren’t, the data is still protected by digital signatures.

But secondly, even in that case, an attacker with enough malicious nodes recording the network in real-time could probably probabistically determine that your self-controlled second node is you, and thus your TX is still fingerprinted to ‘Tor IP zcashd node’ as a traceability vector.

Probably we have to accept this weakness and just do Tor circuit changing and existing OPSEC (like what I’ve shared such as scrambling and spacing out your timing, and the above idea I’ve notes to turn off all self controlled nodes ASAP once confirmed once) to be enough. We can’t do any better.

Final frontier to address leakage of IP address to well-resourced adversaries, as you say, seems to be mix networks:

@secured2k

There is a paper that talks about this here .

Sadly, implementations of mix networks have been around since at least the 90’s, but even Tor hasn’t implemented anything as anonymous as that. (Wonder if Loopix can change that?) Clearly not enough people have been unmasked by adversaries (yet) to demand such a mix network-operated coin exist. (Or a regular web browsing Tor replacement.) Maybe hardly anyone has been unmasked by Tor-level anonymity, so for now, other OPSEC mistakes or exploits are what undermine someone before their need for a mix network emerges.

Thanks for sharing!

[secured2k]

A very quick check of the source code indicates the node that gets the transaction checks validity and if valid, just forwards the transaction and not how many hops or other nodes have received the transaction into the mempool.

The steps you’ve outlined and as outlined by ECC for security considerations are correct - larger value stored in pool and send smaller amounts, spaced out timing for transactions, not sharing transaction details, and protecting IP addresses. Privacy Recommendations and Best Practices - Zcash

There is a project working on enhancing an onion routed network at the IP level called “Lokinet” that tries to avoid letting “global passive adversaries” take control of nodes because there can be high costs to run such nodes with risk of losing those funds if found to be misbehaving. It is far from ready for prime time and runs on privacy based blockchain technology (Oxen - originally forked from Monero).

[Zchurn]

@secured2k

A very quick check of the source code indicates the node that gets the transaction checks validity and if valid, just forwards the transaction and not how many hops or other nodes have received the transaction into the mempool.

Thanks for reporting that! And to corroborate: I found a 2019 paper that explores some of this network graph analysis category of attack:

1907.09755.pdf

It states e.g.: validation time seems to be a good indicator for the number of hops - but it’s close-range timing analysis only.

They don’t show a serious attack IMO - it’s only that a low-resourced attacker from anywhere in the network can map out chains between nodes for a given block/tx, to some extent, back through the chain from their own node(s), but with only “precision of 50%” - and not necessarily unmask which exact node originally created a block/tx (see below for my analysis).

But it made me realise the following:

Zcash’s privacy is not as strong as the quantum privacy of the blockchain graph data: it’s actually as weak as the monitorability of its real-time p2p network data. Obfuscation of a TX sender node’s IP address (as a significant fingerprinting or TX linkability vector) is more important than I thought. Under the current protocol design, if you want to take measures to achieve this, it’s currently doable (continue reading), but means longer confirmation times for your transactions.

In any case, I say it’s safest to always use stream isolated Tor IPs on your nodes - no other type of IP address can possibly be a more anonymous pattern of IP (as we don’t know what other people are using, whether it’s VPNs, university IPs, proxies, residential IPs, hacked IoT botnet IPs, or almost never any of the above), but we do know Tor is officially encouraged, built into the client as an easy setting, so that’s a known IP pattern to blend in with. (Perhaps non-Tor IPs for isolated churns/TXs/purchases have their place sometimes, if you only use such an IP fingerprint one time. But that opens can of other worms in OPSEC depending on your other Internet usage and your threat model, so in general I’d recommend only ever use Zcash on Tor.)

But I think my idea of using a second self controlled, exclusively connected ‘guard node’, which isn’t detectable as the original creator of your transaction, has benefit.

The paper’s core idea:

The [attack] is to infer the connection between two peers by monitoring when they emit inventory messages announcing new blocks.

Seems to me that no single node can necessarily connect to all other network nodes simultaneously.

So I’d suggest a serious user does this:

• First zcashd node (which creates the outgoing tx), use connect=x.x.x.x to only connect to your second node’s IP (guarantees absolute privacy of sender node’s IP address)
• Limit your second node to only connect to ONE other random third-party node on the network (I think do -maxconnections=1? not tested by me yet). This way, limits the chances of connecting to a malicious node to only 1 out of all peers, instead of much more.

Then - unless your second node is very unluckily connected to a malicious node - you can be a true ‘ninja’ on the network as a mystery sender. Who knows what precise node originally created that TX? Only your own second node can possibly know. After that, perhaps there’s enough deniability statistical improbability of source point to hide in the crowd. This especially helps to mitigate the fact there’s currently only ~100 fully shielded TXs to hide among per day right now. (Not many IPs to hide in - let alone other nodes using the same IP fingerprinting of Tor - so let’s not make it possible to be observed what IP we’re even using, when we send a TX. Feel’s kinda Zcash style anyway, right? )

Even if your guard node connects to an evil one, perhaps they aren’t connected in real-time to enough nodes in general to confidently conclude that your guard node is the ‘source’ of your transaction. They’d have to be operating many sinister nodes to map out everything in the brief moments while your TX is confirmed.

But: is it wasted effort to do this ‘second node’ thing? I’d need to study BTC’s technology more (upon which ZEC is based)…I see Zcash has inherited BitCoin’s ‘trickling’ feature to mitigate peer discovery of which node created a transaction, even if the transaction is brand new with 0 confirmations. But unless I know that by default Zcash is bullet-proof in making a sender node being 100% indistinguishable from a subsequent confirmer node, to a directly connected malicious peer, I’d stick with my idea, even though it’s extra work. At least it shields discoverability of sender node IP from the entire network.

Zooming out, alarmingly there were only estimated 300-something zcash nodes in 2019 by those researchers. Cant imagine it’d be above 500 now. Many large entities (corporate or government) could easily add at least that many evil nodes, to make it 50% likely you would connect to a malicious node. We’d need to watch out for this happening at all times, though it must be difficult to know for sure so true IP mixing and latency fuzzing would address that.

Solution for now: just keep using Zcash, thank you Edward Snowden for the continued shout-outs, please ECC continue to make Zcash more Monero-like (e.g. actually do a non-trusted setup for NU5), then more Monero Torheads will jump on board and make that anonymity set bigger. I’m just one of them.

[secured2k]

I believe Zcash aims for privacy and not anonymity.

To quote a Google web search answer to “anonymity vs privacy”…

Privacy is the ability to keep some things to yourself, regardless of their impact to society. … So privacy is a concept describing activities that you keep entirely to yourself, or to a limited group of people.

In contrast, anonymity is when you want people to see what you do, just not that it’s you doing it.

Zcash would say it is like HTTPS - That is once you establish a secure connection, seeing or modifying the contents is private. However, this doesn’t stop the ISP and server from seeing that there is a connection. But just because there is a connection, no one can tell if you are sending nothing or a large sum of coins. Hiding that connection would be more so about anonymity which is something sort of tacked on by using external methods like Tor.

Sure you can attempt to obfuscate your connection/broadcasts, but without Web 3.0 methods of decentralized network connections with privacy, it will be possible to eventually link a connection to the source with enough time and resources.

I think this complexity is beyond the scope of the Zcash project. Instead it can rely on other projects (Loki, Nym, etc) or methods to create more anonymity on the network layer. As for quantum security, this is still pending an adoption of quantum Key Exchange and Signatures, possibly in a future pool as Zooko previously mentioned.

I think as of Jan 2022, there were about 263 nodes and over 75K miners that I could be publicly counted. I would like to see a more accurate number if possible. Transactions are relatively low, but I expect that as Zcash is still not in the top mainstream and is used more of a store of value and investing than for multiple/quick transactions.

[Zchurn]

@secured2k

To quote a Google web search answer to “anonymity vs privacy”…

Yes the two are fundamentally different, and sometimes the symbiosis / clash between the two can be complex / frustrating (respectively).

What I think, based on what I’ve learned so far:

• The word ‘anonymity’ has a bad wrap. It’s associated with criminals, darknet markets, cybercrime, ‘hackers’, etc. (Thanks, media, for perpetuating those negative tropes, definitions, associations). The word ‘privacy’ is much less taboo, thus used more often, including when really they actually mean anonymity, or anonymity in equal measure. It’s proudly used with moral dignity by commercial VPNs and many businesses / orgs, who say it’s ‘a human right’. Not so much the ‘a-word’. This inequality of attitudes towards the two concepts might slowly change, e.g. increasing legal human rights in Europe of ‘anonymity’ just like ‘privacy’. ‘Anonymity rights’ NGOs might emerge in future, defending it and promoting why it’s important. (Tor certainly has found a voice for that message, and EFF - e.g. anonymity helps domestic violence victims, whistle-blowers, etc.)

• The way I see Zcash: it uses privacy as the mechanism by which to achieve anonymity (in addition to privacy). ‘Financial privacy’ on a blockchain means ‘anonymity’ of public transactions to an outside looker (or, even to who you’re transacting with, at the blockchain-level). Speaking to above point, there is unfortunate legal stigmatisation of ‘anonymity’ in the context of money. Anti-money laundering laws (AML) in certain jurisdictions literally outlaw obscuring the source of any money, even if the origin is legal.

Zcash has already implemented ways that allow a user to comply with AML (view keys, memos etc.), which I hope suffices on-ramp/off-ramp exchanges obsessed with risk. But to grow the user base, IMO, the feature of ‘anonymity’ should be openly promised by Zcash as a positive, and not necessarily illegal thing (for a user to do or the project to promote). Just market the ability to comply with AML as strongly as the selling point of anonymity.

Additionally, z.cash (and every official associated domain like this one) should offer .onion Tor hidden services to put its money where its mouth is. You’ve donated to Tor so far, I hope you can consider that too! Like getmonero.org

@secured2k

Transactions are relatively low, but I expect that as Zcash is still not in the top mainstream and is used more of a store of value and investing than for multiple/quick transactions.

I’m still a crypto newbie but looking at Zcash historical price graph vs. ones like BTC, it seems relatively stable over the years apart from a 2018 spike. Doesn’t that show it’s being used more as a regular transacting coin by a certain-sized base, not so much as a volatile investment coin (like BTC)? (Hopefully many of them doing it specifically for the financial privacy, whether perceived or real…) To me, the stable-ish price looks healthy, so I’m motivated to both use regularly for financial privacy and to hold funds in long-term.

(Note the subtle difference between investing in and storing money in Zcash? Maybe that’s a winning strategy for this coin. It’s a true digital cash - who wouldn’t feel safest storing most funds in this less volatile coin as if it’s their bank account, as separate from risk-bearing investment like BTC?)

---

I guess not many, if any, have explored advanced mitigation of surveillance nodes on the Zcash p2p network. I will implement what I thought of above in my OPSEC.

[owenj7920]

This is basically my personal opinion -
Supposing a quantum computer capable of factoring large public/private keypairs is built sometime in the future, would Zcash transactions be at risk of deanonymization through an adversary decrypting all the shielded transaction information?

I looked for information regarding how the data is encrypted on the zcash blockchain but found no exact details on the algorithm used. I assume it is some commonly used public/private key algorithm, which would make it quantum vulnerable. Is this the case?

The reason I’m concerned is that the blockchain is forever. It is easy to wave away concerns over quantum computers, as actually, useful quantum computers may be decades away. It is easy to just say “we’ll change the algorithm to a quantum secure one by then” and be done with it. Basically, I am a blockchain lover so I started reading and developing all the blockchain-related things alongside developing cloud erp adoption. And for concerns such as an adversary spending other peoples’ coins or minting fraudulent coins, this is a valid response. We don’t have to worry about that happening until someone actually builds a quantum computer.

But post-quantum deanonymization is something we have to worry about now. It would be possible for a government agency to store the blockchain until they develop a quantum computer, and then retroactively deanonymize everyone who has ever used Zcash (if Zcash’s anonymity is quantum vulnerable), as they have all the records of every transaction already stored, just waiting for the technology to come along to process it. Even if Zcash updates to use post-quantum crypto at some point in the future, all transactions made before that point will be vulnerable for all eternity.

Is Zcash’s anonymity quantum vulnerable? I’m not as worried about Zcash itself being quantum safe (as the possibility of a quantum computer equipped attacker minting new Zcash is something we don’t have to worry about until a quantum computer is actually developed that can factor keypairs), just the anonymity aspect of the information stored on the Zcash blockchain.

Lattice-based cryptography is the generic term for constructions of cryptographic primitives that involve lattices, either in the construction itself or in the security proof. Lattice-based constructions are currently important candidates for post-quantum cryptography. Unlike more widely used and known public-key schemes such as the RSA or Diffie-Hellman cryptosystems, which are easily attacked by a quantum computer, some lattice-based constructions appear to be resistant to attack by both classical and quantum computers. Furthermore, many lattice-based constructions are known to be secure under the assumption that certain well-studied computational lattice problems cannot be solved efficiently.

Hope this article will help you.

[secured2k]

Hi owenj7920. The Zcash protocol specification can be found here: https://zips.z.cash/protocol/protocol.pdf. It is updated regularly and very thorough/detailed.

The question comes down to if/when quantum computing can crack key exchange and signatures, are any shielded transactions with exposed transaction IDs, z-addrs, or viewing keys actually exposed or able to be compromised? Would this equate to the same transparency as t-addrs like t1PKBiv7mtzD9bNafYaqyxaENeiNDbpKxxQ - where all transactions and values are shown and potentially leaked? I guess a challenge for an attacker would be who owns the addresses. I assume it would eventually link to a regulated exchange unless someone used decentralized/anonymous exchanges.The attacker would know how much ZEC and when it was moving; possibly with enough resources and access could correlate a node and IP address that wasn’t tor’d.

Quantum computers already exist, but not large scale enough to crack existing cryptography. At this time, the underlying symmetric methods are still considered secure vs large quantum computers with the recommendation to double the key size to increase long term strength.

Since this crypto is so widely used everywhere, we can be assured there will be global news and alerts from pretty much every secure web site/bank/healthcare/government/cryptocurrency for users to take action when this becomes an issue.

Ignoring public t-transactions that can be seen anyway - Sapling and newer [Orchard]) should be secure against quantum attacks given the public key (z-addr) is not exposed. Since the block chain does not record or see these shielded addresses, public key exchange attacks are mitigated. However, if someone publicly posts their z-addr without taking additional “churn” steps, it might be possible to link/spend some transactions in the future if the cryptography methods are cracked.

ZIP-316 (Unified Addresses/Keys) isn’t here yet (until NU5) but it seems to move things in a better direction - requiring at least one private address by default and an algorithm to protect against key replacement. I’m not sure how much protection these new addresses provide (if any). They appear to be encoded with bech32[m]. From Bitcoin taproot discussions, they advice against address re-use (public key for the spend is broadcast in transaction), but ECC/Zcash official say it is safe to re-use Shielded addresses.

Since we can’t count on people keeping their z-addr’s secure, moving funds into a new pool (sending to a new address format that supports post quantum resistance) will be the recommended action; but we are far from that as official protocols and methods are being finalized (globally) and the timeline for a successful attack is expected to be 10-20+ years out.