2

Say you had multiple online accounts of all kinds and you route them all through a local Tor daemon on your computer using SOCKS[45].

I'm wondering if running multiple separate Tor instances that offer a SOCKS port each would help to improve anonymity. I could route each client application/account through their own daemon. Hence fully separating guard nodes, circuits, web/XMPP/IRC/Mail/foo traffic from each other.

What would be the pros and cons regarding anonymity and security given that each of the daemons could use a distinct configuration for the intended use. Even differently compiled/patched Tor daemons come to mind.

2 Answers 2

3

You can run a single Tor daemon, but configure it to open multiple SocksPort (and/or TransPort & DNSPort) listeners. Applications that connect to different listener ports will use isolated circuits if your Tor version is 0.2.4 or higher.

The general consensus about guard nodes seems to be that the Tor client daemon already selects too many, and a reduction is planned.[1] Multiple Tor daemons would select even more, so it's probably not a good idea.

3
1

The SocksPort aspect is easy. Just start multiple instances:

tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9050
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9051
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9052
...

It's the DnsPort aspect that's hard. The default is port 53. You could bind each instance to a different DnsPort:

tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9050 --DnsPort 9090
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9051 --DnsPort 9091
tor --defaults-torrc @CONFDIR@/torrc-defaults --SocksPort 9052 --DnsPort 9092
...

And then you could map port 53 for each application to the proper DnsPort.

The canonical answer about entry guards is that variety greatly increases vulnerability to relay adversaries. The idea of using just one entry guard, and keeping it longer that the current two-month default, is under discussion. You could add "NumEntryGuards 1" to "torrc-defaults", and just have one per instance. And you could use "EntryNodes node,node,…" to specify trusted entry guards with good bandwidth, either in "torrc-defaults" for all instances, or individually in each command line.

The strategy of fragmenting activity into unrelated components, and then isolating and disassociating the components, is useful in two ways. First, it protects anonymity. As long as the components are sufficiently unrelated and disassociated, adversaries can't build a coherent persona model, even if they can see each of the components, or at least their effects. And with no coherent persona model, matching to known persons is problematic. And second, it limits the impact if any component is compromised.

However, I don't think that isolating and disassociating by entry guard is all that useful by itself. Typical relay adversaries run lots of attractive entry guards. Over time, their entry guards scan virtually all clients using the default: three entry guards, rotated based on the GuardLifetime parameter from the consensus directory (currently two months).

Over time, they seek circuits that use both one of their entry guards, and one of their exit relays. Whenever they find one, they log whatever information is available about the circuit, and also about the destination. Even if there's end-to-end encryption, they get an IP address and some information about the protocol and whatever. And the logs obviously include client IP addresses.

Given such logs, it's trivial to select client IP addresses of interest, based on destinations of interest. As long as an adversary's entry guards can scan through most clients, even if it takes a year or more, they can eventually associate some set of the anonymous components with an IP address.

Therefore, isolating and disassociating by entry guard is an effective strategy only when your entry guards are highly trusted. If I were doing this, I would probably use my own entry guards.

Using maximal isolation via some concatenated mix of VPNs, JonDonym and Tor, I'd lease several small hosted servers (not VPS). I'd pay with insanely highly anonymized Bitcoins, and/or cash by mail. I'd use dm-crypt/LUKS FDE, with dropbear for remote decryption/mounting. Any server that spontaneously rebooted would be dropped as untrusted. And I'd use Tor-ramdisk.

Even so, some of those entry guards might be tapped by hosting providers, ISPs, etc. To distribute trust, I'd site them across as many different political/military power blocks as possible. I'd also specify entry guards (bridges, really) as domain names, and use DNS-based fast flux (Proximax) to rapidly cycle through my set of semi-trusted entry guards.

On top of that, it might be useful to route each Tor client through a different JonDonym mix, with a premium account funded by insanely highly anonymized Bitcoins. I would access JonDonym via multiple nested VPN chains, using a mix of trusted VPN services and private VPNs, set up as described above for the entry guards.

1
  • Thanks. I know how to build/configure tor and multiple instances. The question was if that could (even if only academically) improve anonymity? - Using different guards/bridges would reduce the risk of a compromised entry to one service.
    – MacLemon
    Jul 26, 2014 at 11:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .