- cypherpunks-legacy - lists.cpunks.org

Trailing blanks in signed plaintext
by edgar＠spectrx.Saigon.COM 09 Jan '93

09 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- Distribution: Cypherpunks <cypherpunks(a)toad.com> Branko Lankester <lankeste(a)fwi.uva.nl> I noticed something about PGP signed plaintext the last time used that feature to send a message to Cypherpunks. Apparently PGP takes any line beginning with 5 dashes ("-----") and adds "- " (dash blank) to it. I guess the purpose for this is to avoid confusion if the plaintext message should contain a PGP delimiter like -----BEGIN PGP SIGNATURE----- But in my particular case, what I specified in my input plaintext was -----END OF MESSAGE BODY----- (but with no indentation), but what came out was - -----END OF MESSAGE BODY----- Given that PGP is going to make changes like this to signed plaintext, I suggest there is no longer any reason to object if PGP also removes trailing blanks from signed plaintext. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK02ta94nNf3ah8DHAQFX8wP/dyusrml+2XH7XQtFcsQveGW3Zz3ib6K9 xGGV2hnvhwIHbFs4HIKTIVT0BFR6Y4SuqFMeF0BS16FIu47GmW8Q55iIhweDP7x5 +CUMXSynwQsz4XOMU/CpqNAwJifNoM9BwNu+RqfhIxwi6KxO1i3FwJjxPzE+uHkh Y7Mjl7Ytkd0= =0l/6 -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

Cascading Aliases
by mjr＠netcom.com 09 Jan '93

09 Jan '93

The discussion just above between Karl, Hal, Johan, and myself, has made me realize that the standard "bounce back" behavior of all the alias servers I've used so far actually defeates the purpose of remailer chains no matter how one embeds the forwarding information. When any person *first* replies to or originates mail across a remailer chain, a new alias is generated at each hop (however many). So far, that is good, a "most conservative assumption" approach, and it provides easily for reply channel maintenance. The problem is that each machine also reflects its new alias back along the chain to the message originator thereby revealing the entire chain to the message originator, something that might not be desirable to the party on the other side. The solution is very simple, just stop bouncing the new alias information back along the chain. This can not HURT anyone using the alias/remailer system because you never need to know what your aliases are as the conversion and forwarding process is automatic. If someone needs, for some reason to KNOW his alias for a given system (or all of them) on *his/her* chain, he/she can easily arrange to ping the server at the appropriate level. Besides not hurting any current operations, Stopping the *automatic* reply to sender about a new alias helps to secure everything a great deal more because it hides the "other guy's" chain, something that both parties might reasonably expect. matthew rapaport Philosopher/Programmer At Large KD6KVH mjr(a)netcom.com 70371.255(a)compuserve.com

1 0

New remailer in C.
by Hal 09 Jan '93

09 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- From: nowhere(a)bsu-cs.bsu.edu (Chael Hall) > Fellow Cypherpunks: > > I am working on a program in C that will provide both anonymous > remailing capabilities and mail server operations. It's good to see more people working on remailers. The cypherpunks remailers have been written in Perl, which facilitates experimenting and testing of new interfaces. The idea might be to migrate them to C eventually for efficiency, but during this experimental phase we may want to try out new ideas, and it's easier to modify a Perl script than a C program. > If you cannot add your own header lines with your mailer, set > the subject to contain "Request Remailing" and use the following format: > > :: > Request-Remailing-To: user@host > Subject: Anything you choose > :: > > Any of the following fields can be placed within the "::" delimiters: > > Request-Remailing-To: > X-Anon-To: > Subject: > > The remailer is case insensitive and you can place the "::" lines > anywhere within the message. This is somewhat similar to the cypherpunks remailers; however, they accept the :: only at the beginning of the message, allow any fields to be put there that the user desires (not just those three), and terminate the block by a blank line. Does your alternate system have some advantages? > I forgot to add: If you are chaining remailers, you can use the > sequence "+::+" at the beginning of the line to pass the remaining characters > on that line through the remailer untouched. I do find the use of this string to produce rather complicated looking commands. The cypherpunks remailers get the same effect by just putting in blocks starting with :: and separated by blank lines: :: Anon-To: anon(a)anon.penet.fi :: Anon-To: nowhere(a)bsu-cs.bsu.edu This looks simpler to me. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK05WUagTA69YIUw3AQGpaAP+LxpocNUI1/Zw3DAwwAxeKBtdj0sSyx8p 05xnI3FmklosxapVpcF/aVkDKL/FjzwBZ9ML5wt2m7UvqS1iX9UILQByPNAxTOKF TIuFKkjt2wT5ykvHRGLl6ZAB6w6PzkNiclHNJw4FFEaFzoxmnz3bQXatKBFFgGFd IjIMFF0d0Ig= =ztz0 -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

