Will Kinney suggests a form of anonymous return address in which "Request-Remailing-To" headers are nested and encrypted, then used for addressing. This is a fine idea, Will, but we're way ahead of you on this. This approach has been used ever since we added encryption to the remailers. Karl Barrus even wrote a script specifically for constructing anonymous addresses like this. It's available from the Cypherpunks ftp site. (soda.berkeley.edu, /pub/cypherpunks. I think the file is something like "scripts.tar".) The problem with this in practice is, first, that the return address block is rather large, especially if more than one level of nesting is used (often 10, 20 lines or more); and second, that it does not lend itself to automatic use of the "reply" function. Instead, the replier has to cut and paste this block of text from the message he's replying to and put it in the right place in his own message. And he has to be instructed in how to do this. (Karl's script adds the instructions when it creates the return address.) This is pretty complicated. This is why Eli suggested (based on suggestions from Eric Hughes) that at least Julf's remailer be enhanced so instead of just mapping, say, an12345 to joe@foo.com, it would map to a Cypherpunks return address of the type Will is describing - a block of encrypted text. People could then have the convenience of automatic replies to an12345 along with the security of a chained address. I don't think the idea quite works in this form, since I don't see how messages to Julf get translated to an12345. Presumably only messages from one specific user should get posted under this ID (the user whose address is buried in the encrypted return address to which Julf's remailer will forward replies). Perhaps another set of commands is needed to tell the remailer what ID to use to post under. By the time you do this much I don't think that what you have bears much resemblence to Julf's current software. I am stymied in doing experimentation in this area by one fundamental problem. I do not have the power to create user ID's on any systems which I use, so I can't create pseudonym accounts. I have tried various tricks. For example, I sent mail with a "Reply-To:" of "hal@alumni.caltech.edu (Pseudonym 12345)". I hoped that if someone did a reply to this mail, it might come to me with that whole field in the "To" line, and I could then parse it for the pseudonym number. That didn't work on the particular reply mailer that I used; it stripped the comment field in parentheses. The one other idea I've had is to put something at the beginning of the Subject: line, so if the user remailed a message with a Subject: of "How's it going, Jack?" it would actually go out as "Subject: (P12345) How's it going, Jack?". Then when they reply it will probably come back as "Subject: Re: (P12345) How's it going, Jack?" or something similar, and I can parse for the (Pxxxxx). This might work pretty often but munging the Subject line is bad for news posting since a lot of news readers sort by subject line. I could put the (Pxxxxx) at the end but it might get truncated? Maybe not. I wonder if anyone knowledgable in mail systems could suggest a relatively robust way of setting up outgoing headers so that return mail will (A) come back to me (hal@alumni.caltech.edu in this case) and (B) be marked in some unique way that would let me do a pseudonym mapping. Any ideas would be appreciated. Hal Finney 74076.1041@compuserve.com
From: Hal <74076.1041@CompuServe.COM> I don't think the idea quite works in this form, since I don't see how messages to Julf get translated to an12345. Presumably only messages from one specific user should get posted under this ID (the user whose address is buried in the encrypted return address to which Julf's remailer will forward replies). Perhaps another set of commands is needed to tell the remailer what ID to use to post under.
I don't know what Eric was thinking, but I was thinking as follows: * I send a message to the nymserver, telling it to create a nym entry. The body of the message is a public key. All further commands to the server must be signed by this key. * I then send a message to the nymserver, telling it to add a return block to the nym's list of return addresses. (signed) * Another (signed) command sets up a human-readable name, if I wish. Now we're in business. * Joe User sends a message to eli-alias@nymserver. The server looks up eli-alias, picks the preferred return path, and richochets the message out. * or, I tell the nymserver to post vitriol to alt.fan.clinton under the name "eli-alias". Again, the command must be correctly signed. (Can PGP let me rename my eli-alias private key to something innocuous -- like "test3"? This would provide some deniability if they seize my secring.pgp -- they need no passphrase to see the names of the keys on it. Denied this information, can `they' associate private and public keys in some way?) Hopefully, all commands to the nymserver would be encrypted with its public key. They might well be bounced to it through anonymous remailers, or sent with whatever other anonymity tech -- such as DC-nets -- is available. Yanek, were you setting up an experimental DC-net? How's it look? Any holes here? The requirement of a signature on all commands is parallel to the present use of a password, but far more secure. It provides continuity of identity, rather than the present use of return address. Attack this protocol, folks. Now, this does look like a lot of hair to add to penet. Maybe I should learn perl and write a remailer. Heh. (Aside: anybody here running linux? Do you know of a non-destructive repartitioner?)
Hal Finney
Eli ebrandt@jarthur.claremont.edu (with a big disk and a small flaky tape drive)
participants (2)
-
Eli Brandt
-
Hal