Agreed. As I wrote in another thread:

> I also do not think their claims of Tor subversion hold water. From what I understand of Tor, directory information (including nodes' key fingerprints) is ultimately verified by the hard-coded keys of very few "trusted" operators of authoritative directory servers. So long as the Tor software isn't compromised, no MITM, regardless of where it's effected, will be able to subvert the user's circuit construction (of course, barring bugs in Tor and exploits higher up in the software stack). At least, that's my understanding.

However, I do assume they are very interested in capturing both short-term directory signing keys and the long-term keys which verify those short-term keys. This means the Tor servers listed as "dirservers" in src/or/confic.c, but especially the nodes tor26, dizum, Tonga, gabelmoo, maatuska, dannenberg, and Faravahar, as they appear located outside the US and so probably "game on" for NSA. I also assume NSA's "partners" will try the same with those authoritative directory servers in the US, which NSA would undoubtedly use to enhance their capabilities. Those who run authoritative directory servers need to be very careful (cough Appelbaum cough).

The paper's main conclusion, "NSA/GCHQ can surreptitiously selectively MITM users' Internet connections", appears to be valid (see FOXACID servers and NSA's "man-on-the-side" attack), but this is a well-known threat model.

In my non-professional opinion, the most likely way NSA/GCHQ would attack Tor appear to be through:

1) Honeypot nodes -- Tor relays which act normally, but silently record timing and circuit routing information ("circuit 2981: $253DFF1838A2B7782BE7735F74E50090D46CA1BC -> $1041213B53CCF586093BB65D9CC4BC0B9656EF17 @t=1386775503.00312")

2) "Upstream" data analysis of regular node connections -- build statistical models of likelihood of a client circuit routing from input node X to output node Y by observing timing of transmission rate bursts

3) CNE of non-US Tor nodes -- Pwn foreign nodes to turn regular nodes into honeypots

And so I wonder: it appears little can be done about 1) and 3) above what's already being done (other than emphasizing to relay operators that Tor relays should be run on an isolated system with as few open services as possible). Tor maintainers seem to see vulnerability to 2) as a fundamental problem with low-latency mixnets, and haven't taken steps (AFAIK) to complicate that analysis. Would it be effective to do something like the following?

1) Propagate relay-to-relay latency and jitter statistics along with client circuit data

2) Have each relay build a model of incoming latency and jitter statistics for each other relay

3) Associate each new client circuit on a relay with a latency and jitter bin selected uniformly at random from the models built in 2), excluding the model associated with the true incoming relay

4) Delay all packets in that circuit by the associated latency time, +/- jitter calculated from a probability distribution created in the associated model of 2)

This might be in combination with a change that removes or smooths bandwidth spikes by inserting dummy traffic between relays.

With both strategies, a) latency would be worse, and b) total available bandwidth would be lower. It looks like there's considerably more advertised bandwidth than there is used bandwidth, so b) might be OK. But a) might be a big problem for usability.

One more harebrained scheme: have each relay pick a few 'buddy' relays whose total advertised available buddy bandwidth sums to ~50% of this relay's estimated bandwidth. For each new client circuit, flip a coin and determine whether this circuit's traffic will be forwarded directly, or given to a buddy to forward. Similarly, the buddies each do the same with this relay. Associate 'chosen' client circuits with a buddy that tends to make a symmetric and smooth bi-directional data flow between the buddies.

OK, stream of consciousness over... I really got off on a tangent. I'm very interested to see why my lame schemes won't work, so please point out why I'm wrong (as I assume I probably am) :).