1994-04-10 - Re: REMAIL: pseudo-account remailer @andrew gains anonymous feature

Header Data

From: Ed Carp <ecarp@netcom.com>
To: Matthew J Ghio <mg5n+@andrew.cmu.edu>
Message Hash: 96f6a79798c6732f029fbf556e967f7f22426c4b51dc4a4a352c4aa69b3a6e33
Message ID: <Pine.3.85.9404091920.A25730-0100000@netcom4>
Reply To: <ohdpBvK00VB_0K4EkW@andrew.cmu.edu>
UTC Datetime: 1994-04-10 02:45:05 UTC
Raw Date: Sat, 9 Apr 94 19:45:05 PDT

Raw message

From: Ed Carp <ecarp@netcom.com>
Date: Sat, 9 Apr 94 19:45:05 PDT
To: Matthew J Ghio <mg5n+@andrew.cmu.edu>
Subject: Re: REMAIL: pseudo-account remailer @andrew gains anonymous feature
In-Reply-To: <ohdpBvK00VB_0K4EkW@andrew.cmu.edu>
Message-ID: <Pine.3.85.9404091920.A25730-0100000@netcom4>
MIME-Version: 1.0
Content-Type: text/plain


On Sat, 9 Apr 1994, Matthew J Ghio wrote:

> Ryan A. Perkins wrote:
> 
> > >An encrypted reply address is created for the sender of the anonymous
> message.
> >
> > What happens if I already have an encrypted reply address? What happens
> > if I already have SIX encrypted reply addresses? Which one is used?
> > Or is *another* one created?
> 
> Another one is created, since no records are kept of what addresses you
> already have.
> 
> I am somewhat unsure of what to do in this situation.  As I have it set
> up now, it will always create the same address for replies (but you can
> still get as many different ones as you like from mg5n+getid@andrew...) 
> so if you send two messages to mg5n+anxxx... addresses, they will both
> have the same reply address.  I could change this and have it create
> different ones each time, which would preserve anonymnity better, but
> this could lead to confusion when replying to messages, because it'd be
> difficult to tell if two messages came from the same person or not.  I
> suppose a more complicated system could be set up where the users would
> specify which reply address they wanted to use, or where replying to a
> certain address would always allocate the same reply-id.  Any
> suggestions?

How about generating a secure hash and using that as an index into a 
table?  If there's an address already there, use that - otherwise, 
generate one.

Generate the hash from the incoming address, of course.  That way, you 
don't need to keep track of anon-id-to-real-id mappings, yet guarantee 
that each user has one and only one anon address. Of course, folks coming 
in from different hosts will have different anon ID's.

Or have I missed some blindingly obvious technical point thaqt would make 
this impossible?






Thread