[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Addressing the tagging attacks



On Wed, 2002-04-03 at 11:32, George Danezis wrote:
 [...]
> - Instead of having a type (2 bytes) field in the header we only have
>   1 bit that lets the node know if it is the last one or not (and will
>   include the Type in the payload to minimize the value of the tagging
>   attacks that are still possible). 

I don't get the implications of this.  How does delivery work?  How does
the last node know whether to deliver to Bob or not?  Do all recipients
need to run nodes?

 [...]
> We can have a standard module (like DROP) that gets the SURB from the
> payload, creates a new message using it and sends it out. It is
> possible therefore for only 1 node to tell that a message is sent
> using one mechanism or the other (which is also true if you send a 
> message directly only using a SURB).

How do you create a routing block from a SURB?  Or are all SURBs
block-length?

> Security?
[...]
> As discussed before on the list only the last mix can tell if a
> message payload is tagged, and it can only distinguish between messages
> with different timestamps(*), since all of the body is going to be
> completely random. It cannot tell what type the message (since the
> type information is in the body).

Whoa, I don't think this is right.  The node that extracts a SURB from
the body will be able to tell scrambled from non-scrambled messages,
right?

And if the typecode is in the body, that last node will be able to tell
messages with scrambled bodies from messages without.

And doesn't this imply that it's no longer possible to receive messages
without client software?

> (*) Timestamps
> 
> As it has been described in the previous email timestamps 
> are becoming a nightmare. Now I found out they they allow an attacker to 
> separate the messages per day. Should be consider having a "deadline" 
> instead of a timestamp? So that packets are not valid after that deadline 
> that could be quite large (although intermediate nodes need to keep some 
> state per packet until that deadline).

No, that's still vulnerable. If Alice sends a message on April 1 that's
valid till April 30, Mallory can delay it till April 30, when there
won't be many messages at all with an April 30 deadline.

-- 
Nick