- cypherpunks-legacy - lists.cpunks.org

alt.hackers post
by Eric Hughes 28 Mar '93

28 Mar '93

Here's the other one Eric ----------------------------------------------------------------------------- From: hughes(a)soda.berkeley.edu (Eric Hughes) Newsgroups: alt.hackers Subject: a new feature of the remailer Message-ID: <HUGHES.92Oct9095848(a)soda.berkeley.edu> Date: 9 Oct 92 13:58:48 GMT Distribution: alt Organization: /accounts/hughes/.organization Lines: 191 Here is the third in the series of articles on the remailer. Remember, these are meant to be fairly tutorial. Eric ----------------------------------------------------------------------------- There's a new feature in the remailing software. Some people can't add arbitrary header fields because of mailer or gateway restrictions. This restricts them from using the remailer. I have added a facility to allow new header fields to be pasted onto the end of a header when the mail arrives. This effectively happens before processing by the remailer software. These new fields exist during transit in the message body, where they remain untouched. Only after the message is delivered to my account does this operator take effect. Syntax: If the first line of the body is the two characters "::", then the following lines are appended to the header, up to the next blank line. Here's how it works. First of all, here's my new .maildelivery file: ------- cut here ------- # # field pattern action/ string # result (quote included spaces) # Request-Remailing-To "" pipe R "perl remailer/remail.perl" Request-Remailing-To "" file R remailer/archive * "" pipe R "/usr/local/lib/mh/rcvtty -biff" * "" pipe ? "perl remailer/incoming.header.perl" ------- cut here ------- Comments are indicated by #. The Request-Remailing-To lines have been there. The second of the makes an archive for debugging purposes. It will go eventually. The third field, "*", indicates all fields, it runs 'rcvtty' on my mail; this replaces the function of biff, since mail is getting piped to slocal now, disabling biff. The last line is the important one. It says "If the mail hasn't been delivered by now, run the incoming header rewrite script on it. If that doesn't work, continue trying to deliver it." Now here's the trick. slocal has no way of taking the output of the rewrite and continuing to process it. (It should. It would make this whole job easy.) So in order to continue processing, you need to redeliver the mail. You could invoke sendmail and mail it back to yourself, but that would mangle the existing header. So the thing to do is to recursively invoke slocal from within the perl script. Here's the perl script to do all this: ------- cut here ------- # First read in the whole header. # We check for the Second-Pass: line to detect infinite loops. while (<>) { last if /^$/ ; exit 1 if /^Second-Pass:/ ; $header .= $_ ; } # We have just read the last line in the header. # Now we check to see if there is a pasting operator. if ( ( $_ = <> ) && /^::$/ ) { while (<>) { last if /^$/ ; $header .= $_ ; } } else { # There is either an empty body or no pasting operator # Thus exit with a return code of 1 to indicate that # the mail has not been delivered. exit 1 ; } # There was a header pasting operator. # So we open 'slocal' as a pipe, effectively redelivering the mail # back to ourselves. #open( OUTPUT, ">foo" ) ; open( OUTPUT, "| /usr/local/lib/mh/slocal -user hughes" ) ; select( OUTPUT ) ; # print a "From " line to satisfy slocal @weekdays = ( "Sun","Mon","Tue","Wed","Thu","Fri", "Sat" ) ; @months = ( "Jan","Feb","Mar","Apr","May", "Jun","Jul","Aug","Sep","Oct","Nov","Dec" ) ; ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime ; printf "From hughes %s %s ", @weekdays[ $wday ], @months[ $mon ] ; printf "%2d %02d:%02d:%02d 19%d\n", $mday, $hour, $min, $sec, $year ; # Now just print out the message print $header ; print "Second-Pass:\n" ; print "\n" ; while (<>) { } continue { print ; } ------- cut here ------- Here's how the perl script works. The first loop reads lines from the existing header. When it sees a blank line (regexp /^$/) it terminates the loop. If it sees a field "Second-Pass", it knows it has filtered this message before and exits with a return code indicating that the mail has not been delivered. The variable $header is appended with the current header line. $header contains the whole header when the loop terminates. Properly speaking, the Second-Pass test is not necessary to detect infinite loops. Since the pasting operator gets removed during the rewrite, the script won't return an exit status of 0 more times than the pasting operator appears. But should something get screwed up, such as a different module adding pasting commands (how? I don't know), the Second-Pass test should prevent infinite recursion. The next statement reads another line from the input file. This line is the first line of the message body. If this line is the pasting operator, then header lines are accumulated in $header as before until a blank line. The difference is that these header lines are being read from the body of the message. If there is no pasting operator, the script exits undelivered. At this point we now have to redeliver the message back to ourselves. We first open slocal as the output pipe. The next section is a kludge. It turns out that slocal strips off the out-of-band "From " (no colon) line that the mail delivery system uses. In other words, the message which slocal pipes into its pipes is not identical to the message it itself received. This means that slocal cannot be directly recursed. What this section does is to create a "From " line to make slocal happy. It calls localtime() and then formats those numbers into the proper form. It turns out that slocal will deliver this mail without the "From " line, even to /usr/spool/mail, but it doesn't do so properly. On my system, in added some delimiters which I think I've tracked down to the 'mtstailor' file, namely mmdelivery1 and mmdelivery2. Since these are not null on my system, there's some garbage added which screws up separation of the spool file into messages. Adding a "From " line fixes that. This misbehavior may not be so surprising, considering that slocal was "meant" to be invoked only in a .forward file. Now we print the variable $header which contains the whole header, including newlines. Using a single string removes the need for an array. We added the Second-Pass line and a blank line for the end of the header. The final loop prints out the rest of the message body. There is another way to proceed to get the same functionality. One could write a filter to translate the first occurrence only of \n\n::\n into \n. We could then pass the message through this filter before slocal saw it. And for now, that would do the same thing. But suppose we want more that one rewrite rule active? Then you would only be able to apply each rewrite rule exactly once in fixed order. You want to be able to rewrite a message and then apply all the rewrite rules again. At least one other rewrite rule is planned: automatic decryption. Since decrypting a message will completely change the body, and since some of the header fields may need to be hidden, you have to be able to decrypt the body and then paste on header lines. But since you need to indicate an encrypted body by a header line (well, not really, but it's more reliable), and since some people can't add these header lines, you need to paste lines before encryption as well. Thus the rewrite rules need to be applied asyncronously and hence I'm using a fairly complex slocal scheme to do a simple filter. Eventually I hope to write an equivalent to slocal which knows about message rewrites and simple filters, but that's for later. ----------------------------------------------------------------------------- To follow this project (and others soon to be started), send mail to cypherpunks-request(a)toad.com and I'll add you to the mailing list. Eric

