// COMPLETE THREAD

Proposal for anon chaining

3 expanded posts ยท every known parent and child

NODE d4ee9e92Proposal for anon chaining
Recent traffic on anonymous remailers/servers:

>From:  Eli   <ebrandt@jarthur.claremont.edu>
>> From: Hal <74076.1041@CompuServe.COM>
>> This method of posting does not allow you to receive replies.  I have set
>> "nicknames" for these two accounts as "Untraceable account" which will appear
> >in the "From" line on the postings.  Hopefully that will offer a clue that
> >the normal reply mechanism doesn't work.  Maybe the nickname should say so
>> more explicitly?
>
>
>The security provided by this technique could be provided without
>the IMHO serious disadvantage of having no return address.  Eric's
>hybrid approach, where a pseudonym server hands mail to an remailer
>chain, is secure (barring sophisticated traffic analysis) if you
>trust the last remailer in the chain.  Julf, have you thought about
>whether you want to do something like this?

> Hal

Here's an idea I haven't seen suggested before, which would remove the need
for a pseudonym server:

The way things stand now, chaining Cypherpunk remailers works by nesting PGP
encryptions of the form

<remail header>

***********
message text
***********

If you want to chain remailers, you encrypt the above, make IT the new 
message text, and then add another header, and so on until you get bored. 
My proposal is for a modification of this protocol to allow for 
pseudonymous return mail addresses, like this:

The trick would be to separate the message text from the remailer routing 
information, in a message of the form

***********
ROUTING INFORMATION
***********

***********
MESSAGE TEXT
***********

where both blocks are encrypted with PGP. The message text would be 
encrypted with the PGP public key of the intended final recipient of the 
message, and would not be modified by the intermediate anon remailers. 
The routing information would be for the benefit of the remailers only. 
It would be created by the RECIPIENT and made publicly available as a 
pseudonymous mail address. It would work like this:

Suppose user foo@bar.com wishes to establish a pseudonymous identity, and 
wants to route it through anon remailers "anon1" and "anon2". What he does 
is take a message of the form

::
Request-Remailing-To: foo@bar.com

and encrypts it with server anon1's PGP public key, to create 
<ANON1 ENCRYPTED ADDRESS>.  Then he adds another header to make

::
Request-Remailing-To: anon1

<ANON1 ENCRYPTED ADDRESS>

and encrypts THIS with anon2's public key to make <ANON2 ENCRYPTED ADDRESS>, 
and adds a header to make

::
Request-Remailing-To: anon2

<ANON2 ENCRYPTED ADDRESS>

Obviously, this procedure can be nested to arbitrary depth, chaining 
through as many anon servers as you like. The trick is that this address 
block can be made PUBLIC, since the only way to unwind the routing is 
to have access to the secret keys of all the intermediate anon servers, 
and the identity of the recipient is protected. foo@bar.com then 
anonymously posts a PGP public key and a routing block to some public forum,
and people can communicate with him without having any idea as to his 
actual identity.  When I want to send a message to him, I encrypt the 
message with his provided public key, and then add the encrypted routing 
header, which he has also provided.  I give him my own pseudonymous 
mail routing header to allow him to reply.

This seems to me to be a very robust pseudonymous mail system which 
could be implemented by relatively minor changes to the existing Cypherpunk 
remailer structure. It has the additional advantage of being decentralized 
and maintenance-free.  It could be used for pseudonyms on net news, e-mail, 
wherever, and could presumably be integrated in some way into Julf's 
anon server.

Comments?

                                -- Will
NODE b111b101Re: Proposal for anon chaining
> From: KINNEY WILLIAM H <kinney@spot.Colorado.EDU>
> The routing information would be for the benefit of the remailers only. 
> It would be created by the RECIPIENT and made publicly available as a 
> pseudonymous mail address. It would work like this:
...
> This seems to me to be a very robust pseudonymous mail system which 
> could be implemented by relatively minor changes to the existing Cypherpunk 
> remailer structure.

This appears to be the ARA system that was previously suggested,
which I was speaking of using with penet.  Your comment that changes
would be needed implies that it is different; if so, could you
clarify the difference?

The reason Eric suggested hanging this off the side of a pseudonym
server is that it is rather inconvenient in its pure form,
particularly for unsophisticated users.  It involves a thirty-line
block of cruft, cutting and pasting... ideally your MUA would handle
everything, but this isn't going to happen soon.  Grafting this onto
a nymserver as a return address gives you the ease of use of
something like penet, without having to maintain a central
nym<--->name mapping.

>                                 -- Will

   Eli   ebrandt@jarthur.claremont.edu
NODE 01fa74c3Re: Proposal for anon chaining
I write:
> > This seems to me to be a very robust pseudonymous mail system which 
> > could be implemented by relatively minor changes to the existing Cypherpunk 
> > remailer structure.
 
Eli  <ebrandt@jarthur.claremont.edu> writes:
> This appears to be the ARA system that was previously suggested,
> which I was speaking of using with penet.  Your comment that changes
> would be needed implies that it is different; if so, could you
> clarify the difference?

No, evidently I wasn't reading carefully enough. These do appear
to be the same. 

> The reason Eric suggested hanging this off the side of a pseudonym
> server is that it is rather inconvenient in its pure form,

Although I would suggest making the raw data available to those who
wish to bypass the nym server for some reason. Say, a 
"Request-Routing-Header <anon_id>", command. Although I imagine
you guys have your hands full getting even a basically functional
version up.

                             -- Will