December 2003 - cypherpunks-legacy

Re: NSA Cheif Counsel in Wired (Rebuttal) (fwd)
by Stanton McCandlish 17 Dec '03

17 Dec '03

Forwarded message: Subject: Re: NSA Cheif Counsel in Wired (Rebuttal) Date: Thu, 12 May 1994 14:26:52 -0700 (PDT) From: Jeff Davis <eagle(a)deeptht.armory.com> To: eff-activists(a)eff.org (eff-activists mailing list) -----BEGIN PGP SIGNED MESSAGE----- A little further along in the AP story on the record level of Clinton Administration wire taps, Micheal J. Sniffen states: In a section on surveillances completed in 1993, the report said the longest and most expensive federal eavesdropping was accomplished by a microphone placed inside a New Jersey lawyer's office in a racketeering case. The microphone actually operated 435 days, overhearing a total of 65 people, at a cost of $517,673. ...The government said in court, "the purpose of utilizing the law offices ... was to evade electronic surveillance by fraudulently creating the appearance that these were legally proper meetings." This microphone recorded conversations in the office, not the telephone. As I stated to Dr. Dorthy Denning of Georgetown University, escrowed encryption is unnecessary for surveillance. In addition to "bugs", intellegence agencies also provide long range listening technology to the enforcement agencies like the FBI and DEA. Organized criminals don't use the phone to discuss business, it can be tapped. This sort of blows a hole in Stuart Baker's arguments for escrowed encryption being necessary in law enforcement. The next time he offends someone with his tired trig joke, I would hope that he is ask to rebut this. As well as to estimate how many conversations and participants are actually involved in the given figure of 333 1993 "wiretaps." Long range listening was found to fall under federal "wiretap" rules in the Smalldone case in Denver during the summer of 1982. Try to FOIA that info. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdKerV/ScHuGXWgVAQFziAQAuYTNTKjaqTWaOO3C42yKCWLM7+kU1gXp 4sGxHGQKfsDP333zLNA+ETGuVfs6si5YQVbsnlGVdS/v36oZp8bUj/8MgWYKLj66 1jRNf4mPl0Mb5LL7InrUwjKCqmOb/GLuHK7F0cHzZbsBE2FkmIqi27AcgJ/8nMxl lFiBbzWrBk4= =I+yV -----END PGP SIGNATURE----- -- PGP PUBLIC KEY via finger! JAFEFFM Speaking & Thinking For Myself! * eagle(a)deeptht.armory.com email info(a)eff.org * *** O U T L A W S On The E L E C T R O N I C F R O N T I E R **** ***** Committed to Free Public Internet Access for World Peace ***** -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 14 1994

1 0

LaMacchia case on McNeill-Lehrer
by bart＠netcom.com 17 Dec '03

17 Dec '03

In the last third of the show. Reasonably balanced coverage with Mike Godwin of EFF. But focussing on the software piracy issue rather than correctness of the prosecution.

1 0

Re: The Wisdom of Stuart A. Baker
by catalyst-remailer＠netcom.com 17 Dec '03

17 Dec '03

> Says Stewart A. Baker, Chief Counsel for the NSA, writes in Wired: But not for long... I understand he's resigned, and will be leaving NSA tomorrow (Friday, May 13th). Wonder what his next illustrious position will be... -------------------------------------------------------------------

2 1

Re: MIT TOC SEMINAR--ADI SHAMIR--MONDAY--MAY 16--4:15pm
by Peter Murphy 17 Dec '03

17 Dec '03

> Imvery curious as to how humans can directly decode encrypted > pictures. Do they stare at it for 10 minutes and go "ah, there > it is". > Paul E. Baclace > peb(a)netcom.com Well... maybe if it was one of those stereographic pictures, it would be a little bit easier. You just have to get your eyes in focus (and that's a bit hard for some people). Pling! You suddenly discover the hidden message, like "HITLER IS ALIVE AND LIVING IN ARGENTINA!" or some other related message. It's in 3-D, so the letters appear to be 5 mm tall! (Reminds me of when Jaws III was out at the cinema. :-)) Of course, you might have to print it out first. Sorry, just me being silly. ======================================================= | Peter Murphy. <pkm(a)maths.uq.oz.au>. Department of | | Mathematics - University of Queensland, Australia. | ------------------------------------------------------- | "What will you do? What will you do? When a hundred | | thousand Morriseys come rushing over the hill?" | | - Mr. Floppy. | =======================================================

1 0

More FOIA docs online at EFF
by Stanton McCandlish 17 Dec '03

17 Dec '03

A few new arrivals at ftp.eff.org that may be of immediate interest. The first is a recent bill, scheduled for markup very soon. EFF urges you to ask your Senators to co-sponsor and support this bill. Those following EFF Boardmember John Gilmore's FOIA battle with NSA, the Justice Dept. and other recalcitrant agencies will know why this is so important. For those that don't, the issue in a nutshell is that the original FOIA (Freedom of Information Act) did not adquately cover records that are not in hardcopy format, such as computer files; it granted overly-broad excuses to not release documents, and provided for few penalties for violating FOIA. As a result, secretive agencies have been breaking the law with impunity, vastly exceeding the mandated times in which the law requires them to respond to FOIA requests from citizens, and have been using technicalities, vague passages, and filmy excuses to withold important information that belongs to the American people. This new bill, supported by EFF, aims to correct these problems, and ensure that FOIA works the way it should. The other file is adequately described by it's entry from our /pub/README.changes file, excerpted below. 05/12/94 - added important recent bill supported by EFF: Electronic Freedom of Information Improvement Act (S1782), sponsored by Sens. Leahy & Brown. Please ask your Senators to co-sponsor this bill to "fix the bugs" in FOIA, and prevent agencies from illegally delaying and refusing to release information to the public, and also mandate procedures for dealing with electronic information as well as hardcopy: /pub/EFF/Issues/Activism/FOIA/ e-foia.bill - added 10/4/93 Clinton & Reno memos to heads of Depts. and agencies on FOIA (Freedom of Information Act) issues: /pub/EFF/Issues/Activism/FOIA/foia_clinton_reno_93.memos - Clinton urges agencies to keep pace with their FOIA obligations, saying "I therefore call upon all Federal departments and agencies to renew their commitment to the Freedom of Information Act, to its underlying principles of government openness, and to its sound administration." Something that also may be of interest: - added new E-Mail Policy in Federal Government: Report of the Electronic Mail Task Force Prepared for the Office of Management and Budget, Office of Information and Regulatory Affairs, Apr. 1, 1994 - /pub/EFF/Policy/Govt_online/ federal_email_policy_omb_report -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 14 1994

1 0

Re: The Wisdom of Stuart A. Baker
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

> Says Stewart A. Baker, Chief Counsel for the NSA, writes in Wired: But not for long... I understand he's resigned, and will be leaving NSA tomorrow (Friday, May 13th). Wonder what his next illustrious position will be... Well, I'd put a dollar on him taking up some civilian post where he can influence the acceptance of Clipper through industry. Managing director of an electronics firm. Or head of one of the escrow agencies perhaps. That how things work here in Britain anyway - most of our big company top management are ex spooks. Especially in the armaments and military-related side of things, like aircraft companies. In Baker's case I'd guess a telephone company. Much more likely that or something else civilian than another govt post like NIST or the FCC. G

1 0

Re: Message Havens
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hal wrote: >Karl's idea about message havens is interesting, but I don't fully >follow how it differs from the anonymous pools we discussed last year Well, the biggest (and maybe the only) difference is mail doesn't leave the haven. It's like a post office box, you have to show up to retrieve your mail. - From my experience running remailers, posts other operators send here, general observations, and various attacks we've all suffered through, it seems like most of the problems/objections we get stem from the fact that anonymous remailers (drum roll...) actually send mail! For example: * Eli just sent a message about somebody who used his remailer to mailbomb something... *this list has been victim to the rantings of various individuals anonymous and otherwise. *somebody forwarded a ClariNet post through Scott Collins' remailer thus causing him difficulty *remailers operators have to fear some fool will remail to whitehouse.gov (or the operatros have blocked that address) *the message pool Miron runs is susceptible to mail bombing I'm not saying we should junk the anonymous remailers and replace them with message havens... it's just a suggestion that may solve a few problems we are having. Until positive reputation filters show up and everybody digitally signs their posts, etc. Digital cash payments for each message stored would greatly reduce the mailbomb problem for message havens as well as anonymous remailers. Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdL1ToOA7OpLWtYzAQEoigP+PmJtyybo24swqPD5MaDRhuvwKhhMMfn7 txaTbdVM8mzoKWgKlsB2Sw89ZO2CMl7Rijv4kgmdaxTBL278p7CuescTmRnwYACr ArlH9DSDsM9eXqVq2jLd33J2PBWhBnpn5TdOOUIJZ7B7HrT0KgaIzFv7lGhsBXQy PUh87BWOhE4= =8T8B -----END PGP SIGNATURE----- -- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

Re: Message Havens
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Downloading the whole message base to scan for one's messages >will place a massive load on net.resources, and probably >a prohibitive load on most people's terminals. I disagree. The only resource that will be hit is the message haven (unlike say every computer in the world that carries the certain usenet group you have chosen to use as a communications vehicle). Geez, think of like a place that offers anonymous ftp. It's resources are hit, but I don't buy the "massive load on net.resources". The only load I can envision being hit on a person's terminal is the time it would take to browse all messages. You have to read each message and have your communications software log in a file, or scrollback/record each one individually. I mean, the info is already coming to your computer, you just have to save it. Maybe the haven could offer a way to get all the days/weeks/whatever files in one big chuck; this is clearly no worse than just ftp'ing a large file. > This scheme should avoid this nescessity: This scheme is precisely what I described earlier! The two users agree on what to name/tag the file, and that's how they get messages to each other. The problem is Bob can't just retreive that one file (if he is concerned about traffic analysis), so he can get them all so a watcher learns nothing. You have suggested downloading a smaller portion of the available message base instead of the whole thing. >The gopherhole must be trusted not to divulge which posts came from >who, and it's key must not be compromized. Alice and Bob can get their messages to the haven via anonymous remailers to avoid problem #1. I didn't envision the message haven even having a key. It isn't needed if they both are encrypting with the other person's key anyway, so I'm not sure what problem #2 is. Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdL5hYOA7OpLWtYzAQHx8QQAtlVYJvSGyR0uGq8a8IodCewZNBwSVHou 7YJssBHIBp/I+V+s1fMpBkUSmG6oINu5L/VEeEQXRswHGJJ/F6jLtxkrFlY/kcff XKTqizrroVtemYQpZtjpPowT2eQsdlonewbslZc3Y+GdZfErgCzoiYW2dXIX8tnG yD2OvZKCAYs= =i3Ea -----END PGP SIGNATURE-----

1 0

Re: Message Havens
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Black Unicorn wrote: > Why can't gopherhole send a random number of messages with a user > selected cap? I'm taking it that a "gopherhole" is different than the "message haven" I described, so maybe I missed something... but if the "gopherhole" sends out random messages (and presumably the ones you are interested in) then the "gopherhole" will eventually be able to figure out what messages you are interested in. And how would it know what messages you are interested in unless you tell it... it would then need to be able to tie your psuedonym to your real mail address, which defeats the entire purpose of what I described. But then, maybe the design goal of a "gopherhole" is different and I missed it. Maybe I wasn't clear in what the "message haven" offered... I'm trying to get away from the penet style mapping tables, persistent information tying you and your pseudonym, and solve the "unsolicited anonymous mail" problem. The message haven requires no trust, no tables, no information since it just accepts message and files them, and if you retrieve all the message, the haven can't figure out which ones you are interested in! Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdMCx4OA7OpLWtYzAQFEyQQAlF5v1z6/GmU0HE56DDsC+IozQk8QKY8n kWmxC8VzyTq2Gjd1JOjq8MrlnQLok2F0wwJqP2+OVv8PY9iT3D3/tCVOwr2iHFq4 OF26mkwz5neIXyilrXmqhJfGPAhJQsjW5eB7PsoVSZtYkcxbjU83ZAkHGRJ6fEr3 j4tIJ6kvcto= =+ijo -----END PGP SIGNATURE-----

2 1

Re: *Here they come
by Peter Murphy 17 Dec '03

17 Dec '03

Like Lefty, I found the bit about "DEATH TO STATISTS" a bit hard to work out. For one thing, what do you define as "statist"? Does it include minarchists in this definition. I also thought that statism and PC were not synomynous. (Take Patrick Buchanan....) ======================================================= | Peter Murphy. <pkm(a)maths.uq.oz.au>. Department of | | Mathematics - University of Queensland, Australia. | ------------------------------------------------------- | "What will you do? What will you do? When a hundred | | thousand Morriseys come rushing over the hill?" | | - Mr. Floppy. | =======================================================

1 0

Re: Message Havens, gopherholes
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Okay, I think the discussion has forked somewhere along the way to "gopherholes" and "message havens". While I described the message havens, maybe I didn't do so clearly (after all, it's all worked out in my mind!) and I may be overlooking something a fresh perspective will see. But, the advantages of a message haven are: * it doesn't send mail, thus eliminating what are the strongest objections to anonymous mail - you can't harrass somebody * it doesn't require you to tell it what messages you want to retrieve * it doesn't keep a list of pseudonym and true identity mappings, which seems to be required for "gopherhole" operation * it doesn't even need to have a public key: you and your partner can use each other's keys, and in every response to a message, you can specify what to name the next message, and even include a brand new public key if you want, etc. * if you retreive all the messages, the haven can't figure out who you are communicating with (actually, it can't figure out who is communicating with you) Now, about gopherholes: [description of how randomization and tag changes will make it hard to associate pseudonyms and true names] > Yeah, it certainly isn't trivial to attack. However, I'd like to Unless I missed something, you have to tell the "gopherhole" what messages you want to receive. This allows the goperhole to associate your psuedonym and true identity. More comments! About message havens and gopherholes. Nice to see some crypto being discussed ;) Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdMGfYOA7OpLWtYzAQHT2gP9GEpOePu8gUp/u4E37pWF8WhkyFaGwpqw nAkpqhanf8gCOsvPRhk4lvwETZ20hoCRzgR2bZzIq4F4bgtvx659bbElNBZv8kKu 5xYlMm+cV3MCwwTYXaBz7ItIl8ZC6rfQLdc2LAXhvJvjdaxHTpDeySN5l1gTdCII j9SQvUGYG1w= =/NkS -----END PGP SIGNATURE-----

2 1

Re: PGP 2.5
by Philip Zimmermann 17 Dec '03

17 Dec '03

