Timestamps and delaying [Re: Addressing the tagging attacks]

[Nick Mathewson <nickm@alum.mit.edu>]

On Wed, 2002-04-03 at 13:10, George Danezis wrote:
 [...]

George, Zooko, I'm going to have to think for a while about all of
this.  I'm starting to prefer solutions that distinguish between forward
messages and SURB messages, and block bad forward traffic at each hop.
Having forward messages distinguishable from SURB messages seems like a
clearer sacrifice.

But maybe we can have our cake and eat it too.

(I'm still thinking because I still don't understand all the
ramifications of George's latest proposal, and I want to think about the
tradeoff between the waste in Zooko's proposal and the linkability in
the 2-variants approach.)

 [...]
> > 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.
> > 
> 
> That is a tough one, and seems to be quite orthogonal to the tagging stuff 
> (although it contributes to it). Anyone has any ideas?

Here's what I proposed before: every instant falls in two intervals.  If
you're not near the end of either, you pick one randomly.  Otherwise,
you pick the one that isn't ending soon, AND send dummy traffic that
will expire.

That way, when you see a message that will expire soon, you can't tell
whether it's a delayed message from the about-to-expire period, or a
dummy expired message.

-- 
Nick