Re: Giblit Proposal

[Some Guy <amichrisde@yahoo.de>]

--- Roger Dingledine <arma@mit.edu> wrote: 
> On Sat, Jan 03, 2004 at 07:16:14PM +0100, Some Guy wrote:
> > So a tagged message would only have a 1/16th chance to make it another hop before being
> > identified, and raising alarm bells or at least being dropped.
> 
> Here are the problems:
> 
> 1) If this is designed for low-latency systems, then:
>    a) Tagging attacks are irrelevant, because timing and counting attacks
>       (see http://freehaven.net/anonbib/#SS03) already work great.

The word "timing" or "counting" doesn't appear in this paper "danezis wpes2003"="Heartbeat Traffic
to Counter (n­1) Attacks".  Is that what you meant to point me at.

Define f as the fraction of faulty nodes.  The chance that both the second node (that knows the
user) and the end node (one that knows what the user does) is f^2.  Now sure the second node may
not be 100% sure it's really next to the user; there is a bit of plausible deniability.  If
circuits go only 2-3 hops, there is a 50% chance as far as the adversary is concerned it doesn't
know the real user.  Is this good enough and what you're shoot for?

It makes me sad.  I was hoping the chance anonymity would be broken to be something like
f^tunnel_length.

>    b) Thousands of crypts overhead per cell is an unacceptable performance
>       penalty. It will seriously impact throughput.

Well keep in mind this little giblit can be the size of the smallest most efficient block. 
Sending a 1K message already costs you a serveral of these smaller crypts.

> 2) If it's for high-latency systems, then this low chance of detection
>    is not good enough. Plus, messages are large enough that you can afford
>    to use some more space. Mixminion includes a hash of the header at
>    each hop, and includes some more magic to deal with the body; see
>    the design paper for details.

I'm reading about the way Mixminion does it.  It seems like if they weren't SURBs, then you could
still tag those hashes in the headers, and figuar out what a circuit was used for.  Am I right
about this?

> Also, note that this integrity-checking you're talking about cannot work
> for intermediate nodes in the reverse (reply) direction, because they
> don't know the other symmetric keys used in the circuit, so they can't
> know what the cells will look like at other hops.

Sure, but it wouldn't need to.  A tagged message going that way would only be identifiable to the
user.  I was think about maybe giving the end node a special reply ticket which could be sent
along with a reply and tested by everyone, just to prevent traffic attacks.  Does anyone do that?

> Please carefully reread http://mixminion.net/minion-design.pdf and
> http://freehaven.net/tor/tor-design.pdf. Feel free to mail me privately,
> but we should take this thread off the or-dev list.

Sorry Roger, I hope I didn't bug you.  That first question I was asking a while back, looking back
at the documentation of tor, I could see that I was suggesting was like what you're doing, but it
wouldn't have been clear to me without you explaining it on the list.

One quick dumb question: Do Minion and Tor both require you know about all the nodes like Tarzan? 
I'm tring to work on a DHT topology where that shouldn't be the case.
  

__________________________________________________________________

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