anonymous return addresses

The recent penet troubles are a reminder that secure anonymous return
addresses are a lot harder than secure anonymous mail with no return
capability.  Maybe it's time to go over the options available to us
for anonymous return?

  1. Remailer memorizes a pseudonym.  I don't like this, mainly because
     it leaves the remailer operator vulnerable to pressure to reveal
     the correspondence between real and anonymous id's.  It
     also opens up about a million possible security holes, as
     we've noticed.

  2. The anonymous message includes a cryptographic "stamped
     self-addressed envelope" which contains a layered list of
     remailer addresses encrypted at each layer.  This requires
     modified behavior of remailers; they must be willing to "unwrap"
     an address-list separately from the message body, and then
     "wrap" the entire message with the destination's public key,
     in order to disguise the correspondence between input and output.
     I think this has been discussed here before.  Has anyone
     implemented it?
        I strongly suggest that this method be implemented in
     the cypherpunks remailers.  Let's call it the SASE feature.
     What do you think?

  3. The reply to an anonymous message can be posted in a public place
     encrypted for a key known only to the sender.

Have I missed any important methods?

-- Marc Ringuette (mnr@cs.cmu.edu)

Re: options for anonymous return

Marc writes:
>  1. Remailer memorizes a pseudonym.  

>  2. The anonymous message includes a cryptographic "stamped
	self-addressed envelope" which contains a layered list of
	remailer addresses encrypted at each layer.  

>  3. The reply to an anonymous message can be posted in a public place
	encrypted for a key known only to the sender.

>Have I missed any important methods?

A variant of (1) greatly increases the security.  Have the remailer
memorize an anonymous return address of type (2).  The information
that is contained in a remailer then, per pseudonym, is

  a.  the pseudonym
  b.  the address of the next remailer to use
  c.  a block of stuff to be prepended to the outgoing mail.  Presumably
        this is forwarding instructions for the next remailer.  It would
	also be encrypted with the public key of the next remailer.

Thus, even if the whole pseudonym mapping list were compromised, it
would only reveal a list of sites to try and compromise next.  And at
some point the private remailer keys have to be compromised as well,
since all the remailing instruction are encrypted with them.

This system can also be chained, creating "routing pseudonyms" on
various remailers and encrypted instructions pointing one pseudonym to
another.

Eric

> A variant of (1) greatly increases the security.  Have the remailer
> memorize an anonymous return address of type (2).  The information
> that is contained in a remailer then, per pseudonym, is
> 
>   a.  the pseudonym
>   b.  the address of the next remailer to use
>   c.  a block of stuff to be prepended to the outgoing mail.  Presumably
>         this is forwarding instructions for the next remailer.  It would
> 	also be encrypted with the public key of the next remailer.

This is an excellent idea!  It would provide decent security without
forcing J. Random User to figure out how to use the SASE block.
You'd want to have a list of address/SASE pairs to use, choosing
randomly from those that have not yet died.

Oh, a complication.  It would probably be necessary to be able to
add new address/SASEs as they become available, to avoid death of
your pseudonym through cumulative remailer attrition.  But nobody
but the owner can be allowed to add destinations, for obvious
reasons.  The only apparent way to handle this is to require a
password at the time of pseudonym creation.  One-way-hash it, and
require it to add and remove destinations.  It should be
PK-encrypted on its way to the remailer, if possible.  This approach
does not require an identity to be irrevocably tied to a destination
address, interestingly -- you can remove chains to your old address,
and add ones to your new.

Suggestions?  Holes?  Implementations?

> Eric

	 PGP 2 key by finger or e-mail
   Eli   ebrandt@jarthur.claremont.edu