- cypherpunks-legacy@lists.ogf.org

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

chaining remailers...
by Karl L. Barrus 07 Jan '93

07 Jan '93

Geez, I can't beleive I forgot to consider that responding to me will result in a steady stream of anonymous id allocations. Guess I was caught sleeping on that one! Back to the better cryptographically protected cypherpunk remailers and Hal's "constructed" anonymous addresses...and I better ask the administrators at pax and penet to wipe out some allocated id's :-) /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0

Chaining remailers.
by Hal 07 Jan '93

07 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- It was interesting to see Karl Barrus's efforts to chain the Pax and Penet remailers. I think one of his problems is this: If I reply to one of Karl's double-remailed aliases, I will get assigned two anonymous aliases - one from each of pax and penet. The first machine I send to will assign me an anonymous alias, and forward my mail on, with a "From:" indicating that same new alias. The second machine will then see mail coming in from that new alias, assign me an alias for that, and send it back to me (via the first machine). That's why Karl got an extra alias in some of his tests that he wasn't expecting. It also means that the fact that he is using a double remailing alias will be revealed to anyone who chooses to send to him. I think the lesson is that this process of automatic alias assignment may not be the best way to handle things. It sounds attractive and simple, but look at all the problems Karl ran into. And if you're using a chain of remailers for an anonymous address, you really don't want everyone who sends to you to find out exactly what chain you are using. 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. Then, I need some way to put that address into the return field of my mail that I send. If this were possible, then person A could post a message, with his headers set so that replies will go to this anonymous address. And if person B wanted to send to A, he could, using A's anonymous address, and B could arrange it so that B's own anonymous address would go into the outgoing headers. A and B could then communicate using two completely different paths, both anonymously. A could go from pax to penet to B, and B could go from menudo to rebma to A. Each user would establish his anonymous address in the way he preferred. I think this is probably a better system than all this automatic assignment of anonymous aliases. It seems simpler and it should still be easy to use. The automatic systems tend to get out of hand. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0xuQagTA69YIUw3AQEGXAP/XxoWGmnMOm7E0d70uRGuwqHpG8KPzopk uERMjltmE1Xug7auzmFYKEV1I24DZyd3ClaDyoZQWpI79dTLQfnEPOHqhgXD8Ul4 PgYo5Gyf2yKIv5kbsmetWnAB23oDeyuE6HR9X5vl/MNWq38exbRlt8I303FtXQCi foIUiShHcaA= =0k6V -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

1 0

mh wrapper
by shipley＠merde.dis.org 07 Jan '93