1 0

alt.hackers post
by Eric Hughes 28 Mar '93

28 Mar '93

Rusty Babani forwarded me my hackers postings from six months ago. Thanks! Here they are (in two messages). Eric ----------------------------------------------------------------------------- From: hughes(a)soda.berkeley.edu (Eric Hughes) Newsgroups: alt.hackers Subject: Remailer that will run on a user account Date: 25 Sep 92 16:17:25 GMT Distribution: alt Organization: /accounts/hughes/.organization Lines: 347 What follows are a couple of postings to the recently formed cypherpunks mailing list. They are tutorial in form because the list is not entirely hackers. Enjoy and deploy. Eric ============================================================================= How to Make an Automated Remailer in Your Copious Spare Time with Easy to Find and Inexpensive Software Tools You May Have Lying Around. <reprinted from Popular Cryptography, September 1992. Used with permission> The basic remailer illustrates how to hook in automated software processing into the Unix mail system. Here are the basic elements. 1. .forward 2. slocal and .maildelivery 3. remail.perl 4. /usr/lib/sendmail -------------------------------------------- 1. .forward Unix mail provides a way to have accounts on many different machines but to receive all your mail in one place. That facility is the .forward file, which resides in the home directory. The file is one line long and contains the email address to which the mail will be forwarded. But the .forward file has another mode of operation. If the string begins with the pipe character '|', the mail will be piped through the program listed. Enclose the string with double quotes if you need spaces included. Here is my .forward file: "| /usr/local/lib/mh/slocal -user hughes" Thus all my mail gets processed by the slocal program, described next. I don't know where the man page for .forward is. Perhaps someone could provide a reference. --------- 2. slocal and .maildelivery The software system MH contains a bunch of useful tools for handling mail, only one of which we need. For details on MH, do 'man mh'. MH has a nice little mail hook processor called slocal. Its docs can be found by 'man mhook'. slocal can conditionally perform operations on mail messages and consider them either delivered or not. It allows multiple operations on individual mail messages. slocal reads the file .maildelivery when it starts up for instructions. Here is my .maildelivery file: # # field pattern action/ string # result (quote included spaces) # Request-Remailing-To "" pipe R "perl remail.perl" Request-Remailing-To "" file R archive.remailer The various pieces of the .maildelivery file are fully documented in the man page. I'll just explain what mine does. Each line describes one operation to be performed on each incoming mail message. Fields are separated by whitespace, so if you need to include spaces, use quotes. The first field, labelled field, is the mail header field to look for. slocal can selectively process on any header line. If the header line does not exist, then the mail does not match this line and no operation is performed. If the header line does exist, processing continues. The second field, pattern, is a text string to match with the contents of that header line, i.e. with everything after the colon. In my case, I put the empty string in, which matches everything. You need the pair of quotes to have a placeholder for the field contents. The next field, action, tells what to do with the message. 'pipe' sends the message to the standard input of the named program. 'file' appends the message to an archive or log file. A useful pipe command for testing is "tee foo", which makes a copy of the message in file foo, but does not append, so that you get an exact copy of what slocal is going to pass to your pipe. This allows testing of the pipe program without sending yourself mail all the time. The next field, result, tells what to do with the message after processing. I am currently using R for Regardless to indicate that this action should always be performed no matter what. The code R indicates that the mail should be considered not delivered after processing; thus slocal writes the mail back into my local spool and I see it as normal. Later, after I'm sick of looking at all the forwarded mail, I'll change this code to A, meaning if the processing succeeds, then the mail is considered delivered. The archive file will always remain R. The last field, string, is the parameter to the action. It is a file name or program. Use quotes to include spaces. The name of my mail processor is "perl remail.perl", which is to run the perl script remail.perl on the mail. The .maildelivery file is also the place to put encryption hooks to automatically decrypt the bodies of messages. More on that in a future version. --------- 3. remail.perl Perl is a wonderful language for doing all sorts of useful work like processing mail headers. Do 'man perl' for details, or get the O'Reilly book and really learn how to use it. The perl script, in summary, strips off the mail headers, saving the Subject: line, rewrites a new header, and appends the body of the previous message. Here is the script: --------- cut here --------- while (<>) { last if /^$/ ; $subject = $_ if /^Subject:/ ; if (/^Request-Remailing-To:/) { chop ; s/^.*:// ; $addressee = $_ ; } } #open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ; open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ; select( OUTPUT ) ; print "To:" . $addressee . "\n" ; print "From: nobody\n" ; print $subject ; print "Remailed-By: Eric Hughes <hughes(a)soda.berkeley.edu>\n" ; print "\n" ; while (<>) { } continue { print ; } --------- cut here --------- Here is a summary of the operation. To really understand this, you'll have to learn perl. The while loop processes standard input. 'last' terminates the loop as soon as a blank line is seen. A blank line separates the header from the body. The subject line, if seen, sets the subject variable to the whole subject line. The Request- header line has its final newline removed, the contents up to the colon substituted into nonexistence, and saves the rest in the addressee variable. Next the pipe to sendmail is opened and its output is selected so that all print commands will go to the pipe. There is a comment for a different output channel to the file foo which can be commented in for testing. Next the remailed header is constructed out of print statements. Lastly the rest of the standard input is passed through unmodified to the output channel. The while loop terminates when there is no more input. --------- 4. sendmail sendmail is the backend mailer; it expects complete mail messages and does not usually generate any line itself except for the first "From" (with no colon) line. Any header you construct will thus get passed through mostly unmodified. Hence you can put in any "From:" line you want and any other header info, such as my "Remailed-By:" line. sendmail expects the name of the addressee on its command line, otherwise it puts an "Apparently-To:" line in the header. Any mail processor which remails should probably go through sendmail, although it would also be possible to talk to an SMTP port directly, were you so motivated. MH also has some remailing programs; see 'man mhook'. --------- A few words for tinkerers. -- You can always send mail to yourself. Especially after you've done one kind of mail processing and want to pass the mail through the filters again. -- When getting started, create an empty .maildelivery file first and then get your .forward file working. Test it by sending messages to yourself. If you're not getting them, they are going into the bit bucket. All your other mail will as well, in this case, so if you can't afford to lose mail, do it right the first time or work on a spare account. -- Any mail slocal does not process will get delivered as normal. Running a remailer will not interfere with your other work. -- Remember to use quote marks. -- You don't need to be a sysadmin to run this kind of remailer. There is nothing, however, to prevent a sysadmin from running this sofware under an alias. The sysadmin is also a 'trusted user' to sendmail and can get rid of pesky "From"-no-colon lines. -- Perl has a random function which could be used to automatically choose various "From:" lines from a database. Remember to include yeltsy(a)kremvax.rus. -- postnews or inews could be substituted for sendmail. Different header lines would have to be created. Such a service could run in parallel with a remailer. You too can now repost to alt.sex.bondage! Enjoy. And watch for interesting improvements like encryption. Eric ============================================================================= The hopping remailer is finished. I wrote it this morning. The change to make a hopping remailer is very easy. Here's the new perl script: --------- cut here --------- while (<>) { last if /^$/ ; $subject = $_ if /^Subject:/ ; if (/^Request-Remailing-To:/) { chop ; s/^.*:// ; $addressee = $_ ; } } #open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ; open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ; select( OUTPUT ) ; print "To:" . $addressee . "\n" ; print "From: nobody\n" ; print $subject ; print "Remailed-By: Eric Hughes <hughes(a)soda.berkeley.edu>\n" ; # # check to see if there are header lines in the body to collapse # into the full header. # if ( $_ = <> ) { if (/^##$/) { # do nothing if the pasting token appears # the rest of the body will be directly appended # this allows for extra header lines to be added } else { # normal line print "\n" ; print $_ ; } } else { # empty body exit ; } while (<>) { } continue { print ; } --------- cut here --------- Short explanation. The 'print "\n" ;' line was moved inside the new if statement. The if statement reads a line of the body and stops the script if there is no body. The line read is tested to see if it contains the two characters "##" alone on the line. "##" is the ANSI C token pasting operator. If there is no pasting, a blank line is printed to mark the end of the header and the first line of the body is printed. If there is pasting, then the conditional does nothing, which has the effect that the body is appended directly onto the end of the header, allowing you to add more header lines after the header is rewritten. Here is a sample message that I sent myself after the new script was installed: --------- cut here --------- To: hughes Subject: multiple hops Request-Remailing-To: hughes ## X-Hop: 1 Request-Remailing-To: hughes ## X-Hop: 2 Request-Remailing-To: hughes ## X-Hop: 3 This is a test message of multiple hops. Eric --------- cut here --------- I received four pieces of mail after sending this to myself. The first was the actual letter, which is still delivering normally and not being filtered. The next two were the first and second remailings; they had X-Hop: 1 and 2. The last message was the final one, had X-Hop: 3 in its header and was delivered normally. At each stage, the header got rewritten and a new Request-Remailing-To: line inserted. When that mail got delivered, it was again rewritten, with a new remailing request. This process is extensible up to the 50K or so practical limitatation on mail size. Note that this system is not at all secure by itself. But if each message body were encrypted first, and the message first decrypted before the header re-write took place, the routing instructions as a whole would be hidden from prying eyes. That's the next project. Eric ============================================================================= To be on the cyhperpunks mailing list, mail to cypherpunks-request(a)toad.com I'll put you on. Eric