David Sternlight, here are the answers to most of your questions. >Just so I'm absolutely clear, since I want to use PGP but not to take any >legal risks: > >1. Was the person in the administration who approved this empowered to act >for the MIT Corporation? Yes. Jim Bruce, a vice president above Jeff Schiller approved it. Another high level official (another VP) also knew, and I'm under the impression that he was in favor of it, too. The decision was a formal decision by MIT The Institution. Absolutely NOT a low-level person acting on his own. I hope I'm making this point clear enough. >2. Did the MIT legal counsel act with full knowledge of the patent situation >and MIT's relationship with PKP? Of course. With absolutely full knowledge. And extensive review. And careful analysis. And with a formal written legal opinion to MIT. >3. Were the counsel and administration people aware that 2.5 uses >non-published calls to RSAREF? Perhaps you have a different opinion of what "published" means. It is the opinion of MIT and their lawyers that the entry points that PGP uses are published entry points. They were not declared public in previous versions of RSAREF, they were declared static. But now they are declared public in the new RSAREF, even to the point of being included in a header file as public entry points. MIT advised their lawyers of the exact nature of this, and the MIT administration was fully informed, and this issue was discussed to death amongst all responsible parties at MIT before a formal decision was made. >I'm eager to start using PGP2.5, and hope it all works out. I'm puzzled that >Jim Bidzos hasn't acknowledged the non-infringing nature of PGP 2.5 if, in >fact it doesn't infringe. I'm puzzled he hasn't supported 2.5 the way he has Has Bidzos publicly asserted that PGP 2.5 is infringing? If not, then it would not be safe to assume that it is. Silence can be interpreted in a variety of ways. Or not interpreted at all. MIT carries a great deal of moral authority by officially releasing PGP 2.5. I hope this will help defuse your efforts to stamp out PGP. -Philip Zimmermann prz(a)acm.org

1 0

Re: Message Havens, gopherholes
by Hal 17 Dec '03

17 Dec '03

One problem I see with Karl's suggestion (if I understand it) is that there needs to be some pre-arrangement between sender and receiver in order for the receiver to know what "tag" will be used to identify the next message. That way he knows to download it after scanning all the tags (plus, he downloads a certain number of other messages as cover). (In other words, every day he downloads five messages from the message haven. He does this whether he has anything there or not. An eaves- dropper doesn't know how many of the five are for him and how many are just random.) I think it should be possible to have a way of marking a messages as being for a particular user without any pre-arragement, and without any outsider being able to determine which messages are for which user. Simply encrypting some standard constant number with the user's public key would be close to right, although you'd have to find a way to keep the modulus size from leaking out. The main down side to this is that the decryption and tag check might take too long, while Karl's pre-arranged tag idea could be very fast. Perhaps both concepts would be useful in different contexts. Hal

1 0

Re: Cypherpunks Goals: Bad debate drives out good debate
by Derek Upham 17 Dec '03

17 Dec '03

Okay, I'll call the moderation method I suggested the ``asymptotic moderation'' method. Some problems that people have with asymptotic moderation: 1> It requires either a trusted subset of the membership to be 1> moderators and the most trusted are also the ones with the least 1> free time, or you trust everyone. I'd hate to send a message to 1> Detweiler to see if he thinks it should be posted or not :) We trust everyone. Let's take a look at the four possible cases here: Good message, good moderator: message accepted. Bad message, good moderator: message denied. Bad message, bad moderator: message denied. Good message, bad moderator: SEND THE MESSAGE AGAIN. If you're confident that your post was good, but rejected out-of-hand by a bad moderator, just send the thing again. It's highly unlikely that the same bad moderator get it the next time around. Obviously bad posts, though, will be rejected by everyone, no matter how many times they get re-posted. And just to be safe, the mailing list program can keep track of rejection slips and refuse posts from obvious abusers (and maybe it could do something similar with the above denial-of-service attack). 2> The trouble with random single moderators are many, but worst would 2> probably be time-delay. If the chosen moderator for a message is 2> busy, sick, or away from their desk messages could be delayed for 2> days. The problem gets even worse if a delayed message is then 2> approved, and posted out of sequence. The mailing list program can detect cases where people are taking too long to reply; those posts can go to a designated list maintainer (or maintainers) for immediate approvial. People who are consistently late will lose moderation privs. Remember that posting out of sequence isn't necessarily a thread-killer---Usenet survived for years with UUCP transfer delays. 3> Instead of picking random list receivers to moderate, readers should 3> choose their own moderators. 3> 3> As a moderator reads the latest messages on the list, he or she can 3> mark each one as junk or not junk. This causes advice messages to be 3> sent to their subscribers. The subscribers can use mail programs which 3> process the advice and only show messages which have passed. ("If all 3> three of my moderators say a message is junk, then don't read it, 3> otherwise, show me.") So now we're back to kill files. Here, though, the kill file rules are based on out-of-band messages that can be received at any time (possibly after you've read the message!). And every user who wants to use the kill file must set up killing software. And there's no guarantee that people would bother to rate every message they read (I've participated in something similar on a BB, and _that_ particular aspect failed miserably). 4> How about auto-moderation? I came up with this idea a while back for 4> automatically moderating mailing lists. Here's how it works: 4> [. . .] 4> If a person becomes a nuisance, people send their votes in to the 4> moderator-robot, and it tallies the votes. If within XXX days more 4> thumbs down votes are received than thumbs up votes, the person is 4> placed on the disapproved list. Pretty good, but it wouldn't do anything to stop those people who create random net addresses and post lone MAKE.MONEY.FAST or Jesus Is Coming!!! messages. And it's a bit too harsh to deal with intermittent flame fests, especially flames from people who are usually productive contributors (you know who you are). 5> There's a simpler solution. Using the majordomo hack I posted 5> earlier, mail from known abusers would be bounced to the moderator 5> for his approval or rejection. This would be a small volume, which 5> should be within the capabilities of one moderator. How do we determine known abusers, and how can we deal with unknown abusers or intermittent flame fests as above? In summary, the aysmptotic moderation method has a couple of benefits. All of the custom code is concentrated in one place; anyone with a mail reader can perform moderation duties. The moderation duties are simple and well-defined. You _know_ when you are being asked to make a critical judgement (instead of judging everything---or more likely, nothing). All of the approval/disapproval information passes through the central site, so that site can keep track of chronic abusers through plain ol' numbers. Finally, since the primary filtering method does not depend on filtering specific users, it works just as well for drive-by posters and for people who are suffering from a temporary lack of control. Derek Derek Lynn Upham University of British Columbia upham(a)cs.ubc.ca Computer Science Department ============================================================================= "Ha! Your Leaping Tiger Kung Fu is no match for my Frightened Piglet Style!"

2 1

No Subject
by Anonymous 17 Dec '03

17 Dec '03

> From: catalyst-remailer(a)netcom.com > > Says Stewart A. Baker, Chief Counsel for the NSA, writes in Wired: > > But not for long... I understand he's resigned, and will be leaving > NSA tomorrow (Friday, May 13th). > > Wonder what his next illustrious position will be... Managing Editor of Wired?

1 0

Delayed messages!
by whitaker＠dpair.csd.sgi.com 17 Dec '03

17 Dec '03

I have, after 9 days, finally received from the cypherpunks list a message I sent for distribution. This message is being sent 0540 PST 13 May 94. -- Russell Earl Whitaker whitaker(a)csd.sgi.com Silicon Graphics Inc. Technical Assistance Center / Centre D'Assistance Technique / Tekunikaru Ashisutansu Sentaa Mountain View CA (415) 390-2250 ================================================================ #include <std_disclaimer.h>

1 1

(fwd) Announcement: Mac Crypto Interface Project
by paul＠hawksbill.sprintmrn.com 17 Dec '03

17 Dec '03

