Re: [ANN] M.0.0.3rc2: Reply block issue

[Zooko <zooko@zooko.com>]

George:

That is a good attack, and a good solution.

A long time ago I objected that SMTP delivery should not be included in the 
MixMinion protocol, but only cleanly layered atop it, and Nick objected that 
there *wasn't* anyway to make MixMinion unaware of the SMTP delivery address.  
That was a good point, and it silenced my objection.

I thought at the time that an opaque block, encrypted so that only the generator 
of the reply block can read it, could be passed along.  Then the SMTP delivery 
address could be encoded inside of it, so that the MixMinion spec itself is once 
again free of any mention of SMTP information, but SMTP delivery can still be 
implemented on top of it.

I didn't post this idea to the list, in part because I have a rule of thumb not 
to worry about abstractions which currently only support a single use.  The 
current design works just as well as my suggestion would have.

Now, if we implement George's solution to the "try othernym's reply block" 
attack, there will be *two* different pieces of information that ought to be 
generated by receiver and encrypted so that only receiver can read it -- SMTP 
delivery address and 'to: nym'.

I have another rule of thumb that if an abstraction would support *two* uses, it 
ought to be considered.

Apologies if either my understanding of the facts or my suggested abstraction 
are wrong for MixMinion -- I haven't been paying close attention for a few 
months.

Regards,

Zooko