The source project of this merge request has been removed.
Broadcast Transactions over Tor Hidden Service
Compare changes
vtnerd-tor-tx-broadcasting.md
0 → 100644
+ 78
− 0
Add support to Monero daemon for broadcasting new transactions received over RPC to privacy preserving p2p connections to conceal origin IP. This proposal will use Tor hidden services, but the implementation will be written such that additional anonymity networks (Kovri?) can be added in the future.
Tor can be used today via exit nodes. The issue is the potential for MitM attacks on the data, and blacklisting of the exiting nodes (to help facilitate surrounding node attacks). The recommendation is to use hidden service nodes, like Bitcoin. Users can already force traffic to Tor exit nodes through other techniques.
Lee Clagett (vtnerd) will be the sole implementer. I have experience contributing code to the Monero daemon, contributing to wallet implementions (simplewallet, mymonero), and vast protocol experience. I am also familiar with some of the literature on privacy networks (this should be obvious in the proposal section).
Sending transactions can be traced to their origin by ISPs, or other institutions that connect to many peers to trace the first appearance of a transaction. An entire project, Kovri, has been funded to help mitigate this issue. There are things to implement on the Monero side to make use of an anonymity network as well which will be completed with the Tor integration.
Provide a sock 4a client implementation. A standard library is less desirable - Tor has some extensions for DNS lookup that will be useful in the future. The delivery for this milestone will _not_ be the ability to force all connections to a specific proxy (that is possibly left for a future FFS). The added functionality of this milestone:
- Network isolation, so that peerlist sharing is only done within the same network type. IPv4/IPv6 peerlists are never shared over Tor and vice-versa. Any future anonymity networks (Kovri) will be isolated from all other networks too. In other words, peerlists through `--anonymizing-proxy tor,...` and `--anonymous-inbound tor,...` will be considered isolated from the others.
A well-known weakness of Tor is the lack of delay in data transmits. This has the side effect of leaking the timing of data transmits through the Tor network, and sometimes the size of a message being sent (if the link is often idle). This timing issue can result in the leaking of transaction origin purely by watching the timing and volume of traffic being sent over Tor. This is particularly problematic with Monero having a lower transaction volume than Bitcoin. This milestone will implement the following:
- "Whitening" of p2p connections through anonymity networks. Try to make data send in constant fixed chunked intervals. This will likely slow-down sending of transactions, but greatly increase privacy. A heavy amount of research will be required - communication via socks connection makes it difficult to control rate.
2. When transaction is received over non-privacy preserving connection, re-broadcast transaction to all other non-privacy preserving connections. Whitening prevents packet/size/timing analysis and not re-broadcasting over privacy leaks prevents leakage of source (through anonymity connection ... but still).
I will have to work with the Monero core team to set this up. This will be similar to the hard-coded seed/bootstrap nodes used for connecting to the Monero network for this first time. These will most likely not be operated by me. This will allow `--anonymizing-proxy` to work without specifying a Tor `--add-peer`.
Setting up a Tor hidden service will require manual configuration of Tor. A future FFS proposal can implement the Tor control connection protocol (like with Bitcoin). Additionally, this proposal will not provide support for completely hiding the usage of a Monero daemon, because that requires significant additional work to never make a connection outside of Tor.
\ No newline at end of file