mix questions

Some Guy amichrisde at yahoo.de
Tue Dec 30 23:52:24 UTC 2003

 --- Roger Dingledine <arma at mit.edu> wrote: 
> On Tue, Dec 30, 2003 at 02:52:26PM +0100, Some Guy wrote:
> > Hi, I'm interested in working on a DHT with mix routing.
> You should recognize that Tor does _no mixing_. If you want
> effective mixing, you need a higher-latency system, such as Mixminion
> (http://mixminion.net/).

Ok sorry, bad term.  I mean circuit based annoymity, probably without too much reordering/batching
of messages.  It depends on what kind of app is using the DHT.  For file sharing you can do this
because downloads take a while anyway.  Is there a better term for "circuit based annoymity"?  I
used to call it onion routing.
> > Is it really nessesary for each node along a tunnel/circuit to check
> >messages for integrity?
> It depends on your threat model. For a system like Mixminion, we've
> solved enough of the other attacks that we think it's worthwhile to
> solve this one. For Tor, enough other attacks still work that per-hop
> integrity checking seems overkill.

Ok wait what attacks are possible, because of not checking consistancy on every hop?  It seems
like they can all be solved.

* If a faulty node tries to send a bunch of junk to generate obeservable bandwidth.  A
message/bandwidth limit on the cicuit should block that.  Once the junk is detected at an endpoint
the cicuit could be destroyed.

* If a faulty node tries to repeat messages, the same thing could happen.  Or we could be more
clever and have every node store hashes of all messages it has passed so far, and break the
circuit if sees a repeat.

Is there some threat I'm missing?

> > So I guess what I'm suggesting is the user sends the <hash(m),m>
> >encrypted with several layers
> > symetric keys, through the tunnel, and whenever someone notices after
> >decription that hash matches
> > the rest of the message, he then interprets the rest of the message
> >to be a control message
> > otherwise he just passes it along.
> > 
> > Does anyone know of a reason why this would be bad right off the bat?
> That's quite similar to how Tor does its cell recognition now. We also
> have 2 bytes in each cell to give a hint about whether we should try
> doing the hash, but that's just a performance optimization.

Ok it seems like I'm suggesting about what you're doing in the PDF.  I wasn't 100% sure.  So the
cell stays the same size going down the circuit?


Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de

More information about the tor-dev mailing list