1 0

ANON: Mark anon. posts a
by Hal 28 Mar '93

28 Mar '93

-----BEGIN PGP SIGNED MESSAGE----- I sent mail to Cypherpunks on this a couple of days ago, but it never appeared. There is a problem with the notion that all "anonymous" remailers and news-posting services should label their messages as anonymous so that users can decide whether to read them or not. This approach abandons one of the strongest arguments in favor of anonymous remailers, which is that the net is inherently an anonymous environment. Especially as more public access Unix systems, BBS systems, and so on become part of the net, we are going to see less and less of the strict controls on identity which were possible when the net was restricted to a few government labs and large universities. The level of anarchy will inevitably increase as larger numbers of people acquire net access. Unless massive and universal authentication efforts are undertaken, it is going to be more and more the case that you will know little about the true identity of a poster. Because of this, those who object to having to read the words of an "anonymous" poster are taking an untenable position. They are already reading words of people about whom they know no more than they would about an anonymous poster. And the argument that "non-anonymous" posters are subject to a form of discipline not available to anonymous posters - messages to the system operator - is clearly falsified by the existance of many sysops who care nothing about complaints. As more and more people run their own machines with net access, these cases will only increase. In short, we anonymous remailer operators have every right to be part of the net. We introduce no more problems than are already happening and will continue to occur as the net grows and becomes more universal. The resistance we've seen is from old-time sysops who are unable to adjust to a changing network environment. Rather than placating obsolete beliefs about network identity by agreeing to mark our messages with the scarlett letter A for anonymity, by accepting that we deserve to be in a ghetto set aside for inferior posts, I feel that we should challenge the net with messages that blur the distinction between anonymous and authenticated posts. The sooner people realize that there is no line that divides the clean from the unclean, the sooner anonymity will be widely accepted on the net. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK7S2oqgTA69YIUw3AQEfagP8DlzINcvUDn7jc351S+hHTBz5NtB3RbRC l+0rgltFcn6QxWaE0GsWFcOa6RcPOe1DOTlwiJejiT6MbnfuDopbUoS98bCiIzLE 0Q2ZVhtsfLs5zFdUj08bRzzU7zyuzSmNoSsCx01O6OiGZB/zs0PEnx/0XqRtXFD2 RM1YTCPIF7Y= =0zw5 -----END PGP SIGNATURE-----