2 1

Cascading Aliases
by mjr＠netcom.com 09 Jan '93

09 Jan '93

****** Hal <74076.1041(a)CompuServe.COM> ***** >My understanding was that everyone who tried to talk to him would get >two aliases assigned automatically. Yes I suppose, but I can ignore them. Let's see if I got this right. In the following scenario, I will represent alias servers and their aliases in the following way: A-123 where 'A' is the server, and '123' is the alias. I receive a message from Z-999. I have no idea how many servers this has gone through. I *originate* a message back to this person, but I sent it first through *my* preferred alias chain, so the message goes from me through A-123 -> B-456 -> Z-999 and then somewhere else (perhaps) before reaching its final destination. Now the Z server has never seen a message from B-456, so it automatically generates a NEW alias (Z-111) for that ID. Now machine Z bounces that new alias back along the chain B-456 -> A-123 and thence to me, informing me that an alias has been established on machine Z for my ID on machine B. It also uses that alias to send the message along to the next machine on the chain (if there is one) which also creates a new alias (never having seen a message from Z-111), and bounces it back, etc. I see that this is where I get to detect the alias path my recipient is using, but there is an easy solution (see below). So one or more new aliases will be generated (you are correct) in response to my original mail, BUT, I can ignore those aliases (once I receive them in the reflected mail) and never need think about them again because the link between B-456 and Z-111 is now established. Further translation will take place automatically with no further bounce backs in any future correspondence between the two parties *if* they both use their own chosen mail paths consistently. If in my next mail, however, I REPLY to Z-999 (i.e. I don't generate original mail), then another alias will be generated on the Z machine for mjr(a)netcom.com and I will also be informed of that, etc. Once again, however, I don't have to care about that. From the recipients viewpoint, however, mail has now been received from two different aliases that represent the same person (one for my original mail, and one for my REPLIES) There are two possible solutions while still generating automatic aliases: 1) Don't alias someone who hasn't specifically requested it (e.g. with a ping or something). This is probably not a good idea. I like the fact that these Aservers take a "most conservative approach" automatically assuming that someone wants to be aliased if they are originating/replying to an aliased ID. 2) Stop the alias-information-bounce-back unless someone specifically requests it (e.g. with a ping). This might do the trick. I don't have to KNOW what my alias number is even on the machine that does the first outbound and last inbound conversion. All the conversions along the chain are automatic, so why should I care what my alias numbers are? matthew rapaport Philosopher/Programmer At Large KD6KVH mjr(a)netcom.com 70371.255(a)compuserve.com

1 0

Russian analysis of PGP
by karn＠qualcomm.com 09 Jan '93

09 Jan '93

Anybody familiar with the internals of PGP care to comment on this item that just showed up on sci.crypt? It's amazing to think that the famous "kremvax" joke was only a decade ago. Now the Russians are openly reviewing our cryptosystems for us. May you live in interesting times. Phil

3 2

Chaining addresses...
by Hal 09 Jan '93

09 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- From: mjr(a)netcom.com (Matthew Rapaport) > >I think the lesson is that this process of automatic alias assignment > >may not be the best way to handle things... look at all the problems > >Karl ran into. > > If I understand Karl right, he got this cascade of aliases because he > tried to talk to HIMSELF through different accounts/aliases at alternate > ends of the chain. Since no one would want to do that (other than to > test things) normally, this wouldn't be a problem. My understanding was that everyone who tried to talk to him would get two aliases assigned automatically. Karl made the problem worse by talking to himself from two different addresses, but you're still talking about a lot of aliases. > >I still lean towards the idea of a "constructed" anonymous address, > >where I decide ahead of time which remailers I'll use, and in what > >order. > > But I already *do* control the order of use for MY mail, that means > stuff I send out and stuff people send to me in DIRECT reply to my > stuff. There is nothing to stop someone from sending to my id on pax say > through a first remailer of their own choice, provided they originate > the mail (i.e. a REPLY is not equivalent to ORIGINAL mail in this case). OK, so you can set up an anonymous address which, say, goes through pax and then penet and then to you. If someone replies to that address, they will be anonymous to you, by default; their anonymous address will go through penet and then pax. But if they didn't want that anonymous address, they could use one of their own (say, rebma to soda to themselves) first, then go to your address. Now when you reply to them, I guess your message will go through penet, then pax, then rebma, then soda, then to them. My feeling was it would be better if they could put a Reply-To: into the message that just meant to go to rebma then to soda to themselves, and get that Reply-To: to go through the pax-to-penet chain to you. Also, they would not get anonymous ID's assigned by penet and pax, ideally. Instead, you would reply to them using this Reply-To address and go through just rebma and soda to get to them. This will be simpler and faster than having all messages go through the union of both communicant's anonymous address chains. > As for picking my own alias, this sounds appealing but is actually much > weaker then a randomly assigned one. Besides that, it could be an > administrative nightmare for the sysadmins on the aliasing systems. I wasn't really talking about picking my own alias. It is more a matter of having a straightforward way to construct an anonymous address that goes through the specific chain of systems that I choose. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK05Wa6gTA69YIUw3AQFy+QP/RAepMQETJWqM7szQ9ID0TAgrIvQc8ArH MX6S14lzb492skAIathLYllfyhN2TTO/gN+lCC4lvnzs9UOLJ2rlNzFxT8geV1yx MxKKzIZ39tMmyCXHx2cnH7ySHMoEVzp5TqXqQhEbmqn0k6c7hoL+sz6l43/g6rPL g++F+kRs2nQ= =0OfU -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

