joinmarket-clientserver icon indicating copy to clipboard operation
joinmarket-clientserver copied to clipboard

Use multiple tor streams / identities

Open MaxHillebrand opened this issue 4 years ago • 8 comments

It might be worth considering how the use of independent Tor circuits / streams / identities can improve the privacy of Joinmarket.

[I am not sure about the specifics of how Tor is used, and how it intermingles with IRC... So I'm sorry if this is a nonsensical idea.]

But I would guess, that if a new Tor identity is used for each round of CoinJoin, then the IRC server has less information than he otherwise would have. I'm not sure how outside how this affects outside observers of the Tor network traffic...

This came up in a cyberspace meetup with @AdamISZ.

MaxHillebrand avatar May 21 '20 21:05 MaxHillebrand

One thing you can already do is Tor stream isolation, use different Tor ports for each IRC server in configuration.

kristapsk avatar May 22 '20 09:05 kristapsk

I kept forgetting to make this point, but: bear in mind that a joinmarket actor (whether maker or taker) is connecting with a nym (a 'nick') which is derived from a hash of a pubkey (very similar to an onion address) and we enforce signing of all private messages (with counterparties) with that nick to allow redundancy across multiple message channels (otherwise identities could be spoofed, on another message channel, with replaying messages).

Switching the tor circuit would therefore make no sense without switching the nick; so I haven't thought this through, but I believe it means that such circuit switching during a bot lifetime would be unnecessary/make no sense.

Notice how it's different from a Wasabi type scenario: there there needs to be a nym/identity disconnection between the phases to achieve the specific goal of anonymity wrt server.

So possibly this just broadens out into the "why not use crypto to prevent even the taker from knowing the linkages" question, which crops up naturally, on occasion.

AdamISZ avatar May 28 '20 13:05 AdamISZ

Thanks for the clarification @AdamISZ.

Then it seems that this issue is out of scope, and can be closed imho, so please do if you agree.

MaxHillebrand avatar May 28 '20 19:05 MaxHillebrand

I think maybe it's best left open as a question - adding this feature may well be beneficial. It's just debatable what is needed and how beneficial it may be.

AdamISZ avatar May 28 '20 21:05 AdamISZ

I guess such things never hurt, even if they don't add much, but it's matter of priorities and somebody willing to implement them.

kristapsk avatar May 28 '20 21:05 kristapsk

Can't this just be taken care of in torrc ? Something like:

SocksPort 127.0.0.1:9050 IsolateClientProtocol IsolateDestPort IsolateDestAddr KeepAliveIsolateSOCKSAuth

xanoni avatar Aug 04 '21 09:08 xanoni

#1235 solved this when using local Tor instance. Should we add some info about modifying /etc/tor/torrc for system-wide Tor in docs/tor.md? Because:

It's just debatable what is needed and how beneficial it may be.

Otherwise this should be closed.

kristapsk avatar Jul 13 '22 10:07 kristapsk

@kristapsk This only helps if one connects through Tor via exit nodes, right? AFAIK different onion services are stream isolated by default. So if one uses IRC through onions, or the new onion channels, he should get that by default.

OP mentioned different circuits between rounds, not necessarily only between makers in the same round. (I believe @AdamISZ answer mostly refers to the latter. We don't reuse the same nick for the entire tumbler run, right?) I'm not sure of the details here, does the JM client keeps the connection to IRC servers and directories alive during the entire tumble run, or does it disconnects each time?

PulpCattel avatar Jul 13 '22 10:07 PulpCattel