Re: Timestamps and delaying [Re: Addressing the tagging attacks]

[Zooko <zooko@zooko.com>]

Folks:  We're going to visit the Univ. of Toronto from today (in about 15 
minutes! Oh no I need to pack!) until Monday the 8th.  I probably won't have 
e-mail during the trip.

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

I too prefer the forward-travelling/reply partition over being open to tagging 
attacks, but I too, don't fully understand George's latest proposal yet.

Let's get a little bit more concrete about the waste in my proposal:

Suppose our overall packets are 62 KB.  Suppose the header is 2 KB, room for 
16 records which include secret, address, MAC, and "forward-or-up" bit.

Then the reply block is also 2 KB.

So we can get as much as 58 KB of payload per packet with the "two kinds of 
messages" approach and as much as 29 KB of payload per packet with my "two 
payloads per message" approach.

Now I think that in either case we are going to have to do a lot of extra 
network engineering for retries, fragmentation and so forth on top of the basic 
mix, so I'm not thinking of it as "With one approach you can't send messages 
larger than 58 KB, and with the other you can't send messages larger than 
29 KB.", but instead "With the latter approach you send twice as many packets 
and occur correspondingly higher chance of dropped and retried packets.".

However, I'm not at all sure about the traffic analysis implications of 
fragmentation and retrying!

Hm.  I guess we picked 62 KB in the first place because we intuited that it would 
be large enough to handle a lot of messages without causing too much wasted 
padding.

So maybe the real alternative should be between the "two kinds of messages" 
approach with 62 KB packets and the "two payloads per message" approach with 
126 KB packets!

Okay, gotta run.  I'm very excited about this project.


Regards,

Zooko