2 1

ANON: real-person newsgroups
by Marc.Ringuette＠GS80.SP.CS.CMU.EDU 28 Mar '93

28 Mar '93

Hal Finney (I think) writes, > the net is inherently an anonymous environment. > ...The sooner people realize that there is > no line that divides the clean from the unclean, the sooner anonymity will > be widely accepted on the net. But there _is_ a line, and people will likely want to draw it. It's true that currently there aren't any security guarantees to prevent a person from pretending to be someone else, but there will be. PEM certificates will distinguish between real people and personas. A public-key-authenticated "real person newsgroup" can be implemented. This raises the possibility that most newsgroups will transition to real-person-only status. This will cramp the style of those of us who wish to participate in the net using a persona. I think a major task ahead of us is to provide an alternative to "real people = good, personas = bad", and to put forward alternatives to "real person newsgroups" which are tolerable to most and more palatable to us. So what's the distinction we might wish to put forward instead of "real person"? "Paying customer", perhaps, or "respected reputation"? Yeah, that sounds good. Maybe it's time to set up some reputation based newsgroups, with a means of keeping track of who has been posting good stuff, and of filtering for credibility. -- Marc Ringuette (mnr(a)cs.cmu.edu)

2 1

Speaking of TEMPEST....
by David Heck 28 Mar '93

28 Mar '93

I was able to procure a tempest specced HP Laserjet + (model 2686 TA), used around a year ago and recently did a motherboard swap to upgrade the unit to 2mb of RAM...wasn't all that much to rip apart and put back together...even with all the damn machined-screws and shielding, the thing still emits a fair amount of noise, but no farther than the room it's in... I checked all my cables and system box and switched to shielded cables and cleaned up the the noise as best I could...interesting design and at least I would see the damn snoops...they'd have to be in my front yard to pick it up...anyone else hack any used TEMPEST stuff? David a.k.a. Unixorn

3 2

Re: ANON: Shutdown of Anon.penet.fi
by nobody＠alumni.cco.caltech.edu 28 Mar '93

28 Mar '93

It is fruitless to try to guess the identity of the famous network personality. You only tar innocent people. The truth will come out, more likely sooner than later. Nowhere, Man

1 0

Re: TEMPEST in a teapot
by ghoast＠gnu.ai.mit.edu 28 Mar '93

28 Mar '93

> > ----- Begin Included Message ----- > > It is speculated that poorly protected systems can > be effectively monitored up to the order of one kilometer from the target > equipment. > > ----- End Included Message ----- > > The "readability" of the relatively high energy sweeps in a standard CRT monitor > is well known. Any idea of similar effects on LCD screens ? The energy involved > would be orders of magnitude less, just for starters. Also, since the whole screen > is effectively oscillating, I'm not sure that there is any 'raster' sweep per se > going on here at all. This could be a factor for the truly paranoid :-) using > portables with LCD screens. > > > Pete Carpenter pete(a)cirrus.com > I've been told that the CRT is not what is generating the signals at all, rather that it is the CPU, and that having an LCD screen won't save you, strength of signal reduced or otherwise.

2 1

REMAIL: Anon. remailers
by wixer!pacoid＠cactus.org 28 Mar '93

28 Mar '93

One alternative would be to use the technology within its own narrative.. If IP providers and other sysops are *annoyed* that an anonymous remailer passes "untraceable" email, why not have a remailer that passes email with a trail of encrypted SASE ?? That way, the identity of the person posting is preserved, albeit not the physical location.. pxn. pacoid(a)wixer.cactus.org

1 0

REMAIL: Anon. remailers
by Hal 27 Mar '93

27 Mar '93

