mix questions

[Roger Dingledine]

You should really read the Tor design paper
(http://freehaven.net/tor/tor-design.pdf) which talks
about some of these issues. And you must subscribe to the list
(http://archives.seul.org/or/dev/) if you want your posts to go through
in the future.

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/).

> 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.

> I realise this lets a faulty node inserting bad data immediately be
>identified by its neighbors.
> However couldn't a faulty node just drop all the messages to break a
>tunnel anyway?

The problem comes when a faulty node can influence the traffic on the
stream. If the user is typing "dir" into an ftp server, and the adversary
(running an intermediate node in the circuit) manages to guess this,
imagine if he could remove the "dir" from the stream and replace it with
"delete *". Or if he thinks based on byte counts that the user is reading
the cnn.com webpage, and he returns a slightly modified page instead.

> Does anything stop a faulty from repeating messages?  Is that dangerous?

It can be very dangerous (depending on your threat model). We prevent the
adversary from successfully replaying messages, both in terms of opening
circuits/streams and in terms of transmitting data in a stream. See the
design paper for details.

> If an application (like DHT) using mix routing had only a few fixed
>message sizes, there would be
> no need to pad the messages, if messages stayed the same size going
>down tunnels.

It's possible that could work. Notice that your requests and your
responses will probably be different sizes. Also, you may still want
other sorts of padding (dummy traffic), to hide *when* a given request
or response is being delivered.

> 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.

--Roger