[tor-dev] A few questions about defenses against particular attacks

[Yuhao Dong <yd2dong@xxxxxxxxxxxx>]

Hi,

I am currently working on a personal project implementing an onion-router,
vaguely similar to Tor (let's just call it Oor, other onion router, for the
moment), and I have a few questions about attacks, which I think are not
really protected by Tor, and whether my solution could possibly work. Of
course, if Tor defends against such attacks, then please enlighten me.


   - Traffic volume correlation. Tor's FAQ says that it doesn't plan on
   defending against an adversary monitoring traffic volumes flowing 
through
   the Tor network. Oor tries to protect against this attack by:
      - Obfuscating every single link with a protocol derived by Tor's
      obfs3 protocol
      - No public list of all node addresses; this makes determining
      whether certain traffic is Oor traffic much harder. More at the next
      bulletpoint
      - Splitting each circuit (termed "onion stew") into many subcircuits,
      all terminating at the same exit node. à la multipath TCP. Cells 
going
      through the subcircuits have a randomly-determined *uneven 
*distribution
      of choice of subcircuit, barring attackers from deducing total
traffic from
      observing one subcircuit.
   - Blanket blacklist attacks by censors. Censors can poll the directory
   and block all ordinary Tor nodes. (obfsproxy) bridges are a workaround.
      - Oor's directory maintains a *graph* of all nodes. Each node knows
      the public keys of all the other nodes, but each node only knows the
      addresses of *adjacent* nodes.
      - Note that this allows (sub)circuit-building along any path in the
      graph. The "extend circuit" command takes the next node's public
key as the
      parameter, rather than the address.
      - This reduces the bootstrapping problem to distributing (an alias
      of) the directory server address. Unlike with Tor bridges, this 
does not
      create a bandwidth bottleneck, and no nodes need to be reserved for a
      special pool of bridges, unable to be used by usual users.
Bridges often go
      offline, but this would work until the alias is blocked. However, 
as with
      Tor bridges, things like e-mail can be used to distribute many
      dynamically-generated aliases of the directory server.
   - Protocol recognition. In "free" countries like the US of A, Tor users
   see no pressure to use obfuscated bridges. Tor traffic is rather easily
   distinguished, and could be used to form suspicion on people. Even with
   obfsproxy, Tor's constant 512-byte cell length may be an issue. The
   "Stegotorus" paper presents a filter that finds cell lengths typical 
of Tor.
      - Every link is obfuscated in oor with obfs3.
      - obfs3 happens to create various cell lengths. This would be a
      problem for Tor-like circuits because it doesn't hide data sizes 
at all,
      but I think that breaking circuits into subcircuits solves this 
problem.

There is a not-really-working but readable PoC implementation of everything
except the "onion stewing" part, i.e. circuits can only work with one
subcircuit, athttps://github.com/quantum1423/kirisurf-dev/

Current work is underway to rewrite a more robust version with various
repos at
https://github.com/KirisurfProject/

(yes, it is currently called Kirisurf, oor is just for short previously,
and I want to change the kirisurf name anyways. You may find a "kirisurf"
on sourceforge. That is a simple one-hop encrypted proxy I made a long time
ago just for breaking censorship without privacy protection; Kirisurf
gradually grew onion-routing things until I decided to redesign it;
namechange probably needed to prevent misleading version numbers)

I would be interested to know what research has been done on these areas in
Tor (to avoid reinventing the wheel), and whether any of my ideas are novel.

Thanks!
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev