More Mix questions

Some Guy amichrisde at
Sun Jan 11 18:02:31 UTC 2004

Hi, I'm back with another batch of questions.  I know they may not be Tor development related; so
it may be better to reply dirrectly instead of this list.

How bad is it if nodes know where they are on the tunnel?

If it's not that big a deal, then consistency checking could be done on each hop going out without
having to pad messages.

If tunnels are used for an extended time, it seems like even with the delay mixing, nodes on a
tunnel could still figuar out they were on the same tunnel by counting messages.  Example: There
cann't be many tunnels that have handle 3047 messages.  Dummy messages being dropped in the middle
of a tunnel or early leaving messages handled in the middle of a tunnel (like tor's exit
nodes!=end node), might help combat this problem.

I was wondering: has anyone developed circuits that branch out in a tree?  It just seems like a
cool way to solve this problem.

As with SURBs, has anyone considered single use tunnels?  They seem like a good idea for a network
where nodes only know about thier neighbors.  It might still be economical for large operations.

This is the type of situation I'd like to stay resistant against:
User -> node1(evil) -> node2(ok) -> end(evil)

Along with the consistency checking info a user could also send each node along the tunnel timeout
instructions with each request like "if you don't get a reply in 5min send a 1k block reply back
anyway."  If nodes only allowed one reply per request, it seems like node2(ok) could keep
end(evil) from sending any hints back to node1(evil).  They would be unable to know they were on
the same tunnel.  Am I right (if there's latency)?

Are there any networks that really resist that situation, and where nodes are not expected to know
about all other nodes in the system, but instead find out about them from the end node extending
the tunnel?  (assume the end node has no control over its neighbor list)


Gesendet von Yahoo! Mail -
Logos und Klingeltöne fürs Handy bei

More information about the tor-dev mailing list