Re: On reply blocks and tagging attacks (was Re: Problems withbit-twiddlers)

[Nick Mathewson <nickm@reputation.com>]

On Wed, 2002-04-03 at 09:46, George Danezis wrote:
 [...]
> Indeed I am not too happy to give the standard "dummy traffic" answer to 
> any of our problems. But I have to say that at the end of the day this is 
> a traffic confirmation attack (it only allows to test for a particular 
> hypothesis) and not a traffic analysis attack (it does not allow to trace 
> the message though the network) so it might be that we can only resolve 
> it by using dummies. 

Well, in a cascade-based regime, it can be analysis (in that, given a
sender, it identifies a possibly unsuspected recipient).

 [...]
> Therefore:
> - You (along with all the other attackers) can only tag one message in the 
> system, until you are confident it has been flushed out. (if each mix has 
> a latency of 1h and there are 16 max mixes then that would be one attack 
> every 16 hours). 

That is, 1 attack, _revealing the recipient of a message_, once every 16
hours.  If there are N attacks (in a cascade-based regime) at a time,
you can link a single message with one of <N recipients.  That's not
good.

> - You need to make sure that you control the final recipient.

Yeah, but in a dynamic cascade-based regime, this is bound to happen
every so often.

You can also greatly improve your chances of being the final recipient
by running a "legally difficult" service.  Outgoing nodes will probably
be less frequent than incoming ones.

> - You do not know at all what the content of the message was (but we do 
> not really care about that), and therefore cannot use it or find out the 
> final recipient or extract ANY information about what the recipient was 
> sending (offers plausible deniability as in our specs).
> 
> Are we still unhappy with this situation?

Personally, I'd rather have forward messages distinguishable from reply
messages, than have tagging work.

SIDE NOTE:
So far, we've been putting routing information for the last node (such
as email address of SMTP recipient) in the payload.  This probably needs
to change--can we move it to the header?

-- 
Nick