1994-02-02 - Re: 2-way anonymous via SASE

Header Data

From: jim@bilbo.suite.com (Jim Miller)
To: cypherpunks@toad.com
Message Hash: 3764485b2707fa6ea73e14cc4e1ec9e9178c417d5919da39195e6c76773ff398
Message ID: <9402020513.AA07003@bilbo.suite.com>
Reply To: N/A
UTC Datetime: 1994-02-02 05:20:49 UTC
Raw Date: Tue, 1 Feb 94 21:20:49 PST

Raw message

From: jim@bilbo.suite.com (Jim Miller)
Date: Tue, 1 Feb 94 21:20:49 PST
To: cypherpunks@toad.com
Subject: Re: 2-way anonymous via SASE
Message-ID: <9402020513.AA07003@bilbo.suite.com>
MIME-Version: 1.0
Content-Type: text/plain



Jon Boone writes:

>  Now, what is this SASE?  Apparently it is either a) a
> fully-specified   return-path (presumably a chain of
> anonymous ids at various remailers),   b) a next-hop
> address (anonymousid at the next remailer that "knows"  

> where to send the message), or c) some combination of the
> previous two.
> 

>   Is there another possibility that I have missed? 

> 


The SASE's that I've been describing are not type a, b, or c.

"b" is closest, except the next-hop address is not an "anonymousid at the  
next remailer", rather, it is simply the e-mail address of the next  
remailer to send to.

The SASE is structured somewhat like a message enclosed in a bunch of  
nested digital envelopes.  If you don't understand "message enclosed in a  
bunch of nested digital envelopes" then you will have a hard time  
understanding SASE's (at least the type of SASE's I'm describing).


** Using Nested Envelopes for sending anonymous e-mail (simplified) **

Say Bob wants to send a message to Ted, routing the message through R1 and  
R2, and finally to Ted.  First of all, Bob needs to know the e-mail  
address of R1, R2, and Ted.  Bob also needs to know the public-key of R1,  
and R2.  He will probably also want to know the public-key of Ted, but  
that is not required.

[Notice that I did *not* say the Bob needed to have an anonymous account  
id at each of the remailers.  There are different types of remailers.   
Some provide anonymous accounts, others simple forward e-mail.  In the  
description below, I am referring to remailers that just forward e-mail.]


To send to Ted, Bob constructs the following: (not considering SASE's yet)

      R1_PK(R2-addr, R2_PK(Ted-addr, Ted_PK(message)))

where:
   XX_PK(stuff)     stuff encrypted with XX's public-key
   XX-addr          e-mail address of XX


Bob sends this mess to R1.

>From R1's point of view, R1 receives

      R1_PK(stuff1)
      

R1 decrypts "stuff1" and gets:

      R2-addr, R2_PK(stuff2)

R1, strips off "R2-addr" and e-mails R2_PK(stuff2) to "R2-addr".

R2 receives

     R2_PK(stuff2)
    

R2 decrypts "stuff2" and gets

     Ted-addr, Ted_PK(message)

R2 strips off "Ted-addr" and e-mails Ted_PK(message) to "Ted-addr".

Ted receives

     Ted_PK(message)
     

Ted decrypts it, and gets Bob's message.


As you can see, you need to use a special type of remailer to get this to  
work.  Not all remailers support the "decrypt, strip, and re-send"  
operation.

You seem to be familiar with the type of remailer that sets up an  
anonymizing "account" (e.g. an12345@anon.penet.fi).  These "Penet-style"   
remailers give you an easy mechanism for doing 2-way anonymous  
communication.  Ted can use ordinary e-mail commands to send a reply  
addressed to "an12345@anon.penet.fi".

The "decrypt, strip, and re-send" remailers do not provide a trivial way  
to send reply messages.  The SASE mechanism is an attempt to extend these  
types of remailers so Ted can reply to whomever sent him the anonymous  
message (Ted doesn't know anything about the original sender, not even a  
anonymous id.  Ted only knows that R2 forwarded a message to him).


Jim_Miller@suite.com






Thread