07 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- here is my first pass (a 7min hack) at a wrapper for a pgp<->mh use. the next verion will me a replacement for the editor to automaticly sign the body of a file (while leaving the header alone. ===== CUT HERE ==== #!/bin/sh #pgpcomp - pgp compose # Peter M. Shipley (Wed Jan 6 17:58:41 PST 1993) umask 7077 TEMP=${TEMP-/tmp} EDITOR=${EDITOR-/usr/ucb/vi} whatnow=/usr/local/mh-6.7/bin/whatnow export TEMP EDITOR tempfile=$TEMP/pgp$$ /bin/cat << EEOOFF > $tempfile To: cc: Fcc: +drafts Subject: Precedence: special-delivery - -------- EEOOFF $EDITOR $tempfile /bin/sed "/^--------/,$ d" < $tempfile > ${tempfile}.head /bin/sed "1,/^--------/d" < $tempfile > ${tempfile}.body /usr/local/bin/pgp -sta +clearsig=on $tempfile.body -o $tempfile.signed /bin/mv ${tempfile}.head ${tempfile} /bin/cat << EEOOFF >> ${tempfile} - -------- EEOOFF /bin/cat < $tempfile.signed.asc >> ${tempfile} /bin/rm -f ${tempfile}.* exec $whatnow -prom "pgpsend> " $tempfile ===== CUT HERE ==== -----BEGIN PGP SIGNATURE----- Version: 2.1 iQBFAgUBK0uPgMhmn7GUWLLFAQH7MAF9EuCX3ZAauG771viwGmnyk4YaiNDFhpmr ann0Qvd6hVhTOnbSZNKet3Z9i0FUnDDu =40PL -----END PGP SIGNATURE-----

1 0

discussion desired
by mkagalen＠lynx.dac.northeastern.edu 07 Jan '93

07 Jan '93

I'd appreciate greately your enlightened opinions on the following article. (disclaimer : I have no qualification in the Great Science of Cryptology(tm) ; I'm just posting someone's e-mail) About using the electronic signature for protection of commercial information: The analysis of PGP ver.2.0 program. --------------------------------------------------------------------- THE MOSCOW STATE UNIVERSITY named after m.V. Lomonosov ______________________________________________________________ THE MATHEMATICAL CRYPTOGRAPHY PROBLEMS LABORATORY The MSU mathematical cryptography problems laboratory employeers with some addition specialists were executed the preliminary analysis of PGP ver.2.0 program. The preliminary study of working and program source code analysis result in following PGP features and problems: 1. The common character problems - the sequence of random numbers has strong prevalences on bytes (up to 0.05 ... 0.1 on material of 10000 byte) and strong correlation dependence between contiguous bytes; - the program doesn't check it's own integrity, so it can be infected by "virus" which intercept confidential keys and passwords used for their protection and save them onto magnetic carriers; - the program has not optimal exponentiation algorithm in GF(P) field, when P - prime number, which result in low performance; 2. The RSA algorithm realization problems - the prime numbers reception using in this program (R and q in RSA algorithm) permits not less than on two order to reduce the labour-intensiveness of factorization; with 256 bit blocks of data lenght it is possible to execute the cryptanalysis in real time; - before using RSA the program executes compression and block encryption that positively affects on the common stability encryption. 3. The electronic signature problems - for signature calculation the program originally executes hashing of file into number of given length (256, 512 or 1024 bit), but hashing function does not corresponds the ISO recommendations; - when considering the hashing function as the automatic device without output, it is enough simply possible to construct the image of reverse automatic device and with using the blanks in text files (or free fields in some standard formats as in DBF), to compensate the hashing function at changed file to former significance. Thus, it is possible to forge the electronic signature without analysis of RSA algorithm. 4. The block encryption algorithm problems - when executing analysis on plaintext and ciphertext the linear correlation dependences with encryption key were founded (0.01 and more degree); - also the effective method of decreasing security which reduces the order of time necessery to key definition in two times in comparison with exhaustive search of all keys (i.e. algorithm has the labour-intensiveness which is equal the root square from labour-intensiveness of the exhaustive search algorithm) have been found. The conclusions: It is recommended to use encryption with 1024 bit key length. The using of electronic signature is not recommended and requires the additional study. The block encryption algorithm has temporary stability. The hashing function should be reduce in conformity with ISO recommendations. The using of PGP program in actual version is undesired. The MSU mathematical cryptography problems Laboratory Manager Academician Dr. Sidelnikov V.M. ==END

1 0

Re: A solution remailer signature suppression
by edgar＠spectrx.Saigon.COM 06 Jan '93

06 Jan '93

Hugh Daniels said here on Dec 28: There are very good reasons to build remailers (and all mail tools) to pass on all the bytes they can, trailing spaces and .sigs included. Hugh doesn't say what these reasons are. They are not obvious to me, so I must disagree. I've already stated what I think are good reasons at least for remailers whose purpose is anonymity to remove automatic sigs which are likley to destroy anonymity. I've said I would accept either a less ambiguous sig delimiter than "--" or a remailer option to remove the sig (default) or leave it in. Might I sugjest that we set up the remailers with a feature where it tests mail sent from its owner to make sure there is no "compromising" content and that the outer shell verifies correctly, if it fails either of these tests it is dumped in a file and a note returned to you saying someings not right. Hugh doesn't say what criteria we are to use to detect "compromising" content (short of genuine AI) or what the outer shell is supposed to verify to. Why limit this test to the remailers "owner"? This system I use doesn't allow me to run my own software, so I think this idea wouldn't work for me, in any case. -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

4 4

Re: Remailer .sig suppressio
by edgar＠spectrx.Saigon.COM 06 Jan '93

06 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- I was glad to read Hal's comments of Jan 2 about sig suppression and his anecdote about trying to chain the penet and pax remailers. I was not aware til now that the penet sig test was any line which *starts with* "--". A more appropriate test would be any line *consisting of only* "--" (exactly two dashes). Do you know if the pax sig test is the same as penet's? I can't imagine any solution to your problem which does not involve changing either the remailer (tighter sig test) or PGP (recognize either ----- or - --- as starting a PGP message or key delimiter). The best solution so far appears to be Miron Cuperman's remailer which is similar to (based on) the cypherpunks remailer, but *requires* encrypted input and does not remail any unencrypted text which might preceed or follow the encrypted text. But some modification of Miron's remailer to process trailing plaintext seems to be necessary for ARA. I hope it will include some recognition of a well-defined unambiguous text delimiter such as - -----END OF MESSAGE BODY----- which will screen out any following text. John Gilmore commented on my request for sig suppression: Remove the file ".signature" from your home directory and you'll be done with *that* hassle. Well, my home directory doesn't *have" a ".signature" file! This is an MS-DOS based WAFFLE BBS. All the sigs on this system look the same so I suspect that they are made up from the user directory and some file outside my home directory. I am led to believe from the user doc that if I *create* a file "sig" or "mailsig" (no dots) in my home directory this may affect the auto sig produced, but I haven't had a chance to try it yet. My fear is that if I produce a null sig file that the "--" will still appear, making it obvious that the auto sig is nulled. If this "--" appears at the same time on both my regular and anonymous messages, people who see both may put two and two together. John: PS: An extra credit note for the differently clued among us: Suppose you wanted to have a *different* signature for each of your multiple identities? I guess the remailers had better not strip off signatures, eh? Since I make up my outgoing mail offline, I would prefer to copy in the correct sig corresponding to each message identity. That way I can see that the correct sig is matched with the correct msg in each case. I can easily avoid remailer stripping by using a delimiter like "**" instead of "--". As I said in a previous msg, the problem with auto sigs is reliably switching them as you send out (with an automatic script) messages from your different ID's. Since getting the wrong sig on the wrong msg could result in jail, under some circumstances, I consider this a serious problem. An "anonymous" remailer which allows a user to lose his anonymity through a simple lapse (forgetting about the auto sig) is one too dangerous for me to use. In another msg, John Gilmore delivers a long harangue about "Why mailers should not touch the body". I agree with the above phrase if we differentiate "mailers", which are necessary for the generation and forwarding of all mail, from "anonymous remailers", which have to be specifically requested by the message sender, and whose only purpose is to obscure the message origin. Since the automatic signature often reveals the message origin, it's quite compatible with the mission of an anonymous remailer to remove it. John doesn't want PGP changed to eliminate trailing blanks on signed plaintext. (Which I think would fix about 90+% of current problems verifying sigs). He wants us all to suffer until all the mailers in the world are fixed to pass 8-bit binary. Well, I won't hold my breath for that. I think UUENCODE and PGP armored form are going to be around a long time. I prefer a more pragmatic approach that will give more immediate relief. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0rOvt4nNf3ah8DHAQGBrQP+I9DKzknWE6sNTmYeSga3tQWv2IrHQPyc hnqgXXqwq6GRvOUvGXqHdig9jfXbatYh7uYuMqn61xP9409JXnNJZ7QQuB9vSNdz K5gvCKksPKjJoxAb5miDJvf61bS3N/bavl8gHM80DaRxv0n5UlzymLAvurZrL2qR ZxgCWhz9P3o= =CAUz -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0