Forwarded message: From: qwerty(a)netcom.com (-=Xenon=-) Subject: Announcement: Mac Crypto Interface Project Organization: PGP Info Clearinghouse. Date: Thu, 12 May 1994 23:29:54 GMT -----BEGIN PGP SIGNED MESSAGE----- Mac programmers, hello from The Macintosh Cryptography Interface Project. Included here are our "Statement of Purpose", and "Interface Design Sheet". What's public key encryption? It means if anyone encrypts something with your public key, not even they can read it again, only you, using your secret key. Send mail to qwerty(a)netcom.com with Subject "Bomb me!" for Gary Edstrom's PGP FAQ and -=Xenon=-'s "Here's How to MacPGP!" guides, which are also available from ftp.netcom.com in /pub/qwerty. -======Statement of Purpose======- Phillip Zimmerman's vision of giving the common man a real encryptor, humbly called Pretty Good Privacy (PGP), "Public Key Encryption for the Masses", was an historical event. But while PGP exists for many platforms including the Mac, it's still a command-line beast, and it shows. The current MacPGP is a powerful tool, but unacceptably difficult to use for average Mac users. Welcome to The Macintosh Cryptography Interface Project. MacPGP wont be a "program". It will be like the Trash or the Clipboard. It's going to be part of the Mac itself. A tool to set programmers free, allowing them to easily call upon any function of PGP from their software, and a tool for Mac users to use within any program. OUR GOALS: The ability to use PGP with non-PGP fanatics! Right now this isn't possible. Try it and see. Our emphasis is on the Macintosh, not cryptography. PGP will be a Mac routine, not a hacked port of the latest DOS PGP. The core PGP routines will be incorporated into a "PGP Engine" with minimal or no interface, easily accessed from other programs via AppleEvents. The operation of this engine will be quick and transparent so the privacy and security offered by PGP can become an expectation, not an inconvenience. A simple, user-friendly interface to this Engine will be designed: a smart system-wide menu, which will know what to do. Selecting a file and choosing "Encrypt" will encrypt the file to the user's own public key. No passwords. In a word processor, "Decrypt" will return a selected block of encrypted text to its original form (only with the proper pass phrase!). For e-mail, "Encrypt to...", containing a sub-menu of public keys, will quickly protect an outgoing message from viewing by anyone but its intended recipient. If not in the Finder, the Clipboard will be used automatically. Simple and easy. Eventually programs will incorporate PGP functions as internal, automatic features, accessing the PGP engine directly. The goal, quite simply, is to put strong, usable security into the hands of every Mac user. WHAT WE NEED: You. Programmers, who turn ideas into code. Cryptography? The cryptographic code exists; what we need now are serious Macintosh programmers. We also need non-programmers to help design a user-friendly environment, to help us find problems in our programs, and to contribute ideas that will help us make the high standards of PGP-encryption universally available. Just as we need the most sophisticated Macintosh programmers for this project to fly, we also need the most frustrated and inexperienced users to make sure that we have met our goals. If you wish to help, contact Xenon <qwerty(a)netcom.com> or Jordyn A. Buchanan <jab3418(a)u.cc.utah.edu> as soon as possible. We have established an international mailing list for this Project, in which no crypto code will flow. Work on the interface will be completely independent of the crypto code, meaning no worry for our programmers. Officially the Macintosh Cryptography Interface Project is not even linked to PGP, though we intend to become the official interface for the licensed MacPGP2.5, and the inevitable EuroMacPGP cryto engine. Early on, we will use an unofficial version of MacPGP2.3 which accepts AppleEvents, as our temporary model crypto engine. We need PGP2.5 to be converted into an AppleEvents engine, as an independent project; anyone within the US interested in working on this should also contact us. People in Europe etc. need to create their own AppleEvents MacPGP cryto engine. -======The MCIP Design Sheet======- Two prototype models for this interface have been built, which are available from ftp.netcom.com in /pub/qwerty/MCIP, or by e-mail from -=Xenon=- <qwerty(a)netcom.com>. One is based on J. W. Walker's OtherMenu, which is also available there. We have a mailing list, where there will be no crypto code. This will free programmers from worries about legal hassles involving crypto politics. If you are a Mac programmer, contact Jordyn Buchanan <jab3418(a)u.cc.utah.edu> or -=Xenon=- <qwerty(a)netcom.com> and we will sign you up and try to agree an a sub-project and specific design. We are also interested in helpful criticism of our design, and its implementation. The OtherMenu paradigm versus our own System Extension is not cast in stone, and needs input from experienced programmers as well as some experience with OtherMenu. Definitions: PlainText is Mac TEXT file or text on the Clipboard. PlainFile means any Mac file, be it a word processor document or a GIF file. CypherText is a text-format PGP message. CypherFile is a binary PGP message, a MacPGP file. The Engine: A dumb PGP cryto engine which accepts AppleEvents, and acts on files or the Clipboard. In the end it should have no interface of its own. This will be created independently of the interface, in both US and non-US versions. The Interface: A system-wide menu next to Balloon Help, making PGP functions available from any application, including the Finder. -=Items in the PGP Menu=- 1) Encrypt/decrypt -- for all types of decryption and for immediate encryption of personal files with the user's public key. Just select a file in the Finder and this command will either decrypt it, asking for a passphrase, or encrypt it with your public key, no questions asked. If the user isn't in the Finder the Clipboard will automatically be used. PGP will figure out if a file is already encrypted or not, and take appropriate action upon it. Additionally, if the option key is held down during passphrase confirmation, decrypted PlainText from the Clipboard will be presented in a window of PGP's text editor (see below). If on decrypting a file on the Clipboard, the output is not PlainText, a Mac binary file will be output to the Desktop, automatically. Within the Finder, holding down the option key while confirming pass phrase entry will launch the decrypted file. On encrypting a personal file, the original plaintext will be securely wiped out. On decrypting a personal file, the original will be deleted. 2) Encrypt to... -- this has a submenu containing the keys on your Public Keyring. If you are not in the Finder, the contents of the Clipboard will be encrypted with the person's public key you select from this menu. If you are in the Finder, the selected file will be encrypted to that person, with a quick dialog box appearing asking for Clipboard or Desktop (and CypherText or CypherFile) output. A TEXT file in the Finder will be treated as text input to PGP, but any other file will be treated as a binary Mac file. At the top of this menu will be Group... which will allow fast single-clicking of multiple recipients from a list. Aliases of single or multiple recipients will also be easy to define, and will appear in a group at the top of this menu. 3) Sign -- If not in the Finder, this will clearsign the contents of the Clipboard (after cutting it to <80 characters per line). If in the Finder, the selected file will be "armored" with a dialog asking for Clipboard (CypherText) or Desktop (and CypherFile or CypherText) output. 4) Keys... -- Dialog box(s) which handles all key management, including a quick button for adding a public key from the Clipboard, or extracting your public key to the Clipboard. The rest is standard, but for the ability to create Aliases for groups of people, the name of the alias then appearing at the top of the Encrypt to... submenu. 5) "Editor..." -- A simple <80 character wide window for typing out (then encrypting) quick e-mail or viewing normal decrypted e-mail. This is for users of simple VT100 terminal emulators, which includes most people using e-mail via modem. The user can choose a font and size, and resize the window vertically. If the window for this editor is active, the PGP menu will act upon text selected in it, or all of the text if no selection has been made. Our goal is to actually have people use this editor for their e-mail drafting and reading. It will also be able to save or append it's contents to a text file, for those of us who keep e-mail logs. 6) "Options..." -- If the user has multiple key-pairs, they can select the one for use in signing things, and for personal encryption. They can select whether to sign things when using "Encrypt to...". They can select the File Type Creator for output text files in the Finder. Any other options will be set here, and be kept in a Preferences file in the Preferences folder (duh). That's it! One menu. No options to choose during the most commonly used operations. Just immediate action after a single menu selection. To demonstrate and elaborate on this interface, here now are presented various actions a user may do. I will use my girlfriend as an example. -=User Actions, Outlined=- 1) Encrypt her diary, which she just wrote using Microsoft Word: She saves the file, selects it in the Finder, and encrypts it with her public key with a single PGP menu selection ("Encrypt/decrypt"). Done. 2) Adds a day's writing to her diary: double clicks her encrypted diary, types her passphase into a dialog box, and hits the return key, to have the CypherFile replaced by a PlainFile. And, since she held down the option key when she hit the return key (OK button), PGP sent an AppleEvent to open that file, so she's already typing new stuff in Microsoft Word. 3) Decrypt the e-mail I sent her: She copies it to the Clipboard, since it's only a couple pages of CypherText. Without leaving her VT102 modem program, she selects "Encrypt/decrypt", is prompted for her pass phrase, and since she holds down the option key when she hits the return key, the PlainText is presented to her in PGP's editor window. I did have to show her how to use Unix "mail" instead of PINE though, since PINE would require saving and then downloading the file, it only being able to show one small block of text at a time in a non-scrollable window. 4) Respond to my e-mail above: She just types away, using the editor's convenient features. She selects her text and simply chooses my name from the PGP "Encrypt to..." submenu. It ends up in the Clipboard, automatically. She's still in her modem program, so she just pastes the CypherText into e- mail. 5) Post a clearsigned announcement to Usenet: "Editor" lets her type it out, then simple selecting "Sign" places the clearsigned message onto the Clipboard. If she is responding to someone else's post, she must copy the original then paste it into the editor. 6) Check a signature from Usenet: Copy the message to the Clipboard and select "Encrypt/decrypt". An alert appears telling her the signature is good or bad. The message is placed on the Clipboard, free of signature. 7) Send a huge Mac file to me, encrypted: She selects it in the Finder, chooses my name from the "Encrypt to" submenu and hits the "PlainText / Desktop" button. She has her modem software autotype the file into e-mail, or uploads it. If it's not too large she can instead hit the "Clipboard" button and just paste it into e-mail. 8) Decrypt a huge CypherText file I sent her in e-mail: she saves it and downloads it, selects it in the Finder and selects "Encrypt/decrypt", and after she types her pass phrase the CypherText is replaced by a PlainFile. 9) Encrypt the message "Meet at midnight, at Nell's, tomorrow!" to a group of people who she is working on a project with. She brings up PGP's editor, types the message, and selects the "Babes" alias, which she earlier defined, from the "Encrypt to" submenu. Her message is automatically encrypted to that group of people, the result being placed on the Clipboard for pasting into e-mail. -=Comments=- 1) PGP is a public key encryptor. No "conventional encryption" is needed in our basic interface, since encrypting a file in your public key is so much easier than having to very carefully type a pass phrase for the encryption step. If someone wants IDEA-only encryption they can use Will Kinney's Curve Encrypt, which does drag-and-drop, they can use the old MacPGP, or they can create their own "Conventionally encrypt" feature to add to our modular interface. 2) Our design is in flux, and flexible. However our singular goal is this: that we can send MacPGP on a floppy to any non-sophisticated Mac user and have them send us a public key within an hour, then start using PGP for e- mail the next day. There will be little in the way of a manual other than as a brief intro on exactly how to quickly set up and use PGP, Balloon Help being enough for most operations. 3) Our interface is a separate project from the cryptography engine. Early on we will use MacPGP2.3aV1.1 which does accept AppleEvents. This will allow us to get started now, as well as have MacPGP2.3aV1.1 take care of features we have not built into the interface yet, such as full key management. 4) Initially we will spool the Clipboard to disk files, then delete them after we have the crypto engine act on them. Later the cryto engine will have an AppleEvent option for using the Clipboard. In the end this will likely have no interface of its own at all, and become a background-only application. 5) We intend to be the official interface for MacPGP2.5, and hope to see PGP2.5 quickly ported to the Mac as an AppleEvents cryptography engine, for use by our interface and any other program such as Mac e-mail programs. 6) J. W. Walker's OtherMenu shareware ($10) may be looked at as a system- wide menu tool kit, to which we can add our routines as CODE resources, placed in the OtherMenu Folder in the System Folder. This will allow us to start getting things done immediately, without any worry about building our own System Extension. OtherMenu is actively maintained by Mr. Walker, who has also been personable in e-mail. We can remove all the extensions that come with OtherMenu, leaving only our own menu items! We can even place our own icon atop our menu. This is a clean solution. CODE resources are trivially made using Think C. Anything that we could do with an application we can do easier with an OtherMenu CODE resource file, and our menu ends up in the system-wide OtherMenu next to Balloon Help. OtherMenu will send any AppleEvent we create for us, as well. There is an OtherMenu Developer Kit available for free, though really such CODE resources are just like any Mac program. These can be had from ftp.netcom.com in /pub/qwerty/MCIP. We may think of OtherMenu as a part of the Mac operating system, which allows us to add any feature to a system-wide menu. As further persuasion, imagine that we had created a system-wide menu for this project, by writing our own System Extension. Further, unbelievably, imagine that we made this Extension able to accept modular plug-in PGP features as simple CODE resources, thus creating a framework for breaking our project into smaller independent projects. Now imagine this is true, and thus take a look at OtherMenu, with a MacPGP icon slapped onto it. Sure it's $10, but it's shareware, and it saves us untold development time and effort. Later, if anyone wishes to assemble our CODE resources into a dedicated System Extension, they are free to do so, though I don't think it will be worth the ten bucks. 7) The interface will be somewhat inflexible in how it does things, which is needed in order to make it very simple. Extraneous features and options will be weeded out unmercifully until the interface is a model of simplicity. Art, if you will. Cryptography fanatics are free to design their own interface to the PGP Engine. 8) We want security of left-over PlainText on the user's hard disk to be handled by PGP, automatically. On encrypting a file for personal use with "Encrypt/decrypt", the original WILL be wiped clean from the hard disk. We should include in our distribution FlameFile by Josh Goldfoot for wiping out Finder files, or all unused hard disk space. In fact, FlameFile can be operated via AppleEvents as well. 9) Since we are developing free software with limited resources and limited time for making an impact, certain compromises have been made compared to a perfect design. OtherMenu is one pleasant compromise. Using MacPGP2.3aV1.1 is not very happy, but will have to do for now. It has the same layout as MacPGP2.3, but is debugged and will accept AppleEvents, in some detail. It will not so far however allow selection of the Clipboard for input/output. The source code for MacPGP2.3aV1.1 is also not yet available, though we will indeed put a large effort into getting it. Another possibility is to write some of our routines as AppleScript applications with Apple's Script Editor, and place them in the OtherMenu folder so they will appear as normal menu items. This would be a temporary quick fix at best. For instance (using "Jon's Commands" for the Finder selection part) the following does work to encrypt a file(s) selected in the Finder to my public key, then wipe the plaintext. tell application "MacPGP" encrypt (finder selection) to "Xenon" quit end tell tell application "FlameFile" open (finder selection) quit end tell 10) Jordyn, -=Xenon=-, as well as others, do have connections with the core PGP development community, for what it's worth. Our main interest is becoming the interface for the next MacPGP. We need our dumb AppleEvents crypto engine to be built from PGP2.5 by a few Mac programmers. If you hadn't suspected it, former MacPGP development is dead, for rather boring reasons. We will help people interested in working on the MacPGP engine in any way we can. There should be two compatible versions, US and international. Since MacPGP development is no longer happening, we need a new group of dedicated people to tackle this, independently of our interface project. 11) An encrypted file will have its name altered, as well as its icon (its type changed to CRYPT too, so a double click will trigger PGP). There are selection dialog boxes and hierarchical menus which show only names, so changing an icon isn't enough. I suggest just *, appended directly to the end of the name, which PGP will not use in any way except as a sign to the user that file is CypherText. 12) No, this interface is not incorporation of PGP into e-mail programs so to make it's operation transparent. The reason for this is the good old VT102 emulator, which so many people use, since that's what came with their modem. People using Macintosh based e-mail programs, will indeed have it easier, once someone links those programs to PGP, so outgoing mail is automatically encrypted, and incoming decrypted. Such uses will still have use for our Finder-based commands however, and their e-mail programs will use the same PGP cryto engine, via AppleEvents. 13) For this project to fly, strong leadership is required. This interface design sheet will be maintained by -=Xenon=-, with equal contribution by Jordyn Buchanan, and SHOULD be followed. Changes to this sheet are easy though: tell us your story of woe, need, or ambition, and we will make changes and issue an update. Alternatively, draft your own sheet ;-). Or get us interested enough in your ideas that we let you take over. This sheet will become very detailed. Given the modularity of this interface, more than one answer to a given problem can be created, with the user choosing favorites. Wherever a conflict in design philosophy arises, the MacPGP USERS, not the programmers will have the greater say. That said, we are looking for creative ideas and damming criticism so we know we are thinking straight. 14) PGP will be free. Why are we doing this? Because ViaCrypt isn't doing it. Unless their MacPGP is System software, free, with source code, we have little interest in ViaCrypt as the answer to how to be able to get our friends to use PGP with us, today. We simply want PGP to become something we no longer think about, so we can get on with our lives instead of struggling with the problem of getting others to use it with us. That shall remain our goal and only purpose. 15) This project is in its infancy. Jordyn and -=Xenon=- are not yet skilled Mac programmers, which in fact gives us an advantage in designing an interface. We are here to reflect what the needs of users are, and to provide organization and resources for this project. We are here by default, there being no competition. However, and especially since this interface project is free from legal and political hassles, we need strongly motivated and highly skilled Mac fanatics to take our design and make it real. 16) The modularity of this interface will allow addition of special-purpose features to PGP, such as Stealth PGP which strips PGP messages down so far you can't tell them from noise, steganography, Magic Money functions (Pr0duct Cypher's PGP-based money system), or anonymous remailer chaining. In fact, without easy to use interfaces for these systems being available for the Mac (and Windows), steganography, digital cash, and chaining of encrypted anonymous remailers will remain obscure toys. 17) The PGP cryto engine, though not mentioned in detail herein, will become a plaything for programmers who wish to create their own PGP-based applications such as for sending credit card orders via e-mail, creating local encrypted networks, making PGP encryption a transparent feature of steganographs, or transparent incorporation of PGP into Mac-based e-mail readers. We need to know what such programmers want out of the engine, since our needs are simple. The engine is not slave to our interface design, and should be pursued for its own sake. We simply hope to show that it should be kept simple, perhaps with no interface of its own and run only by AppleEvents (and thus AppleScript etc. if desired). A separate design effort will be needed, mainly to simply define the required AppleEvent structures that will negate the need for its own interface. One thing I'd love is the ability to define a "safe" folder, the contents of which would be encrypted, always, unless they were open. Then my diary could sit in there, and get encrypted as soon as I was done writing and saved it from my word processor. This could be a System Extension, always watching that folder. With the PGP crypto engine, the writer of such an Extension would not have to worry about any crypto code. 18) It's time to stop waiting for PGP3.0 to be released, since our interface relies only on the most simple of concepts for AppleEvents it will send, and altering AppleEvents is easy. If and when PGP3.0 arrives, our interface will be ready, and porting PGP3.0 to the Mac will thus be much easier. -=Critical Path=- Anyone can take it upon themself to work on these. 1) Get source code for MacPGP2.3aV1.1 and alter it to accept the Clipboard as an input/output option, which it already can do, if operated manually. Till then we will spool the Clipboard to disk and have MacPGP2.3aV1.1 act only on files. MacPGP2.3aV1.1 was recently released in Germany, and will act as our temporary model crypto engine. 2) Recruit native Macintosh programmers, and do a job of inspiring them about what this project is about, and why it is important. Also find some frustrated MacPGP users to tell us what they need, though explanations of what e-mail programs they use, and how they would like to interface it with PGP. We should get our literature posted on AOL and Compuserve as well, where many "isolated" programmers live. 3) Learn the ins and outs of J. W. Walker's OtherMenu and write up a tutorial on how to program the Mac this way, then create our interface in independent pieces as CODE resource files. A CODE resource is just a Mac application stripped down a bit, so they are in fact easier than building an application. The modularity of our interface will give people small yet fully functional projects to work on. 4) Independently of our MCIP mailing list, port PGP2.5 to the Mac as a background-only cryto engine, which accepts detailed AppleEvents. Create a Developer's Kit so any Mac programmer can incorporate PGP into their software. 5) Copyright our Interface, which is really just a few externals for OtherMenu, rendering it free. -=Questions=- 1) How will we handle pass phrase recycling during a long but busy e-mail session? We could do without it completely, as an option. 2) Might we allow selection of Macintosh folders full of stuff, then create an archive of the folder to send to PGP? Or should we just encrypt all the files within a selected folder? That's easier. 3) Though this would require some tricks, might we have PGP use the Clipboard indirectly, by automatically copying any selected text from a text editing window of any application to the Clipboard? Or selecting all of the text in a text editing area, if no selection has been made by the user? The could be termed "magic", for it would be like an added feature to that program that you use it in. Just select text then go to the PGP menu. 4) How can we handle a progress dialog box during long operations? The crypto engine itself shouldn't in the end have any interface. So how do we make a legitimate progress indicator? 5) How do we get the name of the file(s) selected when the user is in the Finder? [If we cannot do this, we can substitute Finder activities with drag-and-drop applications on the Desktop. There would be three of these, one for each menu item, "Encrypt/decrypt", "Encrypt to...", and "Sign".] "Jon's Commands", and AppleScript addition is able to get this info, though the author said he had to delve into undocumented data structures to find it. He seemed willing to help, or we could just use his addition. 6) What will happen if the user is in the Finder, but has selected nothing, or has accidentally selected like their entire hard disk, which is quite common to accidentally do? On the other hand, it wont be too uncommon for someone to wish to encrypt the entire contents of a floppy, or even a hard disk. A dialog box will be needed if the folder selected is a disk. Obviously, there should be a responsive "Cancel" button/command-. option while the encryption progress window is on the screen, which should return all files to their original condition (that's what "Cancel" means). What if they have nothing selected? A dialog box will appear saying they haven't selected anything, with "Clipboard" being default, and "Cancel" as an option. -=Comparison of MacPGP2.3 to the New MacPGP=- 1) To encrypt a file on my hard disk, that I just wrote with a word processor: OLD: 1) Start up MacPGP, and wait for it to fire up (~4 seconds), 2) Command-key and wait for dialog (1 second), 3) Command-D to get to Desktop and click-click click-click click-click click-click click-click click-click click-click to dig up my file deep on my hard disk (~5 seconds), 4) select my public key from the list and hit OK if I am not using "conventional encryption" (which I am NOT since nobody, including myself, can stand typing a damn pass phrase SUPER carefully for an ENCRYPTION step with risk of full data loss on making a typo), (3 seconds), 5) gaze at a HUGE dialog box of 13 buttons and three text edit boxes, selecting "treat source as Macintosh file", "wipe original", "don't sign" and gaze again to make sure I don't have someone else's public key accidentally chosen, and finally hit "Do it" (~4 seconds), 6) wait while staring at a UNIX/DOS screen scrolling text at me instead of a normal Macintosh progress box, 7) quit MacPGP. NEW: Click on the file from the Finder and select "Encrypt/decrypt" from the PGP menu. Decryption is IDENTICAL, except for prompting for a pass phrase, and the option of simply double-clicking on the encrypted file. 2) To encrypt a file to someone else: OLD: SEE ABOVE 7 STEPS! NEW: Place my message on the Clipboard with two standard keystrokes, select the person's name in the PGP "Encrypt to" submenu, and paste it into e- mail. 3) To send short quick e-mail: OLD: 1) Start up a damn word processor and copy the message to the Clipboard, then SEE ABOVE 7 STEPS. NEW: 1) Call up PGP's little text editor in an instant, without leaving my e-mail program, type my message and choose the person's name in the "Encrypt to" menu of PGP. The editor shuts down and the encrypted message ends up in the Clipboard, ready to paste into e-mail. 4) Decrypt short e-mail I just got: OLD: Copy it to the Clipboard and then SEE ABOVE 7 STEPS, and then start up a damn word processor and Paste the PlainText into a document so I can read it! NEW: Copy it to Clipboard and hit "Encrypt/decrypt", holding down the option key so it appears in PGP's text editor window for my viewing pleasure. 5) Add a key to my public keyring. OLD: Copy it to Clipboard, start up a word processor, save it as text-only. Start up PGP, "Add keys...", click-click, click-click, then click-click, click-click, click-click, click-click to find my pubring.pgp. Then say, no, I don't want to certify the key myself. NEW: Copy it to Clipboard, choose "Keys..." from the PGP menu without leaving my e-mail software, click on a button that says "Add key from Clipboard". Done, and I'm back in e-mail. Jordyn Buchanan <jab3418(a)u.cc.utah.edu> -=Xenon=- <qwerty(a)netcom.com> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdKCHQSzG6zrQn1RAQGrAQP+Mw9dJz4vIhnFb8s+CwL84QG3qo5rdYFE 78B4VlA/brOlWmXj6SApn0Yd+l+cLSmezZbLnnumOysk5ZXaTGbOVdv+gN6Ur4lZ 6Nk5pQ+UZNpoM3XBrsCu7k+b0opkMrEkgPv5IfMIQDTJuOOyRryispBjuaS9YuAT QueTCgnbJWA= =olym -----END PGP SIGNATURE-----

1 0

KEYSERVER UPGRADE ANNOUNCEMENT
by pgpkeys＠wasabi.io.com 17 Dec '03

17 Dec '03

The keyserver at wasabi.io.com has been upgraded to cover the new format of pgp2.5 output and its 8 character Key IDs. It will continue to serve keys requested by 6 character ID for a short while, but the 6 character key database will not be refreshed with new keys. After a week or two we will remove the old data and all requests must be for 8 character Key IDs. If you have a reference to your key at wasabi in your .signature, please find the longer form of your key ID and update your sig file. Thank you. The Mgt.

1 0

Anonymous pool?
by Ryan R Snyder 17 Dec '03

17 Dec '03

1 0

Where to get PGP
by mpj＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- WHERE TO GET THE PRETTY GOOD PRIVACY PROGRAM (PGP) (Last modified: 12 May 1994 by Mike Johnson) WHAT IS THE LATEST VERSION? The latest BETA TEST version for DOS and Unix is 2.5 (Uses RSAREF 2.0 for U. S. Patent compliance, even though the original RSA code written by Philip Zimmermann runs faster). The latest commercial versions are 2.4 (both Viacrypt and BSAFE versions). The latest freeware Mac version for which source code is available is 2.3 The latest freeware Mac version (source code not public) is 2.3aV1.1 (written by Christoph_Pagalies(a)hh2.maus.de) The latest Amiga version is 2.3a2 The latest fully released freeware version for all other platforms is 2.3a WHERE CAN I GET VIACRYPT PGP? If you are a commercial user of PGP in the USA or Canada, contact Viacrypt in Phoenix, Arizona, USA. The commecial version of PGP is fully licensed to use the patented RSA and IDEA encryption algorithms in commercial applications, and may be used in corporate environments in the USA and Canada. It is fully compatible with, functionally the same as, and just as strong as the freeware version of PGP. Due to limitations on ViaCrypt's RSA distribution license, ViaCrypt only distributes executable code and documentation for it, but they are working on making PGP available for a variety of platforms. Call or write to them for the latest information. The latest information I have from them on compiled versions are: PGP 2.4 for MS-DOS PGP 2.4 for Unix (several different platforms) PGP 2.4 for WinCIM CSNAV Mac version expected late this summer. ViaCrypt David A. Barnhart, Product Manager 2104 West Peoria Avenue Phoenix, Arizona 85029 Tel: (602) 944-0773 Fax: (602) 943-2601 E-mail: viacrypt(a)acm.org Credit card orders only. (800)536-2664 (8-5 MST M-F) WHERE CAN I GET THE BETA TEST PGP 2.5 FROM MIT (USES RSAREF 2.0)? MIT-PGP 2.5 is for U. S. use only (due to some archaic export control laws), but interoperates with PGP 2.3 and 2.3a. This is the right version to use if you want to use it for personal (not for services you get paid for) electronic mail privacy in the USA and Canada. To get it from the source at MIT: 1. Read ftp://net-dist.mit.edu/pub/PGP/license.txt and agree to it. 2. Telnet to net-dist.mit.edu and log in as getpgp. 3. Answer the question and write down the directory name listed. 4. QUICKLY end the telnet session with ^C and ftp to the indicated directory on net-dist.mit.edu (something like /pub/PGP/dist/U.S.-only-????) and get the distribution files (pgp25.zip, pgp25doc.zip, and pgp25src.tar). If the hidden directory name is invalid, start over at step 2, above. You can also get PGP 2.5 from: csn.org/mpj ftp://csn.org/mpj/I_will_not_export/crypto_???????/pgp/pgp25.zip ftp://csn.org/mpj/I_will_not_export/crypto_???????/pgp/pgp25src.tar See ftp://csn.org/mpj/README.MPJ for the ??????? See ftp://csn.org/mpj/help for more help on negotiating this site's export control methods. ftp.netcom.com/pub/mpj ftp://ftp.netcom.com/mpj//I_will_not_export/crypto_???????/pgp/pgp25.zip ftp://ftp.netcom.com/mpj//I_will_not_export/crypto_???????/pgp/pgp25src.tar See ftp://ftp.netcom.com/pub/mpj/README.MPJ for the ??????? See ftp://ftp.netcom.com/pub/mpj/help for more help on negotiating this site's export control methods. TO GET THESE FILES BY EMAIL, send mail to ftp-request(a)netcom.com containing the word HELP in the body of the message for instructions. You will have to work quickly to get README.MPJ then the files before the ??????? part of the path name changes again (several times a day). ftp.eff.org Follow the instructions found in README.Dist that you get from one of: ftp://ftp.eff.org/pub/Net_info/Tools/Crypto/README.Dist gopher.eff.org, 1/Net_info/Tools/Crypto gopher://gopher.eff.org/11/Net_info/Tools/Crypto http://www.eff.org/pub/Net_info/Tools/Crypto/ Colorado Catacombs BBS Mike Johnson, sysop Mac and DOS versions of PGP, PGP shells, and some other crypto stuff. Also the home of some good Bible search files and some shareware written by Mike Johnson, including DLOCK, CRYPTA, CRYPTE, CRYPTMPJ, MCP, MDIR, DELETE, PROVERB, SPLIT, ONEPAD, etc. v.FAST/v.32bis/v.42bis, speeds up to 28,800 bps 8 data bits, 1 stop, no parity, as fast as your modem will go. Use ANSI terminal emulation, of if you can't, try VT-100. Free access to PGP. If busy or no answer, try again later. Log in with your own name, or if someone else already used that, try a variation on your name or pseudonym. You can request access to crypto software on line, and if you qualify legally under the ITAR, you can download on the first call. Download file names: pgp25.zip (DOS version with documentation) pgp25src.tar (Unix version and source code) pgp25doc.zip (Documentation only -- exportable) (303) 938-9654 (Boulder, Colorado number forwarded to Longmont number) (303) 678-9939 (Longmont, Colorado number) Verified: This morning. Other BBS and ftp sites will no doubt pick it up rapidly after the beta test is completed. Please send bug reports concerning PGP 2.5 BETA to pgp-bugs(a)mit.edu. If you obtain a copy of this beta release code, please keep checking http://web.mit.edu for the announcement of the final release, so that you can update your copy of PGP2.5. WHERE TO GET PGP 2.3a (RELEASED FROM NEW ZEALAND) The freeware version of PGP is intended for noncommercial, experimental, and scholarly use. It is available on thousands of BBSes, commercial information services, and Internet anonymous-ftp archive sites on the planet called Earth. This list cannot be comprehensive, but it should give you plenty of pointers to places to find PGP. Although the latest freeware version of PGP was released from outside the USA (New Zealand), it is not supposed to be exported from the USA under a strange law called the International Traffic in Arms Regulations (ITAR). Because of this, please get PGP from a site outside the USA if you are outside of the USA. This data is subject to change without notice. If you find that PGP has been removed from any of these sites, please let me know so that I can update this list. Likewise, if you find PGP on a good site elsewhere (especially on any BBS that allows first time callers to access PGP for free), please let me know so that I can update this list. Thanks to Gary Edstrom and Hugh Miller for providing part of this data. FTP sites: ftp.ee.und.ac.za /pub/crypto/pgp soda.berkeley.edu /pub/cypherpunks/pgp (DOS, MAC) Verified: 21-Dec-93 ftp.demon.co.uk /pub/amiga/pgp /pub/archimedes /pub/pgp /pub/mac/MacPGP ftp.informatik.tu-muenchen.de ftp.funet.fi ghost.dsi.unimi.it /pub/crypt Verified: 21-Dec-93 ftp.tu-clausthal.de (139.174.2.10) wuarchive.wustl.edu /pub/aminet/util/crypt src.doc.ic.ac.uk (Amiga) /aminet /amiga-boing ftp.informatik.tu-muenchen.de /pub/comp/os/os2/crypt/pgp23os2A.zip (OS/2) black.ox.ac.uk (129.67.1.165) /src/security/pgp23A.zip (MS-DOS executables & docs) /src/security/pgp23srcA.zip (Unix, MS-DOS, VMS, Amiga sources, docs, info on building PGP into mailers, editors, etc.) /src/security/pgp23A.tar.Z (Same as PGP22SRC.ZIP, in Unix tar format) /src/security/macpgp2.3.cpt.hqx (Macintosh version) iswuarchive.wustl.edu pub/aminet/util/crypt (Amiga) csn.org /mpj/README.MPJ contains variable directory name -- read this first. /mpj/help explains how to get to hidden directory containing PGP /mpj/I_will_not_export/crypto_???????/pgp/ contains current PGP /mpj/I_will_not_export/crypto_???????/pgptools/ contains related tools /mpj/I_will_not_export/crypto_???????/ contains other crypto info. /mpj/public/pgp/ contains PGP shells, faq documentation, etc. ftp.netcom.com /pub/dcosenza -- PGP for several platforms + some shells and steganography utilities. /pub/gbe/pgpfaq.asc -- frequently asked questions answered. /pub/mpj (see README.MPJ -- similar layout to csn.org//mpj) /pub/qwerty -- How to MacPGP Guide, largest steganography ftp site as well. PGP FAQ, crypto FAQ, US Crypto Policy FAQ, Steganograpy software list. MacUtilites for use with MacPGP. Stealth1.1 + other steganography programs. Send mail to qwerty(a)netcom.com with the subject "Bomb me!" to get the PGP FAQ and MacPGP guide if you don't have ftp access. nic.funet.fi (128.214.6.100) /pub/crypt/pgp23A.zip /pub/crypt/pgp23srcA.zip /pub/crypt/pgp23A.tar.Z van-bc.wimsey.bc.ca (192.48.234.1) /m/ftp2/crypto/RSA/PGP/2.3a/pgp23A.zip /m/ftp2/crypto/RSA/PGP/2.3a/pgp23srcA.zip ftp.uni-kl.de (131.246.9.95) qiclab.scn.rain.com (147.28.0.97) pc.usl.edu (130.70.40.3) leif.thep.lu.se (130.235.92.55) goya.dit.upm.es (138.4.2.2) tupac-amaru.informatik.rwth-aachen.de (137.226.112.31) ftp.etsu.edu (192.43.199.20) princeton.edu (128.112.228.1) pencil.cs.missouri.edu (128.206.100.207) StealthPGP: The Amiga version can be FTP'ed from the Aminet in /pub/aminet/util/crypt/ as StealthPGP1_0.lha. Also, try an archie search for PGP using the command: archie -s pgp23 (DOS Versions) archie -s pgp2.3 (MAC Versions) ftpmail: For those individuals who do not have access to FTP, but do have access to e-mail, you can get FTP files mailed to you. For information on this service, send a message saying "Help" to ftpmail(a)decwrl.dec.com. You will be sent an instruction sheet on how to use the ftpmail service. Another e-mail service is from nic.funet.fi. Send the following mail message to mailserv(a)nic.funet.fi: ENCODER uuencode SEND pub/crypt/pgp23srcA.zip SEND pub/crypt/pgp23A.zip This will deposit the two zipfiles, as 15 batched messages, in your mailbox with about 24 hours. Save and uudecode. For the ftp sites on netcom, send mail to ftp-request(a)netcom.com containing the word HELP in the body of the message. World Wide Web URLs: (Thanks to mathew(a)mantis.co.uk) UNIX PGP 2.3a Compiles best with GCC 2.4.x or higher. A straight port from DOS, so hardened UNIX users find it a bit chatty. * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/pgp23A.tar.Z * _UK:_ ftp://black.ox.ac.uk/src/security/pgp23A.tar.Z * _NL:_ ftp://svin02.info.win.tue.nl/pub/misc/pgp23A.tar.gz * _SE:_ ftp://ftp.sunet.se/pub/security/tools/crypt/pgp23A.tar.gz * _SE:_ ftp://isy.liu.se/pub/misc/pgp/2.3A/pgp23A.tar.Z * _IT:_ ftp://ghost.dsi.unimi.it/pub/crypt/pgp23A.tar.Z * _FI:_ ftp://ftp.funet.fi/pub/crypt/pgp23A.tar.Z * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/pgp23A.tar.Z * _US:_ ftp://soda.berkeley.edu/pub/cypherpunks/pgp/pgp23A.tar.gz _________________________________________________________________ MS-DOS PGP 2.3 Program * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/pgp23A.zip * _UK:_ ftp://black.ox.ac.uk/src/security/pgp23A.zip * _SE:_ ftp://isy.liu.se/pub/misc/pgp/2.3A/pgp23A.zip * _IT:_ ftp://ghost.dsi.unimi.it/pub/crypt/pgp23A.zip * _FI:_ ftp://ftp.funet.fi/pub/crypt/pgp23A.zip * _IT:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/pgp23A.zip * _US:_ ftp://soda.berkeley.edu/pub/cypherpunks/pgp/pgp23A.zip Source code Designed to compile with Turbo C; compiles fine with Microsoft Visual C++ also. * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/pgp23srcA.zip * _UK:_ ftp://black.ox.ac.uk/src/security/pgp23srcA.zip * _SE:_ ftp://isy.liu.se/pub/misc/pgp/2.3A/pgp23srcA.zip * _IT:_ ftp://ghost.dsi.unimi.it/pub/crypt/pgp23srcA.zip * _FI:_ ftp://ftp.funet.fi/pub/crypt/pgp23srcA.zip * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/pgp23srcA.zip * _US:_ ftp://soda.berkeley.edu/pub/cypherpunks/pgp/pgp23srcA.zip _________________________________________________________________ MACPGP 2.3 A slightly souped-up port of PGP to the Mac. Has help menus and other goodies, but is still not a real Mac application. However, it works. Note that the version 2.3 release of MacPGP contains the major bug-fix which was later added to UNIX/DOS PGP 2.3. There was therefore no need for a MacPGP 2.3A release; version 2.3 already had the bug fix by the time it was released. There is no MacPGP 2.3A. Program * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/MacPGP/MacPGP2.3.cpt.hqx * _UK:_ ftp://black.ox.ac.uk/src/security/macpgp2.3.cpt.hqx * _SE:_ ftp://isy.liu.se/pub/misc/pgp/2.3A/macpgp2.3.cpt.hqx * _IT:_ ftp://ghost.dsi.unimi.it/pub/crypt/macpgp2.3.cpt.hqx * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/macpgp2.3.cpt.hqx * _US:_ ftp://soda.berkeley.edu/pub/cypherpunks/pgp/macpgp2.3.cpt.hqx.gz Source code Requires Think C. * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/MacPGP/MacPGP2.2src.sea.hqx -- version 2.2 only * _IT:_ ftp://ghost.dsi.unimi.it/pub/crypt/macpgp2.3src.sea.hqx.pgp * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/macpgp2.3src.sea.h qx.pgp Documentation PGP is rather counter-intuitive to a Mac user. Luckily, there's a guide to using MacPGP in ftp://ftp.netcom.com/pub/qwerty/Here.is.How.to.MacPGP. _________________________________________________________________ OS/2 PGP You can, of course, run the DOS version of PGP under OS/2. Program * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/pgp22os2.zip -- version 2.2 only, native binaries * _DE:_ ftp://ftp.informatik.tu-muenchen.de/pub/comp/os/os2/crypt/pgp23os2 A.zip Source code * _DE:_ ftp://ftp.informatik.tu-muenchen.de/pub/comp/os/os2/crypt/pgp23src A.zip _________________________________________________________________ AMIGA PGP * _UK:_ ftp://ftp.demon.co.uk/pub/amiga/pgp/pgp21ami.lha -- version 2.1 only * _DE:_ ftp://faui43.informatik.uni-erlangen.de/mounts/rzsuna/pub/aminet/u til/crypt/pgp21ami.lha -- version 2.1 only * _DE:_ ftp://ftp.uni-kl.de/pub/aminet/util/crypt/PGPAmi23a_2.lha * _US:_ ftp://ftp.wustl.edu/pub/aminet/util/crypt/PGPAmi23a_2.lha Source * _DE:_ ftp://ftp.uni-kl.de/pub/aminet/util/crypt/PGPAmi23a2_src.lha * _US:_ ftp://ftp.wustl.edu/pub/aminet/util/crypt/PGPAmi23a2_src.lha _________________________________________________________________ ARCHIMEDES PGP * _UK:_ ftp://ftp.demon.co.uk/pub/archimedes/ArcPGP23a _________________________________________________________________ DOCUMENTATION ONLY Want to know more about PGP, but too scared to download the actual program in case the Feds bust down your door? Fetch this. * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/pgp23docA.zip * _US:_ ftp://soda.berkeley.edu/pub/cypherpunks/pgp/pgp23docA.zip _________________________________________________________________ FOREIGN LANGUAGE MODULES These are suitable for most PGP versions. Italian * _IT:_ ftp://ghost.dsi.unimi.it/pub/crypt/pgp-lang.italian.tar.gz * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/pgp-lang.italian.t ar.gz Spanish * _IT:_ ftp://ghost.dsi.unimi.it/pub/crypt/pgp-lang.spanish.tar.gz * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/pgp-lang.spanish.t ar.gz German * _UK:_ ftp://black.ox.ac.uk/src/security/pgp_german.txt Swedish * _UK:_ ftp://black.ox.ac.uk/src/security/pgp_swedish.txt _________________________________________________________________ OTHER SITES Some cryptographic software is available from ftp://van-bc.wimsey.bc.ca/pub/crypto/software/. They're worried about ITAR regulations, so you'll have to read the README file and proceed from there. BBS sites: Colorado Catacombs BBS (See also the entry above for PGP 2.5) (303) 938-9654 (Boulder, Colorado number forwarded to Longmont number) (303) 678-9939 (Longmont, Colorado number) Verified: This morning. Hieroglyphics Voodoo Machine (Colorado) DOS, OS2, and Mac versions. (303) 443-2457 Verified: 5-2-94 For free access for PGP, DLOCK, Secure Drive, etc., log in as "VOO DOO" with the password "NEW" (good for 30 minutes access to free files). Exec-Net (New York) Host BBS for the ILink net. (914) 667-4567 The Ferret BBS (North Little Rock, Arkansas) (501) 791-0124 also (501) 791-0125 Carrying RIME, Throbnet, Smartnet, and Usenet Special PGP users account: login name: PGP USER password: PGP This information from: Jim Wenzel <jim.wenzel(a)grapevine.lrk.ar.us> PGP 2.3A has been posted to the FidoNet Software Distribution Network and should on most if not all Canadian and U.S. nodes carrying SDN software. It has also been posted on almost all of the major private North American BBS systems, thence to countless smaller boards. Consult a list of your local BBSes; most with a sizeable file inventory should carry the program. If you find a version of the PGP package on a BBS or FTP site and it does not include the PGP User's Guide, something is wrong. The manual should always be included in the package. If it isn't, the package is suspect and should not be used or distributed. The site you found it on should remove it so that it does no further harm to others. ARCHIE WHO? Here is the result of an archie search for file names containing "pgp" (not case sensitive) on 5/2/94. The search was limited to 300 matches, because, as you can plainly see, lots of people value their privacy. Note that archie will not find all relevant files at some sites, like the one at csn.org/mpj properly, due to the export control nonsense, but it does find the directory where the PGP documentation is kept. Host gipsy.vmars.tuwien.ac.at Location: /pub/misc FILE -rw-r--r-- 209409 May 7 1993 pgp22.zip FILE -rw-r--r-- 451114 Jul 23 1993 pgp23.tar.gz Host swdsrv.edvz.univie.ac.at Location: /network/misc/Mosaic/Unix/Mosaic-source/Mosaic-2.4/auth FILE -r--r--r-- 520 Apr 11 21:02 pgp-dec FILE -r--r--r-- 530 Apr 11 21:02 pgp-enc Location: /os2/all/diskutil FILE -r--r--r-- 1946 Mar 16 1993 pgp22.txt Host plaza.aarnet.edu.au Location: /micros/amiga/aminet/comm/mail FILE -r--rw-r-- 137861 Jan 26 08:04 PGPMIP.lha FILE -r--rw-r-- 1878 Jan 26 08:04 PGPMIP.readme Location: /micros/amiga/aminet/util/crypt FILE -r--rw-r-- 305056 Dec 26 22:41 PGPAmi23a2_src.lha FILE -r--rw-r-- 5569 Dec 26 22:41 PGPAmi23a2_src.readme FILE -r--rw-r-- 342426 Dec 26 22:41 PGPAmi23a_2.lha FILE -r--rw-r-- 820 Dec 26 22:41 PGPAmi23a_2.readme FILE -r--rw-r-- 96585 Sep 30 1993 PGPAmi23aplus.lha FILE -r--rw-r-- 712 Sep 30 1993 PGPAmi23aplus.readme FILE -r--rw-r-- 576574 Sep 20 1993 PGPAmiga2_3a.lha FILE -r--rw-r-- 5221 Sep 20 1993 PGPAmiga2_3a.readme FILE -r--rw-r-- 55993 Mar 21 04:41 PGPSendMail2_0.lha FILE -r--rw-r-- 1455 Mar 21 04:41 PGPSendMail2_0.readme FILE -r--rw-r-- 17141 Feb 28 19:23 StealthPGP1_0.lha FILE -r--rw-r-- 1198 Feb 28 19:23 StealthPGP1_0.readme Location: /micros/pc/garbo/pc/crypt FILE -r--r--r-- 209679 Mar 7 1993 pgp22.zip FILE -r--r--r-- 62885 Oct 9 00:00 pgpfront.zip FILE -r--r--r-- 71330 Jan 4 15:00 pgpshe30.zip Location: /micros/pc/garbo/pc/source FILE -r--r--r-- 521820 Mar 7 1993 pgp22src.zip Location: /micros/pc/garbo/windows/util FILE -r--r--r-- 13825 Sep 3 1993 pgpwin11.zip Location: /usenet/FAQs/alt.answers DIRECTORY drwxr-xr-x 512 Apr 18 09:56 pgp-faq Location: /usenet/FAQs DIRECTORY drwxr-xr-x 512 Apr 18 10:09 alt.security.pgp Location: /usenet/FAQs/news.answers DIRECTORY drwxr-xr-x 512 Apr 18 09:45 pgp-faq Host luga.latrobe.edu.au Location: /archive-disk2/os2/all/diskutil FILE -r--r--r-- 1946 Mar 16 1993 pgp22.txt Host sunb.ocs.mq.edu.au Location: /PC/Crypt FILE -r--r--r-- 219951 Sep 14 1993 pgp23.zip Host nic.switch.ch Location: /mirror/Mosaic/Mosaic-source/Mosaic-2.4/auth FILE -rw-rw-r-- 520 Apr 11 23:02 pgp-dec FILE -rw-rw-r-- 530 Apr 11 23:02 pgp-enc Location: /mirror/atari/Utilities FILE -rw-rw-r-- 280576 Apr 15 16:18 pgp23ab.lzh FILE -rw-rw-r-- 29526 Apr 15 16:18 pgpshl06.zip Location: /mirror/os2/all/diskutil FILE -rw-rw-r-- 1946 Mar 16 1993 pgp22.txt Location: /mirror/vms/DECUS/vlt93b/vltextra FILE -rw-rw-r-- 192196 Mar 19 1993 pgp22.zip FILE -rw-rw-r-- 481215 Mar 19 1993 pgp22src.zip Location: /mirror/vms/DECUS/vms92b/hkennedy FILE -rw-rw-r-- 187758 Dec 14 1992 pgp21.zip FILE -rw-rw-r-- 433713 Dec 14 1992 pgp21src.zip Host gatekeeper.dec.com Location: /.0/BSD/FreeBSD/FreeBSD-current/src/usr.bin/file/magdir FILE -r--rw-r-- 478 Jun 24 1993 pgp Location: /.0/BSD/NetBSD/NetBSD-current/src/usr.bin/file/magdir FILE -r--r--r-- 478 Dec 16 23:10 pgp Location: /.3/net/infosys/mosaic/Mosaic-source/Mosaic-2.2/auth FILE -r--r--r-- 520 Feb 8 13:20 pgp-dec FILE -r--r--r-- 530 Feb 8 13:20 pgp-enc Location: /.3/net/infosys/mosaic/Mosaic-source/Mosaic-2.3/auth FILE -r--r--r-- 520 Apr 8 11:38 pgp-dec FILE -r--r--r-- 530 Apr 8 11:38 pgp-enc Location: /.3/net/infosys/mosaic/Mosaic-source/Mosaic-2.4/auth FILE -r--r--r-- 520 Apr 11 14:02 pgp-dec FILE -r--r--r-- 530 Apr 11 14:02 pgp-enc Host hpcsos.col.hp.com Location: /mirrors/.hpib1/NetBSD/NetBSD-current/src/usr.bin/file/magdir FILE -r--r--r-- 478 Dec 17 00:10 pgp Host qiclab.scn.rain.com Location: /pub/mail FILE -rw-r--r-- 537455 Jan 18 1993 pgp-2.1.tar.Z Host world.std.com Location: /src/wuarchive/doc/EFF/EFF/Policy/Crypto/Tools DIRECTORY drwxr-xr-x 8192 Apr 21 02:43 PGP Location: /src/wuarchive/doc/EFF/EFF/Policy/Crypto/Tools/PGP FILE -r--r--r-- 71064 Jan 13 16:57 pgpshe30.zip Location: /src/wuarchive/packages/NCSA/Web/Mosaic-source/Mosaic-2.2/auth FILE -r--r--r-- 520 Feb 8 21:20 pgp-dec FILE -r--r--r-- 530 Feb 8 21:20 pgp-enc Location: /src/wuarchive/packages/NCSA/Web/Mosaic-source/Mosaic-2.3/auth FILE -r--r--r-- 520 Apr 8 18:38 pgp-dec FILE -r--r--r-- 530 Apr 8 18:38 pgp-enc Location: /src/wuarchive/packages/NCSA/Web/Mosaic-source/Mosaic-2.4/auth FILE -r--r--r-- 520 Apr 11 21:02 pgp-dec FILE -r--r--r-- 530 Apr 11 21:02 pgp-enc Host quepasa.cs.tu-berlin.de Location: /.cdrom0/security FILE -r-xr-xr-x 71064 Mar 5 11:51 pgpshe30.zip Host sun.rz.tu-clausthal.de Location: /pub/atari/misc DIRECTORY drwxr-xr-x 512 Dec 30 19:56 pgp Location: /pub/atari/misc/pgp FILE -rw-r--r-- 280454 Oct 11 00:00 pgp23ab.lzh Location: /pub/msdos/utils/security FILE -rw-rw-r-- 209679 Jun 21 1993 pgp22.zip Location: /pub/unix/admin/security DIRECTORY drwxrwxr-x 512 Sep 19 1993 pgp Location: /pub/unix/admin/security/pgp FILE -rw-rw-r-- 209409 Mar 12 1993 pgp22.zip FILE -rw-rw-r-- 521550 Mar 12 1993 pgp22src.zip FILE -rw-rw-r-- 219951 Jun 23 1993 pgp23.zip FILE -rw-rw-r-- 680985 Sep 19 1993 pgp23A.tar.Z FILE -rw-rw-r-- 221332 Sep 19 1993 pgp23A.zip FILE -rw-rw-r-- 88070 Sep 19 1993 pgp23docA.zip FILE -rw-rw-r-- 998 Sep 19 1993 pgp23sigA.asc FILE -rw-rw-r-- 547178 Sep 19 1993 pgp23srcA.zip Host hermes.hrz.uni-bielefeld.de Location: /.mnt1/systems/os2/all/diskutil FILE -r--r--r-- 1946 Mar 16 1993 pgp22.txt Host sun1.ruf.uni-freiburg.de Location: /misc FILE -rw-r--r-- 680985 Mar 11 14:15 pgp23A.tar.Z Host rzsun2.informatik.uni-hamburg.de Location: /pub/doc/news.answers DIRECTORY drwxr-xr-x 512 Apr 18 05:15 pgp-faq Location: /pub/security/tools/crypt DIRECTORY drwxr-xr-x 512 Feb 18 22:05 pgp Location: /pub/security/tools/crypt/pgp FILE -r--r--r-- 449455 Jun 21 1993 pgp23.tar.gz FILE -rw-rw-r-- 17798 May 26 1993 pgputils.zip Host askhp.ask.uni-karlsruhe.de Location: /pub/aegee/tmp FILE -rw-rw-r-- 103448 Mar 12 17:18 pgp23A.zip Location: /pub/infosystems/mosaic/Mosaic-source/Mosaic-2.4/auth FILE -rwxr--r-- 520 Apr 11 23:02 pgp-dec FILE -rwxr--r-- 530 Apr 11 23:02 pgp-enc Host ftp.uni-kl.de Location: /pub1/unix/security DIRECTORY drwxrwxr-x 512 Feb 24 1993 pgp Location: /pub1/unix/security/pgp FILE -rw-rw-r-- 536118 Dec 10 1992 pgp21.tar.Z FILE -rw-rw-r-- 187758 Dec 10 1992 pgp21.zip FILE -rw-rw-r-- 436302 Dec 10 1992 pgp21src.zip FILE -rw-rw-r-- 92405 Feb 19 1993 pgprtest.tar.Z FILE -rw-rw-r-- 17798 Feb 5 1993 pgputils.zip Location: /pub3/amiga/aminet/comm/mail FILE -rw-rw-r-- 137861 Jan 26 14:04 PGPMIP.lha FILE -rw-rw-r-- 1878 Jan 26 14:04 PGPMIP.readme Location: /pub3/amiga/aminet/util/crypt FILE -rw-rw-r-- 305056 Dec 27 04:41 PGPAmi23a2_src.lha FILE -rw-rw-r-- 5569 Dec 27 04:41 PGPAmi23a2_src.readme FILE -rw-rw-r-- 342426 Dec 27 04:41 PGPAmi23a_2.lha FILE -rw-rw-r-- 820 Dec 27 04:41 PGPAmi23a_2.readme FILE -rw-rw-r-- 96585 Oct 1 00:00 PGPAmi23aplus.lha FILE -rw-rw-r-- 712 Oct 1 00:00 PGPAmi23aplus.readme FILE -rw-rw-r-- 576574 Sep 20 1993 PGPAmiga2_3a.lha FILE -rw-rw-r-- 5221 Sep 20 1993 PGPAmiga2_3a.readme FILE -rw-rw-r-- 55993 Mar 21 20:41 PGPSendMail2_0.lha FILE -rw-rw-r-- 1455 Mar 21 20:41 PGPSendMail2_0.readme FILE -rw-rw-r-- 118058 Apr 15 10:20 PGP_german_docs.lha FILE -rw-rw-r-- 234 Apr 15 10:20 PGP_german_docs.readme FILE -rw-rw-r-- 17141 Mar 1 12:23 StealthPGP1_0.lha FILE -rw-rw-r-- 1198 Mar 1 12:23 StealthPGP1_0.readme Host minnie.zdv.uni-mainz.de Location: /pub/amiga/util/aminet/crypt FILE -r--r--r-- 305056 Dec 27 03:41 PGPAmi23a2_src.lha FILE -r--r--r-- 5569 Dec 27 03:41 PGPAmi23a2_src.readme FILE -r--r--r-- 342426 Dec 27 03:41 PGPAmi23a_2.lha FILE -r--r--r-- 820 Dec 27 03:41 PGPAmi23a_2.readme Location: /pub/atari/misc DIRECTORY drwxr-xr-x 512 Dec 30 17:56 pgp Location: /pub/atari/misc/pgp FILE -rw-r--r-- 280454 Oct 11 00:00 pgp23ab.lzh Host von-neum.uni-muenster.de Location: /pub/unix FILE -rw-rw---- 449445 Mar 24 13:04 pgp23.tar.gz Host inf.informatik.uni-stuttgart.de Location: /pub/net FILE -r--r--r-- 680985 Aug 5 1993 pgp23A.tar.Z Host net-1.iastate.edu Location: /pub/netbsd/NetBSD-current/src/src/usr.bin/file/magdir FILE -r--r--r-- 478 Dec 17 01:10 pgp Host jhunix.hcf.jhu.edu Location: /pub/public_domain_software/NetBSD/usr/src/usr.bin/file/magdir FILE -rw-r--r-- 478 Jun 9 1993 pgp Host mintaka.lcs.mit.edu Location: /pub DIRECTORY drwxr-xr-x 512 Jun 18 1993 pgp Location: /pub/pgp FILE -rw-r--r-- 312726 Mar 22 1993 macpgp2.2.cpt.hqx FILE -rw-r--r-- 209409 Mar 22 1993 pgp22.zip FILE -rw-r--r-- 521550 Mar 22 1993 pgp22src.zip FILE -rw-r--r-- 219951 Jun 18 1993 pgp23.zip FILE -rw-r--r-- 17798 Mar 22 1993 pgputils.zip Host josquin.media.mit.edu Location: /pub FILE -rw-r--r-- 321424 Nov 30 20:27 pgp Host archive.egr.msu.edu Location: /pub DIRECTORY drwxr-xr-x 512 Mar 9 18:58 pgp Host xanth.cs.odu.edu Location: /pub DIRECTORY drwxrwxr-x 512 Apr 27 13:38 pgp Location: /pub/pgp FILE -rw-rw-rw- 221332 Apr 27 13:38 pgp23A.zip Host unixd1.cis.pitt.edu Location: /users/i/n/infidel/.Backup/httpd/support/auth FILE -rwxr-xr-x 1019 Jan 24 16:42 pgp-dec FILE -rwxr-xr-x 552 Jan 24 16:42 pgp-enc Location: /users/i/n/infidel/httpd/support/auth FILE -rwxr-xr-x 1019 Jan 24 16:42 pgp-dec FILE -rwxr-xr-x 552 Jan 24 16:42 pgp-enc Host arthur.cs.purdue.edu Location: /pub/pcert/tools/unix DIRECTORY drwxr-xr-x 512 Jul 31 1993 pgp Location: /pub/pcert/tools/unix/pgp FILE -r--r--r-- 209409 Mar 7 1993 pgp22.zip FILE -r--r--r-- 521550 Mar 7 1993 pgp22src.zip Location: /pub/pcert/tools/unix/virus/misc FILE -rw-r--r-- 19277 Feb 23 1993 pgputils.zip Host tehran.stanford.edu Location: /www/httpd_1.2/support/auth FILE -rwxr-xr-x 1019 Jan 24 13:42 pgp-dec FILE -rwxr-xr-x 552 Jan 24 13:42 pgp-enc Host relay.cs.toronto.edu Location: /pub/usenet/news.answers DIRECTORY drwxr-xr-x 512 Apr 22 04:51 pgp-faq Host uceng.uc.edu Location: /pub/wuarchive/doc/EFF/EFF/Policy/Crypto/Tools DIRECTORY drwxr-xr-x 8192 Apr 20 22:43 PGP Location: /pub/wuarchive/doc/EFF/EFF/Policy/Crypto/Tools/PGP FILE -r--r--r-- 71064 Jan 13 11:57 pgpshe30.zip Location: /pub/wuarchive/packages/NCSA/Web/Mosaic-source/Mosaic-2.2/auth FILE -r--r--r-- 520 Feb 8 16:20 pgp-dec FILE -r--r--r-- 530 Feb 8 16:20 pgp-enc Location: /pub/wuarchive/packages/NCSA/Web/Mosaic-source/Mosaic-2.3/auth FILE -r--r--r-- 520 Apr 8 14:38 pgp-dec FILE -r--r--r-- 530 Apr 8 14:38 pgp-enc Location: /pub/wuarchive/packages/NCSA/Web/Mosaic-source/Mosaic-2.4/auth FILE -r--r--r-- 520 Apr 11 17:02 pgp-dec FILE -r--r--r-- 530 Apr 11 17:02 pgp-enc Host server.uga.edu Location: /pub/msdos/mirror/security FILE -r--r--r-- 71064 Feb 3 15:36 pgpshe30.zip Host mrcnext.cso.uiuc.edu Location: /pub/faq/usenet-by-group/alt.answers DIRECTORY drwxr-xr-x 1024 Apr 26 08:08 pgp-faq Location: /pub/faq/usenet-by-group DIRECTORY drwxr-xr-x 1024 Apr 26 13:08 alt.security.pgp Location: /pub/faq/usenet-by-group/news.answers DIRECTORY drwxr-xr-x 1024 Apr 26 08:07 pgp-faq Location: /pub/faq/usenet-by-hierarchy/alt/answers DIRECTORY drwxr-xr-x 1024 Apr 26 08:08 pgp-faq Location: /pub/faq/usenet-by-hierarchy/alt/security DIRECTORY drwxr-xr-x 1024 Apr 26 13:08 pgp Location: /pub/faq/usenet-by-hierarchy/news/answers DIRECTORY drwxr-xr-x 1024 Apr 26 08:08 pgp-faq Host zaphod.ncsa.uiuc.edu Location: /Web/Mosaic-source/Mosaic-2.4/auth FILE -rwxr-xr-x 520 Apr 11 21:02 pgp-dec FILE -rwxr-xr-x 530 Apr 11 21:02 pgp-enc Host f.ms.uky.edu Location: /pub2/NetBSD/NetBSD-current/src/usr.bin/file/magdir FILE -rw-r--r-- 478 Dec 17 02:10 pgp Host pith.uoregon.edu Location: /pub/Solaris2.x/src/httpd_1.1/support/auth FILE -rwxr-xr-x 1019 Jan 24 21:42 pgp-dec FILE -rwxr-xr-x 552 Jan 24 21:42 pgp-enc Host pc.usl.edu Location: /pub/msdos/crypto FILE -rw-r--r-- 187758 Jan 14 1993 pgp21.zip FILE -rw-r--r-- 436302 Jan 14 1993 pgp21src.zip FILE -rw-r--r-- 219951 Jun 23 1993 pgp23.zip Host emx.cc.utexas.edu Location: /pub/mnt/source/www/Mosaic-2.4/auth FILE -rwxr-xr-x 520 Apr 11 12:57 pgp-dec FILE -rwxr-xr-x 530 Apr 11 12:57 pgp-enc Location: /pub/mnt/source/www/NCSA_httpd_1.2/support/auth FILE -rwxr-xr-x 1019 Jan 24 15:42 pgp-dec FILE -rwxr-xr-x 552 Jan 24 15:42 pgp-enc Host tolsun.oulu.fi Location: /pub/unix FILE -r--r--r-- 521550 Jun 16 1993 pgp22src.zip Host gogol.cenatls.cena.dgac.fr Location: /pub/util FILE -rw-r--r-- 534661 Jan 7 1993 pgp-2.1.tar.Z Host grasp1.univ-lyon1.fr Location: /pub/nfs-mounted/ftp.univ-lyon1.fr/mirrors/unix/Mosaic/source/Mosaic-2.2/auth FILE -r--r--r-- 315 Feb 8 22:20 pgp-dec.gz FILE -r--r--r-- 319 Feb 8 22:20 pgp-enc.gz Location: /pub/nfs-mounted/ftp.univ-lyon1.fr/mirrors/unix/Mosaic/source/Mosaic-2.3/auth FILE -r--r--r-- 315 Apr 8 20:38 pgp-dec.gz FILE -r--r--r-- 319 Apr 8 20:38 pgp-enc.gz Location: /pub/nfs-mounted/ftp.univ-lyon1.fr/mirrors/unix/Mosaic/source/Mosaic-2.4/auth FILE -r--r--r-- 315 Apr 11 23:02 pgp-dec.gz FILE -r--r--r-- 319 Apr 11 23:02 pgp-enc.gz Location: /pub/nfs-mounted/ftp.univ-lyon1.fr/usenet-stats/groups/alt FILE -rw-r--r-- 2500 Apr 5 09:39 alt.security.pgp Host ns.urec.fr Location: /pub/reseaux/services_infos/WWW/ncsa/Mosaic-source/Mosaic-2.4/auth FILE -rw-rw-r-- 520 Apr 11 21:02 pgp-dec FILE -rw-rw-r-- 530 Apr 11 21:02 pgp-enc Host granuaile.ieunet.ie Location: /ftpmail-cache/ie/tcd/maths/ftp/src/misc DIRECTORY drwxr-xr-x 512 Dec 2 11:43 pgp Location: /ftpmail-cache/uk/co/demon/ftp/mac DIRECTORY drwxr-xr-x 512 Mar 10 04:01 MacPGP Host walton.maths.tcd.ie Location: /news/news.answers DIRECTORY drwxr-xr-x 512 Apr 18 03:45 pgp-faq Location: /pub/msdos/misc FILE -rw-r--r-- 227625 Apr 18 14:47 pgp23.zip Location: /pub/sboyle DIRECTORY drwxr-xr-x 512 Apr 25 20:20 pgp Location: /src/misc DIRECTORY drwxr-xr-x 512 Apr 21 14:52 pgp Location: /src/network/Mosaic-2.4/auth FILE -rwxr-xr-x 520 Apr 18 12:21 pgp-dec FILE -rwxr-xr-x 530 Apr 18 12:21 pgp-enc Host ghost.dsi.unimi.it Location: /pub/security/crypt FILE -rw-r--r-- 3012 May 15 1993 MacPGP.bugfix.README FILE -rw-r--r-- 45446 May 18 1993 MacPGP2.2.bugfix.sit.hqx FILE -rw-r--r-- 299477 May 18 1993 MacPGP2.2.sit.hqx FILE -rw-r--r-- 27882 Aug 11 1993 hint_trick_pgp00.gz FILE -rw-r--r-- 312726 Mar 20 1993 macpgp2.2.cpt.hqx FILE -rw-r--r-- 422851 Jul 3 1993 macpgp2.3.cpt.hqx FILE -rw-r--r-- 1027543 Jul 21 1993 macpgp2.3src.sea.hqx.pgp FILE -rw-r--r-- 12873 Feb 5 18:22 pgp-lang.italian.tar.gz FILE -rw-r--r-- 91281 Jan 22 12:41 pgp-lang.spanish.tar.gz FILE -rw-r--r-- 680985 Jul 22 1993 pgp23A.tar.Z FILE -rw-r--r-- 231 Jul 26 1993 pgp23A.tar.Z.sig FILE -rw-r--r-- 221332 Jul 26 1993 pgp23A.zip FILE -rw-r--r-- 300 Jul 26 1993 pgp23A.zip.sig FILE -rw-r--r-- 51241 Dec 24 19:31 pgp23ltk.zip FILE -rw-r--r-- 547178 Jul 26 1993 pgp23srcA.zip FILE -rw-r--r-- 232 Jul 26 1993 pgp23srcA.zip.sig FILE -rw-r--r-- 3709 Dec 4 15:02 pgpclient.gz FILE -rw-r--r-- 14209 Nov 29 10:46 pgpd.tar.gz FILE -rw-r--r-- 62619 Oct 27 00:00 pgpfront.zip FILE -rw-r--r-- 13689 May 10 1993 pgpmenu.zip FILE -rw-r--r-- 71064 Jan 22 11:59 pgpshe30.zip FILE -rw-r--r-- 142993 Feb 5 18:55 pgptools.zip FILE -rw-r--r-- 17798 Feb 8 1993 pgputils.zip FILE -rw-r--r-- 13825 Sep 20 1993 pgpwin11.zip FILE -r--r--r-- 1043163 Feb 15 12:54 public-keys.pgp FILE -r--r--r-- 1042460 Feb 15 05:39 public-keys.pgp.old Host isfs.kuis.kyoto-u.ac.jp Location: /BSD/FreeBSD/FreeBSD-current/src/usr.bin/file/magdir FILE -r--r--r-- 478 Jun 24 1993 pgp Location: /BSD/NetBSD/NetBSD-current/src/usr.bin/file/magdir FILE -r--r--r-- 478 Dec 16 23:10 pgp Location: /ftpmail/ftp.dit.co.jp/pub/security/tools FILE -rw-rw-r-- 422851 Apr 21 21:57 macpgp2.3.cpt.hqx Location: /ftpmail/ftp.nig.ac.jp/pub/security DIRECTORY drwxrwxr-x 512 Dec 18 04:31 PGP Location: /ftpmail/ftp.nig.ac.jp/pub/security/PGP DIRECTORY drwxrwxr-x 512 May 22 1993 MacPGP FILE -rw-rw-r-- 521550 May 20 1993 pgp22src.zip FILE -rw-rw-r-- 680985 Dec 18 04:29 pgp23A.tar.Z FILE -rw-rw-r-- 231 Dec 18 04:31 pgp23A.tar.Z.sig Host theta.iis.u-tokyo.ac.jp Location: /pub1/security/docs/news.answers DIRECTORY drwxr-xr-x 512 Apr 28 17:33 pgp-faq Location: /pub1/security/tools FILE -rw-r--r-- 422851 Mar 6 01:16 macpgp2.3.cpt.hqx FILE -rw-r--r-- 451124 Oct 17 00:00 pgp23.tar.gz FILE -rw-r--r-- 680985 Feb 20 23:06 pgp23A.tar.Z FILE -rw-r--r-- 231 Feb 20 23:06 pgp23A.tar.Z.sig Location: /pub2/FreeBSD/FreeBSD-current/src/usr.bin/file/magdir FILE -rw-r--r-- 478 Jun 24 1993 pgp Host news.cfi.waseda.ac.jp Location: /pub2/FreeBSD/FreeBSD-current/src/usr.bin/file/magdir FILE -r--r--r-- 478 Jun 24 1993 pgp Host rena.dit.co.jp Location: /pub/security/docs/news.answers DIRECTORY drwxr-xr-x 512 Mar 1 16:53 pgp-faq Location: /pub/security/tools FILE -rw-r--r-- 422851 Mar 6 01:16 macpgp2.3.cpt.hqx FILE -rw-r--r-- 451124 Oct 17 00:00 pgp23.tar.gz FILE -rw-r--r-- 680985 Feb 20 23:06 pgp23A.tar.Z FILE -rw-r--r-- 231 Feb 20 23:06 pgp23A.tar.Z.sig Host mtecv2.mty.itesm.mx Location: /pub/Mosaic/NCSA-Mirror/Mosaic-source/Mosaic-2.4/auth FILE -r--r--r-- 520 Apr 12 03:02 pgp-dec FILE -r--r--r-- 530 Apr 12 03:02 pgp-enc Location: /pub/usenet/news.answers DIRECTORY drwxr-xr-x 512 Apr 18 07:06 pgp-faq Host ftp.germany.eu.net Location: /pub/comp/atari-st/mint FILE -rw-rw-r-- 2102 Sep 21 1993 pgp23ast.zip Location: /pub/comp/atari-st/utils FILE -rw-rw-r-- 280576 Apr 20 15:42 pgp23ab.lzh FILE -rw-rw-r-- 29526 Apr 20 15:42 pgpshl06.zip Location: /pub/comp/msdos/local/utils DIRECTORY drwxr-xr-x 512 Jul 12 1993 pgp Location: /pub/comp/msdos/local/utils/pgp FILE -rw-r--r-- 449445 Jul 12 1993 pgp23.tar.gz FILE -rw-r--r-- 219951 Jul 12 1993 pgp23.zip Location: /pub/comp/msdos/mirror.garbo/crypt FILE -rw-r--r-- 209679 Mar 7 1993 pgp22.zip FILE -rw-r--r-- 62885 Oct 9 00:00 pgpfront.zip FILE -rw-r--r-- 71330 Jan 4 13:00 pgpshe30.zip Location: /pub/comp/msdos/mirror.garbo/source FILE -rw-r--r-- 521820 Mar 7 1993 pgp22src.zip Location: /pub/comp/os2/mirror.ftp-os2/2_x/diskutil FILE -rw-r--r-- 1946 Mar 16 1993 pgp22.txt Location: /pub/comp/os2/mirror.ftp-os2/all/diskutil FILE -rw-r--r-- 1946 Mar 16 1993 pgp22.txt Location: /pub/infosystems/www/ncsa/Web/Mosaic-source/Mosaic-2.4/auth FILE -rw-r--r-- 520 Apr 11 19:02 pgp-dec FILE -rw-r--r-- 530 Apr 11 19:02 pgp-enc Location: /pub/newsarchive/news.answers DIRECTORY drwxr-xr-x 512 Apr 19 04:12 pgp-faq Host mcsun.eu.net Location: /documents/faq DIRECTORY drwxrwxr-x 512 Apr 20 03:51 pgp-faq Host sol.cs.ruu.nl Location: /NEWS.ANSWERS DIRECTORY drwxrwxr-x 512 Apr 18 11:55 pgp-faq Host ugle.unit.no Location: /faq/alt.answers DIRECTORY drwxr-xr-x 512 Apr 18 07:27 pgp-faq Location: /faq/news.answers DIRECTORY drwxr-xr-x 512 Apr 18 07:26 pgp-faq Host csn.org Location: /fruug DIRECTORY drwxr-xr-x 512 Sep 29 1993 PGP Location: /mpj/public DIRECTORY drwxr-xr-x 512 Apr 18 15:09 pgp Location: /mpj/public/pgp FILE -rw-r--r-- 20941 Feb 22 23:07 Here.is.How.to.MacPGP! FILE -rw-r--r-- 687646 Feb 1 07:45 pgp-elm.gz FILE -rw-r--r-- 26905 Feb 22 18:03 pgp-msgs-japanese.tar.gz FILE -rw-r--r-- 88070 Nov 6 17:44 pgp23docA.zip FILE -rw-r--r-- 998 Nov 6 17:44 pgp23sigA.asc FILE -rw-r--r-- 179070 Apr 18 15:08 pgpfaq.asc FILE -rw-r--r-- 44956 Apr 18 15:08 pgpfaq01.asc FILE -rw-r--r-- 44836 Apr 18 15:08 pgpfaq02.asc FILE -rw-r--r-- 44873 Apr 18 15:08 pgpfaq03.asc FILE -rw-r--r-- 45118 Apr 18 15:08 pgpfaq04.asc FILE -rw-r--r-- 3460 Apr 18 15:08 pgpfaq05.asc Host ftp.eff.org Location: /pub/EFF/Policy/Crypto/Tools DIRECTORY drwxr-xr-x 512 Apr 20 02:58 PGP Location: /pub/EFF/Policy/Crypto/Tools/PGP FILE -rw-r--r-- 71064 Jan 13 11:57 pgpshe30.zip Host sune.stacken.kth.se Location: /disk2/OS/NetBSD/NetBSD-current/src/usr.bin/file/magdir FILE -r--r--r-- 478 Dec 17 07:10 pgp Host isy.liu.se Location: /pub/misc DIRECTORY drwxr-xr-x 512 Sep 19 1993 pgp Location: /pub/misc/pgp/2.1 FILE -rw-r--r-- 536118 Jan 11 1993 pgp21.tar.Z FILE -rw-r--r-- 187758 Jan 11 1993 pgp21.zip FILE -rw-r--r-- 436302 Jan 11 1993 pgp21src.zip Location: /pub/misc/pgp/2.2 FILE -rw-r--r-- 209409 Mar 10 1993 pgp22.zip FILE -rw-r--r-- 521550 Mar 10 1993 pgp22src.zip Location: /pub/misc/pgp/2.3 FILE -rw-r--r-- 219951 Jun 17 1993 pgp23.zip Location: /pub/misc/pgp/2.3A FILE -rw-r--r-- 422851 Sep 19 1993 macpgp2.3.cpt.hqx FILE -rw-r--r-- 680985 Sep 19 1993 pgp23A.tar.Z FILE -rw-r--r-- 221332 Sep 19 1993 pgp23A.zip FILE -rw-r--r-- 998 Sep 19 1993 pgp23sigA.asc FILE -rw-r--r-- 547178 Sep 19 1993 pgp23srcA.zip Host lth.se Location: /pub/netnews/news.answers DIRECTORY drwxr-xr-x 512 Apr 18 03:44 pgp-faq Host krynn.efd.lth.se Location: /pub/security FILE -rw-r--r-- 521550 Jul 24 1993 pgp22src.zip Host leif.thep.lu.se Location: /pub/Misc FILE -rw-r--r-- 221332 Jul 23 1993 pgp23A.zip Host ftp.luth.se Location: /pub/NetBSD/NetBSD-current/src/usr.bin/file/magdir FILE -r--r--r-- 478 Dec 17 08:10 pgp Location: /pub/amiga/.1/comm/mail FILE -rw-r--r-- 137861 Jan 26 15:04 PGPMIP.lha FILE -rw-r--r-- 1878 Jan 26 15:04 PGPMIP.readme Location: /pub/amiga/util/crypt FILE -rw-r--r-- 305056 Dec 27 05:41 PGPAmi23a2_src.lha FILE -rw-r--r-- 5569 Dec 27 05:41 PGPAmi23a2_src.readme FILE -rw-r--r-- 342426 Dec 27 05:41 PGPAmi23a_2.lha FILE -rw-r--r-- 820 Dec 27 05:41 PGPAmi23a_2.readme FILE -rw-r--r-- 96585 Oct 1 00:00 PGPAmi23aplus.lha FILE -rw-r--r-- 712 Oct 1 00:00 PGPAmi23aplus.readme FILE -rw-r--r-- 576574 Sep 20 1993 PGPAmiga2_3a.lha FILE -rw-r--r-- 5221 Sep 20 1993 PGPAmiga2_3a.readme FILE -rw-r--r-- 55993 Mar 21 21:41 PGPSendMail2_0.lha FILE -rw-r--r-- 1455 Mar 21 21:41 PGPSendMail2_0.readme FILE -rw-r--r-- 118058 Apr 15 12:20 PGP_german_docs.lha FILE -rw-r--r-- 234 Apr 15 12:20 PGP_german_docs.readme FILE -rw-r--r-- 17141 Mar 1 13:23 StealthPGP1_0.lha FILE -rw-r--r-- 1198 Mar 1 13:23 StealthPGP1_0.readme Location: /pub/infosystems/www/ncsa/Mosaic-source/Mosaic-2.2/auth FILE -r--r--r-- 520 Feb 8 22:20 pgp-dec FILE -r--r--r-- 530 Feb 8 22:20 pgp-enc Location: /pub/infosystems/www/ncsa/Mosaic-source/Mosaic-2.3/auth FILE -r--r--r-- 520 Apr 8 20:38 pgp-dec FILE -r--r--r-- 530 Apr 8 20:38 pgp-enc Location: /pub/infosystems/www/ncsa/Mosaic-source/Mosaic-2.4/auth FILE -r--r--r-- 520 Apr 11 23:02 pgp-dec FILE -r--r--r-- 530 Apr 11 23:02 pgp-enc Host cs6400.mcc.ac.uk Location: /pub/src FILE -r--r--r-- 455861 Feb 22 15:38 pgp23A.tar.gz - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.4 mQCNAi0aFSUAAAEEAOCOKpaLepvJCFgIR4m+UvZe0IN8g7Guwc+6GH4u6UGTPxQO iAhk/MJ7E8LE4c55A1G8to2W4y3aKAHvi9QCYKnsLV8Ag0BYWo3bGGTPEfkS7NAI N+Zy6vSjuF1D6MUnbvrQJ5p4efz7a28iYRKoAdan2bfnvIYWUD9nBjyFM+vFAAUR tDdNaWNoYWVsIFBhdWwgSm9obnNvbiA8bXBqQGNzbi5vcmc+IG1wajQgW2V4cCAz MSBEZWMgOTRdiQCVAgUQLTqfXj9nBjyFM+vFAQGU7wP/ZuuHfdAnCIblNCtbLLG8 39CSg6JIVa3KWfe0WIz6dXFU3cvl2Wt094kJgZ+Nmq01INWlib2lTOznbkA9sV1W q0aJSBHFWQH29qGmIdEqThs7A5ES2w8eRjJD80lxHodRIkBcC5KI6x4Mxo8cib5V BrwsvtG0+81HD6Mrpvc+a0GJAJUCBRAtJc2rZXmEuMepZt0BAe4hA/9YANYPY4Z3 1pXv2mT6ReC09cZS5U3+xxC5brQdLsQGKuH6QVs/b5oc6NV84sh8A9tZyHG2067o 3XIEyN7PPQzRm2UUnHHqw9lBCNhMiFQsAJi4W+m8zXrVrpJWK0Wv61eV2/XIQl0V d4lxu0r+MNRP6ID6FBzA4C9rO+RYEZmwOIkAlQIFEC0aGRzb/VZRBVJGuQEBfaUD /3c2h//kg843OIcYHG4gMDqdeeZLzGlp3RVvh0Rs3/T0YylJZGjPL2L/BF/vfLlB 9E2Urh9mDG/7hiB5FncrUnkmN63IkSj+K9YyfPyYxBVx06Srj8ZzYynh0N+zledd 6cnwxRXhaD3Wc4EfSNR7BH9M2rjkGzyb5to9cgBb0ng+ =BLg5 - -----END PGP PUBLIC KEY BLOCK----- I didn't have to generate a new key to use version 2.5, but I think keys should be changed periodically anyway to limit damages just in case a key got compromised and I didn't know about it. - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.5 mQCNAi3P6L4AAAEEAM4qXLLvN7dOVuEOIMjX3AFB8HtsCeYECF428Z1dVSf8OMGr KbTjGpuy0WvkigHm0yZmfmAdS8GkLReFmwv36TbhYYvjRaTou+qFjC9um9j4UPP3 /337HTEvFC+oVtCcqLVn2Xv0tTO/KB4nfbash8tzPZWn0WUfpQ9rDjx3TioRAAUR tCJNaWNoYWVsIFBhdWwgSm9obnNvbiA8bXBqQGNzbi5vcmc+tB1tcGo2IDxtcGpv aG5zb0BueXguY3MuZHUuZWR1PokAlQIFEC3P7AA/ZwY8hTPrxQEBmEoD/RJZure0 ghGjOq2qxYIgrd8xebuFEchOQZwInerWd0izjpIMmfh3zlgkgejUhEfPafwCTYg6 BMdbxjNzYwC8/rq/R4EGR6pTe7dJqhvFfvzzLZyjBarX7lw6TJ2Oyt9oFMSQbGwF /BKqc0Ymr/8EmT+JsEDnypepm41otWMyYFfSiQCVAgUQLc/rww9rDjx3TioRAQF0 igQAkRrmuAmF1QLp1gFRxqMLw+dDzAtUjFpUrpvqN8yDu/TS3Ue/GdvBECFCzbcD jA3gGviXBWfRx4w6KRVpqTSsfJt5IvcrTbYGcscIQWHPzqLiq8iu22+Ao2ImcDUB Lu+Z+Wo2Ok00DnvAnzqjXrffo6Eq2qOoGhBlFfStXUCMvbe0HU1pa2UgSm9obnNv biA8bXBqQG5ldGNvbS5jb20+tDBEb24ndCB1c2UgZm9yIGVuY3J5cHRpb24gYWZ0 ZXIgMzEgRGVjZW1iZXIgMTk5NS60I01pY2hhZWwgSm9obnNvbiA8bWlrZWpAZXhh Ynl0ZS5jb20+tDBNaWNoYWVsIFBhdWwgSm9obnNvbiA8NzEzMzEuMjMzMkBjb21w dXNlcnZlLmNvbT60KU1pY2hhZWwgUC4gSm9obnNvbiA8bS5wLmpvaG5zb25AaWVl ZS5vcmc+ =w6Cu - -----END PGP PUBLIC KEY BLOCK----- ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj(a)csn.org ftp:csn.org//mpj/README.MPJ for crypto stuff | | |||/ /_\ | aka mpj(a)netcom.com mpjohnson(a)ieee.org mikej(a)exabyte.com | | |||\ ( | m.p.johnso(a)nyx.cs.du.edu CIS 71331,2332 PGP key by finger | | ||| \ \_/ |___________________________________________________________| -----BEGIN PGP SIGNATURE----- Version: 2.4 iQCVAgUBLdKNkD9nBjyFM+vFAQFC0wQApwvxO9KIYScX7W6+W+UVPzPBwDDWx1f7 PZLd6ltBHZmsgYFiJxEJ7KXTtAVRLwcJS4/jvmsp1fGBrsg2fo1Ej48Zu1JJb6TY W9M5heasDVeKMoSukF7I4uY0LXUbZyYWfgxlbv2gTgwD9uj3h7PwnhhI5Ou70ll1 rcfs4f4dwE8= =YRGv -----END PGP SIGNATURE-----

1 0

BOYCOTT AT&T
by John K Clark 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- It seems that the Government of the USA has been interfering with the free market to reward AT&T , I don't know how much AT&T's support of the Clipper Chip had to do with it but I'm sure it didn't hurt. In the May 13 New York Times: >The AT&T Corporation's winning bid for a $4 billion contract to >modernize Saudi Arabia's phone system ,WHICH HAD BEEN SUPPORTED >BY HEAVY CLINTON ADMINISTRATION LOBBYING , was hundreds of >millions of dollars higher than other bids [...] The huge-scale >deal, which was announced on Monday is the biggest >telecommunications contract in history. I think it's important for company's to realize there is also a downside for supporting Clipper. As a start ,I don't see how any self respecting Cypherpunk or Extropian could use AT&T as their personal long distance carrier . AT&T 's not the only company in bed with the government over Clipper (INTEL) but it is the most visible and the easiest to boycott, MCI and Sprint do a fine job. If 5% of the Internet users quit AT&T it would make other companies think twice before they endorse Clipper. John K Clark johnkc(a)well.sf.ca.us -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCzAgUBLdOeHX03wfSpid95AQEfMATw08p59yySy+t6yE87anzQF8MThp4gnHuz GXAvOYN4ibQjybLABDYgKXScMUSoBu5bxlI0PdtYIRVzc4SHEBLha7IR01I7ysqE oyIzweQuPC96BRivX0+cIVbNyZRMyegxw2DevyK9YGeHLnz12PaMgFwH5jzfapVO IXvWnkmmYbu4AuT8Ej3r1gPvKRzq4xb7oIOiOVWUpAd+bRElGcE= =rfvk -----END PGP SIGNATURE-----