1 0

Alias cascades
by mjr＠netcom.com 09 Jan '93

09 Jan '93

****** Hal <74076.1041(a)CompuServe.COM> ****** >I think the lesson is that this process of automatic alias assignment >may not be the best way to handle things... look at all the problems >Karl ran into. If I understand Karl right, he got this cascade of aliases because he tried to talk to HIMSELF through different accounts/aliases at alternate ends of the chain. Since no one would want to do that (other than to test things) normally, this wouldn't be a problem. >I still lean towards the idea of a "constructed" anonymous address, >where I decide ahead of time which remailers I'll use, and in what >order. But I already *do* control the order of use for MY mail, that means stuff I send out and stuff people send to me in DIRECT reply to my stuff. There is nothing to stop someone from sending to my id on pax say through a first remailer of their own choice, provided they originate the mail (i.e. a REPLY is not equivalent to ORIGINAL mail in this case). As for picking my own alias, this sounds appealing but is actually much weaker then a randomly assigned one. Besides that, it could be an administrative nightmare for the sysadmins on the aliasing systems. matthew rapaport Philosopher/Programmer At Large KD6KVH mjr(a)netcom.com 70371.255(a)compuserve.com

1 0

New Remailer (more)
by nowhere＠bsu-cs.bsu.edu 09 Jan '93

09 Jan '93

I forgot to add: If you are chaining remailers, you can use the sequence "+::+" at the beginning of the line to pass the remaining characters on that line through the remailer untouched. For example: Message sent to this remailer: ----------v :: X-Anon-To: anon(a)anon.penet.fi :: +::+:: X-Anon-To: nowhere(a)bsu-cs.bsu.edu +::+:: beginning of text... ----------^ Message sent to anon.penet.fi: ----------v :: X-Anon-To: nowhere(a)bsu-cs.bsu.edu :: beginning of text... ----------^ Chael Hall Chael Hall | Campus Phone Number nowhere(a)bsu-cs.bsu.edu | (317) 285-3648 00CCHALL(a)bsuvax1.bitnet | 00CCHALL(a)LEO.BSUVC.BSU.EDU | "I hate it when that happens!"

1 0

New Remailer
by nowhere＠bsu-cs.bsu.edu 09 Jan '93

09 Jan '93

Fellow Cypherpunks: I am working on a program in C that will provide both anonymous remailing capabilities and mail server operations. In order to better test the software I have installed it on my account through my .forward and .maildelivery files so that all messages received with a header line "X-Anon-To" or "Request-Remailing-To" will be remailed to the appropriate address. If you cannot add your own header lines with your mailer, set the subject to contain "Request Remailing" and use the following format: :: Request-Remailing-To: user@host Subject: Anything you choose :: Any of the following fields can be placed within the "::" delimiters: Request-Remailing-To: X-Anon-To: Subject: The remailer is case insensitive and you can place the "::" lines anywhere within the message. Signature stripping is NOT supported, however a "kill line" will be implemented soon so that you can halt message processing beyond a certain point. Message body processors are supported as an add-on feature. PGP support would work as a message processor. On my end, I can define a "start processing" line and a "stop processing" line. Only text between (and including) those lines will be passed to the message processor. Unfortunately, PGP is not installed on this system, so support will have to wait. I will post full specifications later. Plesae let me know of any ambiguities. Please also note that I am keeping detailed logs of the use of this software for testing purposes, but I would rather delete all logs than provide them to authorities. The remailer is run on a multi-user system for which I do not have a privileged account. Chael Hall Chael Hall | Campus Phone Number nowhere(a)bsu-cs.bsu.edu | (317) 285-3648 00CCHALL(a)bsuvax1.bitnet | 00CCHALL(a)LEO.BSUVC.BSU.EDU | "I hate it when that happens!"

1 0

double anonymity via pax and penet
by Karl L. Barrus 07 Jan '93

07 Jan '93