-----BEGIN PGP SIGNED MESSAGE----- Kenneth G. Hagler, "Lord Krieg" <CVADSAAV(a)CSUPomona.Edu>, writes: > Joe Thomas has suggested that a group of penet-style anonymous servers > be set up to act as "front ends" for the Cypherpunk remailers. This seems > like a good idea (provided that the technical problems can be overcome), > but I'd like to propose an addition. I don't see the advantage of having behind-the-scenes remailers. The addresses of the front-end remailer(s) will have to be advertised, and that is where people will think of the service as originating. That is where their attacks will be focussed. It won't matter if there are other systems involved with the remailing. If one front-end gets shut down then yes, it would be nice to have another. Again, I don't see how this is made much easier by the existance of multiple back-end systems. Penet has not been replaced yet, and I think the reason is because nobody wants to take the heat for running such a system. What difference does it make whether you are running front-end software or an entire remailer? Either way you have to be a system manager in order to install new mail aliases ("an12345", etc.). There just aren't that many system managers out there willing to take on the traffic load and the political heat for a service which they may not even believe in that strongly. > Now, as I understood the suggestion from Joe Thomas, the Cypherpunk > remailers behind the front ends would only be "visible" to the people > involved in running the service. This would certainly make the remailers > more secure, since the net.fascists would not know who to terrorize to > can the remailers. Again, saying that it is the back ends which are the remailers is misleading. As far as the net at large will be concerned, it is the front end which is the remailer. That is where you send your mail if you want it to be remailed. That is where the heat will be. And shutting down all the front ends will shut down the remailing service. The existance of back ends does not affect the strategy used by our opponents, nor does it give us any additional defense that I can see. > Although I certainly may be misunderstanding something, I don't really > see why the users of the service would ever need to see a message about > "if mail to here bounces, try there." Shouldn't the loss of a remailer be > dealt with entirely "behind the scenes," by the service administrators? How could this be done? If I still try to send mail to an1234(a)anon.penet.fi, it will not be remailed. If Julf does start enabling such messages to be remailed, by forwarding or by any other way, he will presumably face the same consequences which convinced him to stop. On the other hand, if all messages from a remailer say "reply to address A; if that doesn't work try B, and then C" then I can guarantee that when net powers try to shut down the remailers they will go after A, B, and C. Exposing their names like that will just give opponents of anonymity more time to marshall their forces against these alternative remailer sites. I think the only reasonable approach is to make the remailer code widely available, and to try to convince people to run it who are in a position not to be exposed to pressure. From earlier postings here, it sounds like someone who is paying his own money for a UUNET connection, which someone said costs about $50 per month (what does that $50 include?), would be a good choice. It sounds like UUNET is not going to cut off a paying customer just because others complain about his use of the net, particularly if it is true that UUNET is a immune to legal threats about what they carry. If he who pays for the feed is willing to carry the remailer traffic then he should be immune to pressure. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK7SyjagTA69YIUw3AQEVkwP/T6VMZJToUCvNnBTwrYZRKiJarxproRRP usOFFWyQ27ABBGypS79PfJmJZUyJAuZkAGExEapMTF/Nh0zNb8feZimfJk8A7SbM 5CvlITUMJsjmNCvk/HeeJadhkADyFiD9zRbuZiSzPGNCankt4lCxoGA2qIDklBYp ZlcMs+eHxbs= =IT8B -----END PGP SIGNATURE-----

1 0

PGP key
by AJ Janschewitz 27 Mar '93

27 Mar '93

My "old" PGP key died with my PSI account. The new key is below, and can be accessed by fingering my secondary mail address, ajay(a)holonet.net. If the list server ops would kindly kill my old key (which should have my name and an attached address of p00258(a)psilink.com) I'd appreciate it. Scary thought: If any goon wanted to trace remailers, with the Clintoon Administration now accepting E-Mail, all one would have to do is send a threatening message through a remailer and it would give the brownshirt squad license to do all kinds of things. A government bent on knowing everything might even initiate such a move itself. How do the people running remailers and those of us who might have occasion to use them deal with this straw man threat? ==a.j.== -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQCNAiuyVNUAAAEEAMWyeYBYXNT6JXDS/3ixsS1tFd02K/qekH6gjAThcm8KkFmL FVRsW9pwgpkrLV/nra3kWKeV6tA1Lic+21pmoXhdAR9tMLpy6k0KFYPTbYob8hkr kZ6u6rpRz2WcvA3LxpVbPXMMa5R/rsH9r6lnE23gD3JxGoqkaxk4MFKFFwHhAAUT tDdBLkouIEphbnNjaGV3aXR6IDxhamF5QGhvbG9uZXQubmV0LDUwMzcwMzBAbWNp bWFpbC5jb20+ =Ylln -----END PGP PUBLIC KEY BLOCK-----

1 0