Hello, Im looking to see and understand what Zcash does to prevent network analysis attacks when using shielded transactions. Is this an issue for Zcash? If someone monitors your IP during a shielded transaction, what can they see? Will zcash implement a second layer to further obfuscate traffic if this already isnt an option? Looking for topics surrounding this specific network attack against private zcash users. Any papers about this topic that have been posted would be greatly appreciated as well
3 Likes
Someone monitoring your IP can see everything going in and out of your router (your ISP sees pretty much everything), the information contained within a zksnark is shielded from all persons although they could possibly tell that you conducted a zcash transaction and possibly correlate in the upcoming block, but there’s no way of knowing if that actually occurred for sure (given the size of zcash blocks probably did) but no other information is revealed i.e amounts and addressess
The biggest potential for information leaks besides using transparent is deshielding which is sending from Z to T or T to Z which you should avoid if possible
Against an adversary like the NSA, forget it, they record ALL transmissions that move into, within or out of the US because they have unrestricted access to every carrier option (accept carrier pigeon! Lol)
Otherwise it’s just common sense, strong passwords, use Tor and VPNs, limit your networks access
(Packet Radio Systems can offer obfuscation once its far enough away to a degree but radio location services are actually really good and a general locale would be inescapable so I wouldn’t bet on it)
Caveat, transmitting encrypted information across amateur bands is illegal in the United States so would have to check on that
2 Likes
So even if Z-cash were to offer completely private transactions(I’m speaking about shielded transactions), on the network level there is still the issue of de-anonymizing a z-cash user. The amounts would remain private but useage of the currency could become known? Am I right in understanding this?
The solutions you mentioned are Tor and VPNs. Is there something being built to help further combat these issues?
Is Zcash or the Zcash community looking to build something that could further obfuscate traffic and possibly implement it at the protocol level? Would this even be possible to add to the protocol level?
Could BOLT be a potential solution for this type of attack?
The problem is signaling, whether broadcast or across the tubes a signal comes from you going to somewhere else, isp’s and radio relays take and resend
In all honesty carrier pigeon maybe, lay your own tubes, chain letters, what your asking is quite alot
You could post your signal through a high-powered laser at the moon and the receiver could pick that up ( the reflection), morse might work
This was just posted by Nathan in the community chat using mixnets:
1 Like
Thats really cool, it doesn’t satisfy what I mentioned (you still submit a signal to an isp) but now I wonder if thats beyond the scope of what he asked
Thanks for these thoughtful responses, I was looking for these kinds of thoughts/ideas. The mixnets seem very interesting
Havent you been able to do this all along? I know you can in bitcoin, I don’t see why it would be different for zec. The wallet software just needs to show the raw transaction data rather than send it straight to the network then the user could cut n paste the info into a webpage.
like this - Push Raw Bitcoin Hexadecimal Transaction | BlockCypher
I get what the paper is getting at with the t-z stuff, but that becomes a non issue with z-z and I still don’t see why publishing the raw transaction via a webserver using tor is any less secure than what the author is proposing. Especially if it is a .onion that is relaying the transactions. idk. maybe im missing something.
It just seems a wallet software issue mixed with user network privacy issue. They are just putting a tor like relay into their wallet/node. I personally think better informing people on how to maintain privacy or secrecy is vital and how to assess their risk model. that’s just me tho.
I think to my understanding is that timing attacks could still be an issue using tor as there isnt any time delays, and the centralized nature of the Directory authorities plays an issue. As with mixnets there are DHT’s that are decentralized as well as false data/timing delays that also is sent out. They are both viable options but mixnets seem to offer a better solution in this case for trying to achieve a better sense of anonymity.
Would love to hear criticism or thoughts on what I interpret it as.
1 Like
If you create the transaction off line, then logon to a Clearnet webpage using http (this is worst case) all that anyone looking at network traffic will see the tor exit node sending the transaction to the web page and the web page relaying the transaction. you could even just use the tor exit node to broadcast straight into the mempool. (but this is a little harder and you could mess up)
The only IP addresses revealed are the exit node and the relay website. So yes your packet can be seen and identified as a z-z transaction, but nothing else. so for z-z it fine. there would be no way to correlate your real world IP or identifying information with that transaction.
But mix nets do look interesting, but they just seem to do what tor is doing anyway from my initial reading, they just implement it slightly differently. One issue I can see unless it gets added to the core branch is you might not be able to find a node to rebroadcast. It does look reasonable though.
Thanks for starting this topic. its really interesting.
This is an interesting conversation. I am not very well-versed in networking, but I did wonder if Zcash shielded transactions could be traced using a timing analysis based using websites like this, since at least until recently it has been necessary to run a full node to complete shielded transactions, and the network is relatively small.
I imagine Tor/VPN are recommended for this reason, but it does make me wonder how vulnerable a user would be if they failed to use those layers of security.