2 1

List moderation
by Hal 17 Dec '03

17 Dec '03

Two comments: First, from his past comments, I think it very unlikely that Eric Hughes will want to see this list moderated. However, he has indicated that he would have no objection to a second list, run by someone else, which took all posts from the CP list and moderated them, filtered them, encrypted them, or whatever. So some site would be needed to run the moderated list. Second, is anyone actually willing and able to do this job? I certainly don't have time. How much delay is the moderation process likely to introduce? How available can the moderators be to handle and process incoming mail? This seems like a potentially very large time commitment by the moderators with little reward. Hal

3 3

Message brokering
by GERSTEIN＠SCSUD.CTSTATEU.EDU 17 Dec '03

17 Dec '03

Hey Nobody- I could use some GhostMarks, so let's make a deal! Drop me a line Adam Gerstein GERSTEIN(a)SCSU.CTSTATEU.EDU -=-=-=- -----BEGIN PGP SIGNATURE----- Version: 2.3 iQBVAgUBLc0c/AT73QJlKKVlAQGV5QIAmusRN0C58o/ScjA1/V7Mq77XurUi3Ktk XZfUXkk6yLJtxtKj5kIddxMiJISfRLbNFvKkAv7LFbYDAdI0RYpnxg== =vEVx -----END PGP SIGNATURE-----

