On 10/26/19, Punk - Stasi 2.0
2005 Low-Cost Traffic Analysis of Tor https://www.freehaven.net/anonbib/cache/torta05.pdf
"By making these assumptions, the designers of Tor believe it is safe to employ only minimal mixing of the stream cells...
...This choice of threat model, with its limitation of the adversaries’ powers, has been a subject of controversy...
...Tor, on the other hand assumes a much weaker threat model..
...we show that even relatively weak adversaries can perform traffic-analysis, and get vital information out of Tor. This means that even non-law-enforcement agencies can significantly degrade the quality of anonymity that Tor provides, to the level of protection provided by a collection of simple proxy servers, or even below."
-------
my comment : the attack is based on monitoring the latency of a node while sending an attacker controlled stream through it
"Tor exhibits the worst possible behaviour: not enough interference to destroy individ- ual stream characteristics, yet enough to allow the remote measurement of the node’s load."
Maybe some tor fanboi knows if this has been somehow fixed?
Tor, perhaps as result of years of such papers and posts, is attempting to incorporate some traffic noise, search there for "netflow" and "padding", however the breadth of its application may not be enough to close out many of the traffic analysis papers. People should look more closely at that work and analyse its results.
Anyway the article makes it clear that simple cover traffic in not enough to defend against timing attacks.
This may be one of the papers that may outlines why, in a fill padding chaff wheat network, or even any network, that every node also needs to reclock the input it receives into its output, else adversary can see the perturbations it applies to a nodes input reflected in its output, and or see the natural perturbations the internet itself imparts, and those of the users own traffic patterns, carried through end to end without mitigation. Also why, similar to some Bittorrent and other protocols, overlay nodes should probably drop contracts they have with other peer nodes that do not fulfill input performance expectations. ie: Bittorrent nodes (clients) ignore nodes that send corrupted datas... overlays should drop peer nodes that exhibit non conformant traffic characteristics... such as unclocked, bursty waves, etc that was not agreed to, that would present risk to observability. ie: First, don't accept sketchy peers trying to send you suspect waveforms to carry, and Second, do not forward anything on through you to another node without conforming and reclocking it, don't be so busy or partition attacked that your node can't uphold that thus becoming a risk to the net, sleep and reestablish your node into the net later. Since an overlay network does not yet own the underlying internet hardware (and there is not yet full time crypted link rate fill HW RFC), this must be done in nodes CPU versus at the NIC PHY over the cable. You can get closer to Layer0 with #OpenFabs #OpenHW #MeshNets #GuerrillaNets. Note also there is a difference in design thinking approaches between say... - Cover traffic, meaning traffic laid over or filling in gaps in wheat. The wheat ends up being awarded a variety of mental biases and design assumptions in its favor which could prove controlling and exploitable. - Base fill traffic, meaning a base of fill [at linerate, fulltime, regulated], such that when wheat is ready to pass, the wheat packet is substituted in for the fill packet. The fill security aspect is mentally biased for, such that it should continue to hold regardless whatever wheat or active adversary crap is attempted to be sent over or at it. There's something to be said for "store and forward" overlays on the order of hours to days... file storage, email / nntp. Unfortunately they're no good for anything interactive realtime... IRC, urgent messaging, website queries, transactions, voice, video. There's also consideration to make on whether an interactive realtime network should also provide, if needed, a store and forward layer, or treat it as just another app riding on top, as all realtime nets do today. Or whether to cripple either s+f or realtime to preclude use of the other over them. ie: Tor is somewhat crippled by TCP only. Whereas I2P/Tor+OnionCat, CJDNS, Phantom enable UDP etc by providing a full IPv6 stack. Other overlays have similar restrictions and capabilities, most not intentionally preclusive, instead being just "We want to create a net to do X (say send an email)" and the net just ended up being useless for anything else. Keep in mind, once you have a cryptographically strong analysis resistant general purpose overlay transport network (ie: internet stack), you can run anything over it. Don't be afraid to create an AF_OVERLAY if needed to accomplish that. If the overlay network is truly good, people will get todays applications ticketed, patched, and compiled with that option to inferface with them.