Re: Reply blocks and tagging protection: a third variant

[George Danezis <gd@theory.lcs.mit.edu>]

On Sun, 7 Apr 2002, Roger Dingledine wrote:
> Which leads to the issue of putting destination information in the payload
> vs the header. I'm still not convinced by George's statement that it
> should go in the payload. First off, it seems hard to put destination
> info in the payload of a reply block: I just don't know how it could work
> with our encryption system. The guy using your reply block should not be
> able to learn (parts of) your delivery info, eg by keeping transport_type
> but changing email_address, in order to learn transport_type. Second,
> in order for tagged (and thus random) messages to not be recognizable,
> some messages must be plausibly all-random. These messages are the ones
> that are encrypted to somebody, either a forward message encrypted to
> the recipient or a reply message which has been multiply-encrypted. If
> the destination info is in plaintext, then these payloads aren't
> all-random. So tagged messages are discernable.
> 

The idea is not to explicitly put all routing information in the payload. 
Routing information should stay in the two headers. The point I tried to 
make is that the second header depends on the correct decryption of the 
payload and therefore if the payload is modified it is not possible to 
continue with the delivery. Note that this property is stronger then just 
including a hash to check the payload that a malicious node could ignore.

As I say before no routing information is in the payload, only in the 
second header, which is treated exactly like the first one after a certain 
stage. I do not see how tagging attacks would work against it.

> Can you clarify your reasoning for putting delivery info in the payload,
> George? Do you agree that the above approach is simpler but along the
> same lines? Does it lose any properties from yours?
> 

The reason why the second header should be dependent on the payload is 
that if the payload is modified, in an attempt to do a tagging attack, 
then the second header cannot be recovered. Therefore a attacker can only 
recover using a tagging attack half the route in the best case.

This property could be 
implemented by a "strip N and decode using payload" operation but I think 
it is unnecessary to provide more general operations than strictly 
necessary (unless there are other reasons). 

> Ugh. It's 7am. I reserve the right to deny this when I wake up. :)
> --Roger
> 

Yours,

George