1 0

Re: Message Havens
by David Scheidt 17 Dec '03

17 Dec '03

Thus spake SINCLAIR DOUGLAS N <sinclai(a)ecf.toronto.edu>: > klbarrus(a)owlnet.rice.edu (Karl Lui Barrus) writes: >> Maybe I wasn't clear in what the "message haven" offered... I'm trying >> to get away from the penet style mapping tables, persistent >> information tying you and your pseudonym, and solve the "unsolicited >> anonymous mail" problem. The message haven requires no trust, no >> tables, no information since it just accepts message and files them, >> and if you retrieve all the message, the haven can't figure out which >> ones you are interested in! >This flavour of message haven would not require persistent tables. >A crooked operator /could/ maintain them, but unlike penet they are >not required. Every time you log into a message haven, you tell it >what tags you are interested in. Here the level of trust is similar >to that of a regular remailer. The remailer /could/ keep logs to >destroy your anonymity, but we hope it doesn't. > >I realize this solution is far from ideal. But as I posted before, >I don't believe the numbers favour a message haven where everything >is downloaded. I have this nagging feeling that there is some >very elegant cryptographical way of doing this employing secret >sharing, but I can't actually think of how to do it. Couldn't each message have a short header, which is encrypted with the final recipent's public key? When you go to retrieve mail from the haven, you request the complete list of headers (or at least those that are new). If you can decrypt the header, then the message is for you. You then request that those messages, and also some random messages, be sent to you. If the sender uses one or more current-style remailers to send his/her message to the haven, it would much more difficult to work out a map of who is talking to whom. david -------------------------------------------------------------------------------- David Scheidt PGP 2.3 key by email scheida(a)yang.earlham.edu or finger scheida(a)earlham.edu "If we don't remember what we do, how will we know who we are?" -Ronald Reagan

