Re: [minion-cvs] clarified the subheader section

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

I think that there is no security problem with that approach, since the 
secret used is only recoverable by the node. There is only an 
engineering/extensibility issue which is only partially relevant to 
mixminion. For some reason the address has to be recovered before the 
"Shared secret" can be computed you are in a deadlock situation. The 
obvious question would then be: why/how the hell could that happen?

It turns out that this is one way of providing "forward secure" mixing. 
Which means that after a certain amount of time any opponent who has 
intercepted material and can force mixes to decrypt it cannot do it any 
more.

More information is contained in a paper I am writing right now that you 
can find a pre-alpha version at:

http://www.cl.cam.ac.uk/~gd216/fsmix.pdf
(not for distribution please!)

Otherwise I am happy with the scheme.

George

On Wed, 5 Jun 2002, Roger Dingledine wrote:

> On Wed, Jun 05, 2002 at 08:27:58PM -0400, Nick Mathewson wrote:
> > >  The Routing Extension corresponding to a particular subheader is
> > >  encrypted using the Encrypt function with key=Hash(Shared Secret,
> > > -``ROUTING EXTENSION SECRET KEY'') and appended to the RSA encrypted
> > > +``ROUTING EXTENSION SECRET KEY'') and appended to the RSA-encrypted
> > >  subheader.
> > 
> > Claim:  There's no reason to use a separate key for the routing
> > extension.  Instead, use Hash(Shared Secret || "HEADER SECRET KEY") to
> > encrypt all of the header from the Extensions through the end.
> > 
> > I have this working in CVS.
> 
> Works for me.
> George?
> 
> --Roger
>