- cypherpunks-legacy - lists.cpunks.org

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

RSAREF now available via anonymous FTP (fwd))
by yanek＠novavax.nova.edu 06 Jan '93

06 Jan '93

In case someone's interested: Forwarded message: > Date: Tue, 5 Jan 93 17:15:58 PST > Message-Id: <9301060115.AA18302(a)RSA.COM> > To: rsaref-users(a)RSA.COM > From: burt(a)RSA.COM > Subject: RSAREF now available via anonymous FTP > Sender: rsaref-users-request(a)RSA.COM > > Dear RSAREF user -- > > RSAREF is now available via anonymous FTP to 'rsa.com'. Along with > RSAREF you can get RIPEM, Mark Riordan's RSAREF-based privacy-enhanced > mail application, and an Emacs command interface to RIPEM. See the > file 'README' in the FTP directory 'rsaref' for more information. > > -- Burt Kaliski > RSA Laboratories > -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek(a)novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819

1 0

Re: purloined letter -- mimic functions
by wcs＠anchor.ho.att.com 05 Jan '93

05 Jan '93

Peter Wayner sent along the following note about mimic functions: ------- cut here ------ Original-From: wayner(a)cs.cornell.edu (Peter Wayner) Cool. I'm not a member of the mailing list. You can tell them if they want a copy of the code they should send me a note. They can get it in either C or Pascal. The C comes with tar wrapping paper for the faux industrial tech look. (I can't wait until Crate and Barrel start mining the Civil Defencse era for new retro-trendy styles. ) -Peter ------ cut here ------- At the risk of sounding like Peter G Neumann, I should comment that the combination of mimic functions and Mime mail could lead to lots of silliness and hand-waving .... Bill

1 0

Re: Anonymous thanks ;-)
by Mark Turner 05 Jan '93

05 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- On Tue, 05 Jan 93 11:00:49 BST, "Russell E. Whitaker" <whitaker(a)eternity.demon.co.uk> wrote: > In the meantime, Mark Turner (mt(a)kram.org) is hard at work 1.) > porting PGP to 386BSD and 2.) developing a telnettable PGP Key > Server. Details as they happen. I was beaten too it with the port by Graham Toal (gtoal(a)gtoal.com) and Adrian Hall (adrian(a)rachel.ibmpcug.co.uk) It's available for anon ftp from rachel.ibmpcug.co.uk:/usr/local/src/pgp. Regards, Mark. p.s. I'll announce the PGP server here once it's fully operational. It will also have a mail server. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0n6NUER4WTv6d3nAQHorAP/ekT7fQYOSBBuS3vcBXJ7FG7RtwoID8QP NxspuGGrXcFSkKR4pCIzAArhWpxN3/gIqELiMQuEF2oGkzVomZBxmnyXvQxOjTtl e1x42EISp06qgMplwx4xu1FyPtF00BYI+WLlzeELvJ4DEvej8A5o+WVqQyjn8Ah7 /fAWIx4JSaE= =/ja0 -----END PGP SIGNATURE----- -- /\/\ark Turner Demon Systems / Demon Internet Office: mark(a)demon.co.uk (+44 81 349 0063) 42 Hendon Lane, London Home: mt(a)kram.org (+44 831 823 212) N3 1TT, England ------------------ PGP version 2.1 Public Key available ------------------- *** IP level dial-up connectivity to the Internet for a tenner a month! ***

1 0

Anonymous thanks ;-)
by whitaker＠eternity.demon.co.uk 05 Jan '93

05 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- Some kind U.S. cypherpunk sent me a copy of his public keyring last week. Unfortunately - mea culpa! - after having integrated his keyring, I deleted his original message from my mailbase, and thus lost his contact info. I wish to thank this person for sending the keyring, whoever you are... my memory is faulty: so much email to catch up on! In the meantime, Mark Turner (mt(a)kram.org) is hard at work 1.) porting PGP to 386BSD and 2.) developing a telnettable PGP Key Server. Details as they happen. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0lqRITj7/vxxWtPAQGKeQQAo45IcgvBRON49bxyRtPSyHEpi4InsXQA oNxAE+iN+mGTRYRov8a9twgPXp+i7YHv+Xx+A8+c0ZilJV/954uPFy22xAqxl+4P kpUaITTt+oo/3no7g2cBPC2JhOZS7QTkokBvILhoofjNzRZJ+qTUScpyZ4QVlRvP smkZ8WWQg6o= =uvOA -----END PGP SIGNATURE----- Russell Earl Whitaker whitaker(a)eternity.demon.co.uk Communications Editor 71750.2413(a)compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available =======================

1 0