Re: 2-way anonymous via SASE

[wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)]

Jon Boone <boone@psc.edu> writes
>   Isn't it true that no matter how many remailers you use, the full spec
>   of the return path has to be included?  And if the last remailer is 
>   keeping a log of all messages passed, then the reciever/replier need
>   only interrogate the last remailer to find out the sender's address?

No, the last remailer only needs to know how to send mail to the
preceeding remailer.  Depending on how fancy a remailer system you're
using, and whether the recipient or remailer operator can be trusted,
there are different amounts of work you need to do to get what you want.
If you're creating 1-shot reply tokens, they can be set to send
to an address at the n-1th remailer, which anonymizes and adds the address
for the n-2th remailer, etc.  This gives you reasonable security as long
as at least one remailer can be trusted and isn't coercible.
Don't know if anybody's implemented remailers supporting this yet;
Julf's anon.penet.fi remailer gives a more persistent return address.

BTW, an alternative to arranging digipayment to every remailer
in the chain, which is complex, slow, and introduces opportunities
for leakage, might be to create a "Remailer Postage Cooperative";
postage gets sent to the first remailer only, and the remailers
use some sort of settlements process to divide up the payments,
the way phone companies or post offices do.  Postage might vary 
by number of hops you're paying for or whatever (e.g. a 3-hop stamp),
and settlements might be per-message or might just be apportioned by the
difference in amount of traffic flowing in each direction.
This works better with a stable system of remailers,
but even if the remailers aren't all cooperating, it at least lets you
reduce the number of postage-stamp messages to the number of cooperatives
your message uses instead of the number of remailers,
and reduces setup considerably.

>  Jon Boone | PSC Networking | boone@psc.edu | (412) 268-6959
>  finger boone@psc.edu for PGP public key block

Finger can be faked - including your Key ID or fingerprint in
your .signature file lets people be more sure it hasn't.
e.g. >  finger boone@psc.edu for PGP public key block ID #123456

# Bill Stewart  AT&T Global Information Systems, aka NCR Corp
# 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204
# email bill.stewart@pleasantonca.ncr.com billstewart@attmail.com
# ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465