1994-01-28 - 2-way anonymous via SASE

Header Data

From: jim@bilbo.suite.com (Jim Miller)
To: cypherpunks@toad.com
Message Hash: d10f61ffaa7c96a9a081a1af13f937cd82d459ffa4067561c54e6c1f78df478d
Message ID: <9401282254.AA00887@bilbo.suite.com>
Reply To: N/A
UTC Datetime: 1994-01-28 23:02:36 UTC
Raw Date: Fri, 28 Jan 94 15:02:36 PST

Raw message

From: jim@bilbo.suite.com (Jim Miller)
Date: Fri, 28 Jan 94 15:02:36 PST
To: cypherpunks@toad.com
Subject: 2-way anonymous via SASE
Message-ID: <9401282254.AA00887@bilbo.suite.com>
MIME-Version: 1.0
Content-Type: text/plain



Here's an idea that was inspired by Tim May's prepaid mailer example.  I  
call it "2-way anonymous communication using Self Addressed Stamped  
Envelopes".

The general idea is that each anonymous messages will include a SASE that  
can be used to reply to the sender, without revealing the identity of the  
sender to the message recipient.  To reply, the recipient will copy the  
SASE from the original message and past it into a special section of the  
reply message.  Remailers will examine this section of the reply message  
and use its contents to route the message back to the sender of the  
original message.  


The syntax's for describing the mechanism gets messy fast.  I hope I can  
describe it so others can understand it.

Here's how I see it working...


Small example:

Bob wishes to communicate anonymously with Ted via remailer R1.  (With  
just one remailer, R1 would be able to track who sends to whom, but this  
is just for example purposes.)

Bob constructs:

(stuff1)R1                   - stuff encrypted with R1's public key

Where:

stuff1 == Ted, (stuff2)Ted   - Ted's address and more stuff encrypted
                               with Ted's public key.

stuff2 == msg, SASE          - Bob's message and Self Addr Stamped Envlpe


All together, it looks like:

(Ted, (msg, SASE)Ted)R1

(i.e. msg and SASE, encrypted with Ted's public key, appended to Ted's  
e-mail address, all encrypted with R1's public key)

The SASE contains the information Ted will use to send a reply message  
back to Bob.  It looks like:

  R1, A, (stuff3)R1

where

  stuff3 == Bob, B, (stuff4)Bob

  stuff4 == A', B'

all together:

  R1, A, (Bob, B, (A', B')Bob)R1

expanded

  R1's address,
  A                  - a one-time public-key generated by Bob,
  ( Bob's address,
    B                - another one-time public-key generated by Bob,
    ( A'             - private key paired with A,
      B'             - private key paired with B
    ) encrypted with Bob's public key
  ) encrypted with R1's public key


Ok, Bob sends (stuff1)R1 to R1. This is just like using a regular  
encrypting remailer.  R1 decrypts stuff1 and gets:

Ted, (stuff2)Ted

R1, strips off "Ted" and passes the rest to Ted.  Ted receives  
(stuff2)Ted, decrypts it and gets:

msg, SASE

Which is really:

msg, R1, A, (stuff3)R1

Ted reads the message and decides to reply to whomever sent the message.   
Ted composes a reply and encrypts it with public-key A, then sends the  
following to R1 (he sends it to R1 because R1 was in the SASE):

(stuff3)R1, (reply)A           ==> R1

R1 receives this, decrypts (stuff3) and gets:

Bob, B, (stuff4)Bob

R1 encrypts (reply)A with public-key B and sends the following to Bob (the  
guy mentioned inside of stuff3):

(stuff4)Bob, ((reply)A)B       ==> Bob

Bob receives this, decrypts stuff4, obtaining A' and B'.  Bobs decrypts  
((reply)A)B using B' and A' respectively and gets the reply message.  If  
the reply message contained a SASE generated by TED, then Bob and Ted  
could continue to converse anonymously by including SASEs in each reply.



Expanded example:

Bob and Ted use combinations of R1, R2, R3 to communication anonymously


Bob write a message and wants to send it to Ted via R1, R2, and R3.  He  
constructs the following:

(R2, (R3, (Ted, (msg, SASE)Ted)R3)R2)R1

In this example, the SASE will look like the following:

R3, A, (R2, B, (R1, C, (Bob, D, (A', B', C', D')Bob)R1)R2)R3

ASIDE: As you may guess by now, Bob's message will go through R1, then R2,  
then R3, and Ted's reply will come back via, R3, then R2, then R1.   
However, the SASE does not have to specify the reverse route of the  
original message, nor even use the same remailers.


Anyways, Bob sends

(R2, (R3, (Ted, (msg, SASE)Ted)R3)R2)R1      ==> R1

R1 decrypts it and gets:

R2, (R3, (Ted, (msg, SASE)Ted)R3)R2

R1 strips off "R2" and sends the rest to R2.  R2 and R3 do similar things.   
Standard remailer stuff.  Eventually Ted will receive

(msg, SASE)Ted

decrypting obtains:

msg, SASE

Which is really:

msg, R3, A, (R2, B, (R1, C, (Bob, D, (A', B', C', D')Bob)R1)R2)R3

To reply to the sender of the message, Ted does just what he did in the  
first example.   He constructs:

(stuff3)R3, (reply)A

and sends it to to R3.  R3, R2, R1 do their thing and eventually the reply  
gets back to Bob.  When it arrives at Bob it will look like:


(A', B', C', D')Bob, ((((reply)A)B)C)D

>From this, Bob can recover Ted's reply message, while simultaneously  
verifying that the remailers correctly routed the reply.  If the remailers  
did not correctly route the reply, or failed to re-encrypt the reply with  
B,C, and D, then the thing Bob got at the end of the final decrypt would  
have been garbage.


Phew.  I wonder if it really works?


Jim_Miller@suite.com






Thread