Cypherpunks, I've been toying lately with "tying" the remailers at pax and penet together. Briefly, the anonymous service at anon.penet.fi supports anonymous remailing (but you must register your id), anonymous posting, and anonymous forwarding. The remailer at pax.tpa.com.au support anonymous remailing (runs pgp, must register your key for encryption service) and anonymous posting. For more info, get the help files by mailing to help(a)anon.penet.fi and anon.info(a)pax.tpa.com.au. Anyway, my idea is as follows: somehow get one of these services to establish an id on the other one, and also establish a path back to you. Then, you should be able to receive mail by having it sent to an anonymous id on one of the services, which will then forward it to another anonymous id on the other service, which will then forward to you. Of course, as cypherpunks, we have several of our own cryptographically protected remailers, but I thought I'd explore using these others ones also. If you don't have an id already established on either service, you can get one by simple trying to use it (for example, posting a message). Since the remailer at anon.penet.fi allows anonymous forwarding (using the % notation), I established a double system as follows: (for convenience I shall reveal the anonymous id's I was assigned by this test procedure; @penet shall mean @anon.penet.fi and @pax shall mean @pax.tpa.com.au) I mailed to anon.post.alt.test%pax.tpa.com.au(a)anon.penet.fi from barrus(a)tree.egr.uh.edu. This went to anon.penet.fi, where I was allocated an anonymous id for barrus@tree. The id I was given for barrus@tree was an5022@penet. Then, penet forwarded to anon.post.alt.test(a)pax.tpa.com.au (because of the % notation), which resulted in two things: a post to alt.test, and the establishing of an id on pax for the anonymous id on penet - anon.435@pax. After a few minutes, I recieved acknowledgment of my post to alt.test, sent from penet. So pax sent the acknowledgement to the anonymous id at penet, which then sent it to me - barrus@tree. I also watched for my post to alt.test to appear, which it did. So now, mail sent to anon.435@pax gets forwarded to me via penet. Then, I tried the process in reverse. I sent to the anonymous pax allocated from my other account (elee9sf(a)menudo.uh.edu) I sent from the other account because I already have an anonymous id for that one, and I wanted to keep new account allocation to a minimum, but as it turns out I think I messed up. Anyway, the mail I sent made it to barrus@tree (via pax and penet), but I was allocated another anonymous id from penet (an5030@penet), and the notice came to elee9sf! After thinking about it some more, I realized that what that acknowledgement must be. When I mailed to anon.435@pax from elee9sf, I wasn't allocated an anonymous id because I have one. So pax sent the message to an5022@penet. But penet hadn't seen a message from anon.435@pax, so it allocated another id, and sent to acknowledgement back to anon.435@pax. But for some reason, the remailer at pax didn't send this to an5022@penet - it jumped it and responded to my account elee9sf(a)menudo.uh.edu. So the pax service seems fairly intelligent. Or there is a bug :-) Then, I tried to mail to anon.435@pax from barrus@tree. I thought I would be assigned an anonymous id at pax for barrus@tree, but I wasn't. Actually, for some reason, I was mailed the acknowledgement of yet another anonymous id, an5047@penet! But, my original goal was to establish an anonymous id on pax which would forward to an anonymous id on penet (and vice versa), and I succeeded: mail sent to anon.435@pax goes to barrus@tree via penet mail sent to an5030@penet goes to elee9sf@menudo via pax as an unplanned effect: mail sent to anon.437@pax goes to elee9sf@menudo via penet mail sent to an5047@penet goes to barrus@tree via pax These are the anonymous id's I beleive I've generated because of this procedure: an5022@penet, an5030@penet, an5047@penet (I don't understand this one), anon.435@pax, anon.437@pax (I don't understand this one either). I figured I would use four id's: one from penet for barrus@tree, one from pax for barrus@tree, one from penet for pax, and one from pax for penet. For some reason, when I mail to anon.437@pax or an5047@penet from barrus@tree, the mail doesn't arrive in either of my accounts. So I'm still trying to sort out this mess before I mail to the administrators at both sites, explain what happened, and have these various id's deleted. Anybody with an id already established on pax or penet is welcome to mail to me at anon.208@pax or an5030@penet to help me figure out if it worked (I've run out of accounts to test this from and I don't want to involve elee7h5@rosebud where I'm running a remailer). I think the step I may have erred was mailing to anon.435@pax from elee9sf, where I have an id. Maybe by mailing from barrus@tree I would have been assigned an id, and recieved acknowledgement of an id from penet for the id at pax, and possibly an5047@penet wouldn't have been generated. Some uses of this I can think of are of course mailing via cypherpunk remailers to the first link in the pax/penet remailers chain. This would hide our remailers from others, since pax and penet are well known anonymous services. I haven't thought of a way to send messages (other than posting to usenet) via pax/penet. So I could post a message, as described above, and collect responses via a double anonymous reply. Anyway, what do you think?? Any ideas or suggestions? /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

2 1