3 2

Raids in Europe...be careful!
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Here's a report, dated today, that indicates the recent "software piracy" issue (MIT/La Macchia, other sites) may be being used to launch raids. Apparently this guy, in Italy, did not (his claim) have any pirated software on his machine(s), but it was seized by the Italian feds. Other sites, too, I gather. This is only a SPECULATION here: With the Clipper program foundering, and reaction very negative, and government official wringing their hands at their inability to get a handle on things (control), there may be alternate strategies put into play. A crackdown on pirated material could be one avenue. Net porn could be another. And should there be some highly visible case involving encryption, bombers, child porn, terrorists, whatever, action could be swift. Briefly, let me urge you all to carefully think about this. Blatantly illegal material on your systems could play into their hands. No, I don't mean "free speech" issues...attacking _that_ would be a difficult task. I mean pirated software in a location accessible to the outside world, pornographic GIFs or whatever similarly accessible, and so forth. (Someone recently asked if ftp sites could be anonymously loaded (put) with items...this is worrisome, though I'm certainly not accusing that anonymous person of any ill intent. Just with the climate and all...) I'm not playing net.cop. I just think Cypherpunks have enough interesting--and ultimately very important--things to think about without getting caught up in a criminal prosecution of software piracy, child pornography, or the like. Just my personal view, you understand. I hope my concern is premature (I have no doubt that sooner or later there will come a time of collision between Our Side and Their Side, and that we will have to stand against Randall Flagg, DIRNSA). Here's the Italian case: From: zbig(a)junior.wariat.org (Zbigniew J. Tyrlik) Newsgroups: alt.bbs.unixbbs,alt.bbs.unixbbs.uniboard,comp.org.eff.talk,comp.bbs.misc Subject: Bad news from iItaly Followup-To: alt.bbs.unixbbs Date: 13 May 1994 07:26:13 -0400 Organization: Akademia Pana Kleksa, Public Access Uni* Site Message-ID: <2qvo4l$b5k(a)junior.wariat.org> Reply-To: staff(a)ita.it Just received this message from Italy. Anyone know what is going wrong with te world ??? >>> included message: >From ita.it!staff Fri May 13 05:32:27 1994 Return-Path: <staff(a)ita.it> Received: from relay.iunet.it by wariat.org with smtp(/\==/\ Smail3.1.28.1 #28 .5) id <m0q1tbS-00037uC(a)wariat.org>; Fri, 13 May 94 05:32 EDT for "|/usr/local/bin/filter -o /usr/zbig/.elm/f ilter_error" Received: from ita.UUCP by relay.iunet.it with UUCP id AA02606 (5.65c8/IDA-1.4.4 for zbig(a)wariat.org) Fri, 13 May 1994 11:36:32 +0200 Received: by ita.it (5.65/ita-mail-drop) id AA09891; Fri, 13 May 94 11:23:03 +0200 From: staff(a)ita.it (Riccardo Pizzi) Message-Id: <9405130923.AA09891(a)ita.it> Subject: Busted!! To: zbig(a)wariat.org Date: Fri, 13 May 94 11:23:02 EET X-Mailer: ELM [version 2.3 PL11] Status: RO Hi Zbig, things are getting really bad here... On Wednesday, 11th of May, at 3:30 pm, the italian Feds came into my house while I was out of town for a consulting business. They went into my bedroom and seized all my equipment, diskettes, tapes. This action was part of a nationwide raid against software piracy that hit some other 40+ FIDONET sites (yes, they seem to have used a Fido nodelist to find out about sites to investigate). Needless to say, I didn't even had DOS on my disk drives, let alone any copyrighted software. Anyway, they have now all my work of the latest 5 (five) years, including all backup copies of UniBoard and related stuff.. and I don't know if I will be ever able to have all my stuff back. I have also lost my nervous.com email address, but I can be reached here as <staff(a)ita.it>; I will try to keep you informed about this (very bad) story. Please, forward this to the alt.bbs.* groups, since I do not have news access here, and am also missing all the email addresses of my customers and friends.. Wish me luck, Rick _\\|//_ ( 0-0 ) -------------------------------o00--(_)--00o------------------------------------ Riccardo Pizzi, SysAdmin Tel: +39 71 204046 I.T.A. Informatica e Fax: +39 71 2073033 Tecnologie Avanzate s.r.l. E-Mail: staff(a)ita.it --------------------------------------------------------------------------------

1 0