From: Ian Hebert Area: Public Key Encryption To: All 29 Jul 94 02:03:10 Subject: 0- FAQ: Where to obtain P ************* Original From: MATHEW@MANTIS.CO.UK * FORWARDED * To: ALL * MESSAGE * Date/Number: 07/14/94 - 0004098 ************* On: HOMEBASE - 3299 - alt.security. |29 ----------------------------------------------------------------------- *@SUBJECT:0- FAQ: Where to obtain PGP source and binaries -0 *@PACKOUT:07-16-94*#Fr Message-ID: Newsgroup: alt.security.pgp Organization: Mantis Consultants, Cambridge. UK. So, you think you might want to get PGP, but you're not sure where to look? If you have access to the World Wide Web (WWW), use the following URL: http://www.mantis.co.uk/pgp/pgp.html For more information about WWW, try the FAQ for comp.infosystems.www. If you don't have WWW, send mail to pgpinfo@mantis.co.uk. (Note the address carefully, be sure to type it correctly.) The mail you send doesn't have to say anything in particular; you'll automatically be sent a list of sites from which you can obtain PGP binaries and sources. If your e-mail address is unreplyable, you won't get a reply. That's your problem. If you don't have ftp for fetching files, you'll need to find out how to do ftp by e-mail. Send e-mail to mail-server@rtfm.mit.edu with send usenet/news.answers/ftp-list/faq in the body. This article is automatically posted every single day, as that's how often I was manually posting it to answer "Where can I get PGP?" questions. No, I won't just post the list of sites every day, that would be a complete waste of bandwidth. mathew -- http://www.mantis.co.uk/~mathew/ Looking for: Bug-tracking systems for UNIX, DOS and Windows * RM 1.3 * Eval Day 161 * Authority will be respected when authority is respectable. 201434369420143436942014343694201434369420143436942014343694718 From: Ian Hebert Area: Public Key Encryption To: All 28 Jul 94 20:27:10 Subject: EFF Analysis of Vice-Pres ************* Original From: MECH@EFF.ORG * FORWARDED * To: ALL * MESSAGE * Date/Number: 07/22/94 - 0000034 ************* On: HOMEBASE - 3563 - comp.org.eff. |29 ----------------------------------------------------------------------- *@SUBJECT:EFF Analysis of Vice-President Gore's Letter on Cryptography Message-ID: <199407222325.TAA26059@eff.org> Newsgroup: comp.org.eff.news Organization: UTexas Mail-to-News Gateway EFF Analysis of Vice-President Gore's Letter on Cryptography Policy ------------------------------------------------------------------- July 22, 1994 Two days ago, Vice-President Al Gore signaled a major setback in the Administration's Clipper program, and a willingness to engage in serious negotiations leading to a comprehensive new policy on digital privacy and security. Many questions remain about the future, but one thing is certain: Clipper is a dead end, and those of us who are concerned about digital privacy have won a new opportunity to shape a better policy. The Vice-President's letter to Rep. Maria Cantwell (D-WA) made it clear that while Clipper might have a small place in the telephone security market, it has no future in the digital world. "...[T]he Clipper Chip is an approved federal standard for telephone communications and not for computer networks and video networks. For that reason, we are working with industry to investigate other technologies for those applications.... We welcome the opportunity to work with industry to design a more versatile, less expensive system. Such a key escrow system would be implementable in software, firmware, hardware, or any combination thereof, would not rely upon a classified algorithm, would be voluntary, and would be exportable." Clipper does not meet most of these criteria, so, according to the Vice- President, it is a dead end. END OF THE LINE FOR CLIPPER -- LONG-RUN EFFORT TO DRIVE MARKET WILL FAIL The premise of the Clipper program was that the government could drive the market toward use of encryption products which incorporated government-based key escrow agents. A series of subtle and not so subtle government actions would encourage private citizens to use this technology, thus preserving law enforcement access to encrypted communications. Clipper was originally announced as the first element of a family of hardware-based, government key escrow encryption devices that would meet security needs for both voice and data communications on into the future. Clipper itself was purely a voice and low-speed data product, but other members of the Skipjack family, including Tessera and Capstone, were to be compatible with Clipper and were intended to lead the way from escrowed encryption in voice to escrowed encryption for data. Plans are already announced, in fact, to use Tessera and Capstone in large government email networks. At the time, the hope was that government use of this technology would push private sector users toward key escrow systems as well. Now, the announcement that the Administration is re-thinking plans for data encryption standards leaves Clipper a stranded technology. No one wants to buy, or worse yet, standardize on, technology which has no upgrade path. As a long-run effort to force the market toward government-escrowed encryption standards, Clipper is a failure. WE STILL MUST WORK FOR VOLUNTARY, OPEN, EXPORTABLE STANDARDS The fight for privacy and security in digital media is by no means over. Though the Administration has backed away from Clipper, and expressed willingness to talk about other solutions, we are pursuing serious progress on the following issues: * Improved telephone encryption standards For the reasons listed by the Vice-President, in addition to the inherent problems of making copies of all your keys available, Clipper is a poor choice for telephone encryption. Industry should develop a standard for truly secure and private telephones, make them available from multiple manufacturers worldwide, and make them interoperate securely with audio conferencing software on multimedia PC's. * Truly voluntary standards Any cryptographic standard adopted by the government for private sector use must be truly voluntary. Voluntary means, to us, that there are statutory guarantees that no citizen will be required or pressured into using the standard for communications with the government, or with others. No government benefits, services, or programs should be conditioned on use of a particular standard, especially if it involves government or private key escrow. * Open standards Standards chosen must be developed in an open, public process, free from classified algorithms. The worldwide independent technical community must be able to create and evaluate draft standards, without restriction or government interference, and without any limits on full participation by the international cryptographic community. * No government escrow systems Any civilian encryption standard which involves government getting copies of all the keys poses grave threats to privacy and civil liberties, and is not acceptable in a free society. * Liberalization of export controls Lifting export controls on cryptography will make the benefits of strong cryptography widely available to our own citizens. U.S. hardware, software and consumer electronics manufacturers will build encryption into affordable products once they are given access to a global marketplace. Today's widespread availability of "raw" cryptographic technology both inside and outside the United States shows that the technology will always be available to "bad guys". The real question is whether our policies will allow encryption to be built into the fabric of our national and international infrastructure, to provide significantly increased individual privacy, improved financial privacy, increased financial security, enhanced freedom of association, increased individual control over identity, improved security and integrity of documents, contracts, and licenses, reduced fraud and counterfeiting, the creation of significant new markets for buying and selling of intellectual property, and a lessened ability to detect and prosecute victimless crimes. These benefits are not free, however. EFF does recognize that new communications technologies pose real challenges to the work of law enforcement. Just as the automobile, the airplane, and even the telephone created new opportunities for criminal activity, and new difficulties for law enforcement, encryption technology will certainly require changes in traditional investigative techniques. We also recognize that encryption will prevent many of the online crimes that will likely occur without it. We further believe that these technologies will create new investigative tools for law enforcement, even as they obsolete old ones. Entering this new environment, private industry, law enforcement, and private citizens must work together to balance the requirements of both liberty and security. Finally, the export controls used today to attempt to control this technology are probably not Constitutional under the First Amendment; if the problems of uncontrolled export are too great, a means of control must be found which does not restrict free expression. CONGRESSIONAL LEADERSHIP TOWARD COMPREHENSIVE POLICY FRAMEWORK IS CRITICAL The efforts of Congresswoman Maria Cantwell, Senator Patrick Leahy, and other members of Congress, show that comprehensive policies on privacy, security and competitiveness in digital communication technologies can only be achieved with the active involvement of Congress. Unilateral policy efforts by the Executive branch, such as Clipper and misguided export control policies, will not serve the broad interests of American citizens and businesses. So, we are pleased to see that the Vice-President has pledged to work with the Congress and the private sector in shaping a forward-looking policy. We see the Vice-President's letter to Congresswoman Cantwell as an important opening for dialogue on these issues. The principles of voluntariness and open standards announced in the Vice- President's letter, as well as those mentioned here, must be incorporated into legislation. We believe that under the leadership of Senator Leahy, Reps. Cantwell, Valentine, Brooks and others, this will be possible in the next congress. EFF is eager to work with the Congress, the Administration, along with other private sector organizations to help formulate a new policy. EFF is also pleased to be part of the team of grass roots activism, industry lobbying, and public interest advocacy which has yielded real progress on these issues. FOR MORE INFORMATION CONTACT: Jerry Berman, Executive Director Daniel J. Weitzner, Deputy Policy Director For the full text of the Gore/Cantwell letter, see: ftp.eff.org, /pub/Alerts/gore_clipper_retreat_cantwell_072094.letter gopher.eff.org, 1/Alerts, gore_clipper_retreat_cantwell_072094.letter http://www.eff.org/pub/Alerts/gore_clipper_retreat_cantwell_072094.letter * RM 1.3 * Eval Day 160 * Authority will be respected when authority is respectable. 201434369420143436942014343694201434369420143436942014343694718 From: Ian Hebert Area: Public Key Encryption To: All 27 Jul 94 22:14:10 Subject: No time to relax ************* Original From: GMCGATH@CONDES.MV.COM * FORWARDED * To: ALL * MESSAGE * Date/Number: 07/22/94 - 0001210 ************* On: HOMEBASE - 3274 - alt.privacy.c |29 ----------------------------------------------------------------------- Message-ID: Newsgroup: alt.privacy.clipper Organization: Conceptual Design The administration's retreat on Clipper can easily be seen as a tactical one. Most of the vocal opposition has come from the computer community. By giving up the battle for now in that area, Clinton and Gore can concentrate on getting it established in voice communications. Then they will have a stronger base for imposing key escrow on data communications at a later date. We need to insist on two goals: (1) That the government stop treating encryption technology as "munitions," stop placing trade barriers on it, and recognize our right to encrypt information securely. (2) That the government refrain from escrowing encryption keys except for its internal use. Anything less than this isn't enough. -- Gary McGath gmcgath@condes.mv.com * RM 1.3 * Eval Day 159 * Authority will be respected when authority is respectable. 201434369420143436942014343694201434369420143436942014343694718 From: Ian Hebert Area: Public Key Encryption To: All 29 Jul 94 19:32:10 Subject: A sample clipper letter ************* Original From: GEDESEVE@AOL.COM * FORWARDED * To: ALL * MESSAGE * Date/Number: 07/21/94 - 0001217 ************* On: HOMEBASE - 3274 - alt.privacy.c |29 ----------------------------------------------------------------------- Message-ID: <30ms3a$etp@search01.news.aol.com> Newsgroup: alt.privacy.clipper Organization: America Online, Inc. (1-800-827-6364) Here is a sample letter based on the EPIC guidelines. Please feel free to use it to mail to Gore and others who still support Clipper. Dear Mr. Vice President, Thank you for your willingness to reconsider the Clinton Administrations views on the Clipper Chip/key escrow policy. Your letter to Rep. Cantwell shows that you are willing to regulate the Information Superhighway with regards to the wishes of the people. However, your stand needs to be taken one step further. While it is excellent that you have expressed support for unclassified algorithms and liability for key escrow agents, these changes in administration policy will mean little if key escrow remains a government required standard for encryption. If Clipper is dead, key escrow must be allowed the same fate. In addition, the ground-swell of anger over the clipper situation will not subside until government support for the use of Clipper in telephones is curtailed as well. The backdoor in Clipper and the unusally secretive methods for testing the algorithms are signs to the general public that Clipper is not a reliable technology. Please publicly test Clipper and the key escrow system extensively before implementing it. Also, the public has yet to see the earlier White House studies done on cryptography. Releasing all documents relating to the reliability, strengths and weaknesses of the key escrow proposal would ease public doubt about the initative. * RM 1.3 * Eval Day 161 * Authority will be respected when authority is respectable. 201434369420143436942014343694201434369420143436942014343694718 From: Luke Neville Area: Public Key Encryption To: All 27 Jul 94 10:19:10 Subject: PGP I am looking to easily set up PGP for my mail -- I am not incompetant with computers but want to know how to : Add a user_id - do I have to get the other party's public key to be able to encrypt it for him so he can read it? And (stupid question coming up) how much of PGP does he need? The .exe and his keys? I already have an external utility in my Blue Wave to handle all the stuff, but it chokes as soon asI write a email and put in a user_id for the recipiant it doesn't recognize. What do I do? cya -l. ... When in doubt, mumble. ... If brains were gunpowder he couldn`t blow his nose 201434369420143436942014343694201434369420143436942014343694718 From: Tim Bradley Area: Public Key Encryption To: All 30 Jul 94 09:26:22 Subject: Apologies Hi All! My feed is experiencing SERIOUS problems both sending and recieving echo-mail AND Net-mail -- so if I haven't answered a post or netmail message, that's why, and I apologize, and would ask you to try again. Hopefully my sysop'll have things back in shape soon. -- Tim Bradley 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 30 Jul 94 13:38:58 Subject: new GenMsg issue! -----BEGIN PGP SIGNED MESSAGE----- GenMsg 4.15 has just been hatched into PUBKEYS and SDS area SOFTDIST for general consumption. GMSG415.ZIP replaces GMSG408.ZIP and adds several functions and improvements. freq GENMSG. OS/2 version of the update is not yet available. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: PGP 2.6 is LEGAL in Zone 1! So USE it! [grin] iQCVAgUBLjqQJcsQPBL4miT5AQHMagP8D+4Hg2GK4NHxPabSXjoRoG078Tw+1uKh F1NRsPale9uSVBrN+BCSZUHRCmGdty12ldzmOHqbpCKAJim18totyYHdeAlCVoE8 Ij73IMNoSpxzaMVVy4yezIRG0IZuWzSshr2p49RLGAd8GGaet4vke6wRUAarTVER IzPSUyycFJo= =5MX1 -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: Ryan Shaw 30 Jul 94 18:00:12 Subject: Re: New to PGP -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 27 Jul 94, Ryan Shaw was quoted as saying: RS> To make this message more on-topic. Since the recent "Steve Winter RS> Episode" what does everyone think about making PGP signatures the RS> norm in Fight-o-Net? Also, what is the view on the use of PGP RS> signatures in Fight-o-Net echos? FidoNews used to have a PGP public-key when Tom Jennings was editor. [sigh] Echomail content is up to the Moderator of every Echo. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: PGP 2.6 is LEGAL in Zone 1! So USE it! [grin] iQCVAgUBLjrNX8sQPBL4miT5AQHc5QQAi8FyP++TaKWkQ9JPjDeFQQv5G5s9d6FO kSGJNpBV2YHjrOElXWZiSmwyG3X5w5jAmK6oa6Ngz5ShwAmD5W8le37hKgH+HBYG Aj4N9IrupUv0n52i8UlrIGedbowFXki5fxg257LJAfbRLF8rhdUC+pZ2xDgBRPJV fISq70PsctM= =TjJh -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: Ryan Shaw 30 Jul 94 18:10:18 Subject: Echo sources [Was: Re: My public key] -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 27 Jul 94, Ryan Shaw was quoted as saying: CB> please put your keys in the PKEY_DROP Echo. RS> Would that echo be available via the Fight-o-Net backbone RS> and/or Planet Connect? not exactly. it IS available from the FidoNet Backbone and PCon. 'Fight-o-Net' is a figment that exists only in the minds of certain folks in New Jersey. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: PGP 2.6 is LEGAL in Zone 1! So USE it! [grin] iQCVAgUBLjrPvcsQPBL4miT5AQFd/AP/eftojtt1CSBKWNTERygSHg4RTO6D3cJr 2u4rV5YIuX/dahSoOH42p2AU/29zoC1J+1iYLOvdpknaxm7exdh50JJ+f9Mrbvba zs+MlxGdyv85/ETbahFhZ6bNeyN7v0n2hZwNPtwyBkJmxVc/OcVkIMbJqW7BVBBS X+knk+tSvP0= =Jm4l -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Jess Williams 30 Jul 94 19:21:08 Subject: PGP VOICE -----BEGIN PGP SIGNED MESSAGE----- Jess Williams wrote in a message to All: JW> Whatever happened to that PGP Voice Idea? I heard that Phil I talked to Phil a few months back, and he was still working on the project then. jason -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLjsLF0jhGzlN9lCZAQHYtAP/YE+zRGByFRntiz3sLTCfDY9oyTG3W08v EBcz4PPXml5ph1Gacv3UyRDubRzdI8sDdC2jX9QfEu+4t2/6I/h4Sl/dMjD99wDU yl68zbYyOYoBljmni6zb8Iuy9NiQOgkpjqXVMtt4M40iCvnE56cuLDvRGt1SRye6 E2PWUpu1lF0= =cQ7y -----END PGP SIGNATURE----- ...Key fingerprint = 60 97 B2 AE 7D 90 11 2F 05 1C 35 98 E9 B9 83 61 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Ryan Shaw 30 Jul 94 19:24:52 Subject: New to PGP -----BEGIN PGP SIGNED MESSAGE----- Ryan Shaw wrote in a message to All: RS> Just testing out my new configuration of PGP with timEd and RS> QEdit. Looks like it worked. Lotta fun, huh? RS> To make this message more on-topic. Since the recent "Steve RS> Winter Episode" what does everyone think about making PGP I think it will make our our position much stronger. And this week's snooze had a digisigged article. Maybe this will open some eyes. RS> signatures the norm in Fight-o-Net? Also, what is the view RS> on the use of PGP signatures in Fight-o-Net echos? DigiSigs are up to the individual mods, I think. I have toyed with the idea of annoucing they are allowed in COLLEGE, which I moderate. Seems like a crowd that would take to the idea. But that would effectively cut off the flow to 106 (houston, I think) where they delete any msg with the string "PGP" in it. . jason -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLjsNMUjhGzlN9lCZAQFUpgQArkMerOsS+Y2n25Jq44vFqbcH5jLKz7vn dx1W9uDLnm1lPLPax1KxcRwwrP/aqluraV3n7wiqZ0BtQ1sbfvjRlMgA0mI4VTom LjOJU39YB9QfegU+P/dk/opUrUmjaGzfzOhNFwzeSiHJk2YyB3/c1385+SAL7B5x CcIn/YXMTuc= =VU6H -----END PGP SIGNATURE----- ...Key fingerprint = 60 97 B2 AE 7D 90 11 2F 05 1C 35 98 E9 B9 83 61 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Christopher Baker 31 Jul 94 11:19:50 Subject: state not sad state advancing [Was: Steve Winter] -----BEGIN PGP SIGNED MESSAGE----- - --> Note: Reply to a message in MODERATOR. Christopher Baker wrote in a message to David Nugent: CB> a digital signature is not something 'sad'. it is something CB> useful and prevents the kind of hoorah now in progress. CB> it's a tool like any other and can be used in several ways. CB> in this case, it could have prevented a hoax. CB> sounds like a good idea to me. [grin] Very, very well put. I think that this hoax will strengthen the case for digisigs. 'Specially since the Snooze had this to say: >> >> Consciousness twitting bomb-drop Eeek: the article published >> last >> week under Steve Winter's name was not written by him. Sure, >> it came >> in via net mail with path lines which made sense, but >> there was no >> pgp sig on it etc., so there's acatually no "proof" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> either way if he >> wrote it or he didn't. But i believe Steve ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Winters did not write the article which was published last week under >> his name, although i did not know this last week. They're making our case for us... I hope people get interested enough to find out about PGP. CB> sTandbYTobemoRtIFiedbytHeSigHTOfthIshoRriblenONEncrYPtEdsi CB> LlysI CB> Gnature!dOitmeanYouwIlLhAvetOwoRkTwIceaShArdTopROvetOThEfe CB> SthAt CB> yOuARenOtsOMeSCumSuCkinGPrIvatEmEsSagerEadeRThAtsHoulDBEPu CB> iNjAi LasSOonaSpOsSiblE?TWo= CB> twO% This stuff kills me! ROTFL!! jason -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLjvuuEjhGzlN9lCZAQG7UwQAksnyTHrJtPeb2L0ZSX3XWllK5AeH+MG+ RbIkF7VH/KeIH36I3PfUfzp02oaMYEoxCLP7a8u1ePdw5ptUSk5G/YKyGQsHESW6 pDHJM9b9CmzgGvPfozgPTgxAwDsynOeEEynco1dV03z2HBpfTVVHlymBGfWm3vA7 xNRrjy88QaI= =HtpY -----END PGP SIGNATURE----- ...Key fingerprint = 60 97 B2 AE 7D 90 11 2F 05 1C 35 98 E9 B9 83 61 201434369420143436942014343694201434369420143436942014343694718 From: Brad Ems Area: Public Key Encryption To: All 31 Jul 94 20:19:18 Subject: Clipper Chip Lecture For all St. Louis BBSers, there will be a free lecture on the Clipper Chip: Where: St. Louis County Library Hedquarters 1647 S. Lindbergh (across from Plaza Frontenac) When : August 12th, 7:30 p.m. What : Individual Privacy v. National Security Who : Jim Burnes, a local consultant will speak on the chip, what it does, what are the pitfalls, and why it is not needed Why : Because it ain't nobody's business but yours Y'all come. We're expecting a big crowd, so get there early! 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 31 Jul 94 18:18:16 Subject: GenMsg update for OS/2 -----BEGIN PGP SIGNED MESSAGE----- has just been hatched into PUBKEYS and SDS area SOFTDIST as: GMSG2107.ZIP replacing GMSG2104.ZIP. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: PGP 2.6 is LEGAL in Zone 1! So USE it! [grin] iQCVAgUBLjwjG8sQPBL4miT5AQFGagP9Hgwnu2Ybp7vDBpQl2ml/mXyCcQUZZpLa B2ZXM+bgI1HAr8G9vI8zGPbcuOq1pa30qfrSxQ02zQsefq8KsNa09MHv2W6zqFcG k5X12UZHQvJlpQSYLdsFy8Oc4aoOU2uGhrM8be2NFLWXHdjkxX53tYKwKDpTE2aq tu1Yq90yFGo= =5F1D -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Aug 94 00:17:46 Subject: PUBLIC_KEYS Echo Guidelines - regular repost -----BEGIN PGP SIGNED MESSAGE----- This is the PUBLIC_KEYS Echo. The purpose of the Echo is to provide a place to discuss public-keys for data privacy within FidoNet and elsewhere. We also consider electronic signature possibilities using public-keys and discuss data and software encryption and the various schemes and programs that produce them. This is a technical Echo with very few rules. Those very few rules are: 1. Stay on-topic. Topics of keys and encryption and related privacy and electronic signature issues are welcome. Others are not. 2. No politics [except as it relates to privacy issues] and no religion. 3. No personal attacks, slurs or innuendo. Stick to issues not personalities. 4. No Private flagged messages in Echomail! Encrypted traffic using public-keys is permitted for the exercise so long as it is on-topic. Don't send person-specific encrypted traffic. Such specific traffic belongs in direct Netmail. Encrypted traffic should be in the form of public-keys or public-key signed messages that can be read by anyone with PGP 2.4+ and your public-key. Include your public-key when sending such messages in case the other end doesn't have it or make them aware of how to get it from your system. 5. This Echo may be traveling around the world so try to be concise. Avoid excessive quoting for one-liner responses. 6. Be aware that Echomail is NOT secure. Don't take anything at face value. 7. The posts in this Echo are the sole responsiblity of the poster. If you need verification, use Netmail. 8. The Moderators will deal with off-topic traffic. Don't respond for them. Links to this Echo will only be curtailed when absolutely necessary so please don't make it necessary. [grin] The Moderators are Christopher Baker [KeyID: 1024/F89A24F9 1994/05/18] and GK Pace [KeyID: 1024/EE38FB41 1994/05/14] at 1:374/14 and 1:374/26, respectively. It is Gated into Zone 2 by Harry Bush at 2:51/2 and into Zone 3 by Jackson Harding at 3:800/857. [thanks, guys!] The other Zones are open [hint, hint]. It is recommended that individual, public-keys be made available via Netmail or by file-request with the magic filename: PGPKEY and that the public-key provided for that request by given a distinctive filename using part or all of each provider's name and address. For example, on my system, a file-request of PGPKEY will give BAK37414.ASC to the requesting system. A magic filename of KEYRING will yield extracts from my Public Keyring as BAKPUB14.ASC. This will avoid duplicate overwriting and make it easier to track the keys. Using standard magic filenames will make it easier to find keys and keyrings on different systems. The PGP and Privacy and encryption related files on each system should be maintained with a magic filename for file request. PGPFILES should be set on all participating systems to allow your current related files to be picked up at any time. It is suggested that the actual filename indicate the origin of the list to avoid confusion and overwriting. PGPFILES requested from this system gets the requestor a file called: PGP37414.LST. The contents of this Echo are archived on 1:374/14 as the area is purged. The current past traffic is in the file PUBKEY.ECO. Archived volumes of past traffic [P_ECHO1.ZIP - P_ECHO99.ZIP for example]. Files on this system are available anytime except 0100-0130 ET and Zone 1 ZMH at 1200-9600+ HST/V32 for FidoNet listed systems only. Request FILES for complete listings. This Echo is currently available on the Zone 1 Backbone. It has been EListed as of ELIST211. Please feel free to announce this Echo in all Nets and Networks. A companion Echo for the purpose of submitting public-keys only is now available as PKEY_DROP Echo. PKEY_DROP may be obtained via the same channels as PUBLIC_KEYS. NOTE: If you lose your secret-key password [or forget it] or your secret-key in a drive crash [because you failed to back it up on floppy], you cannot issue a revocation certificate. In that case, you should make a general announcement in all related Echos that your old key should be disabled using the PGP disable command [PGP -kd userid] for your userid. That keeps your useless key on their keyrings [so they won't be replaced from other lists who didn't get the word] and permits them to add a new key from you without one interfering with the other. Thanks. TTFN. Christopher Baker & GK Pace Moderators -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: PGP 2.6 is LEGAL in Zone 1! So USE it! [grin] iQCVAgUBLjx3XcsQPBL4miT5AQG1jQP+KD3kExxyKDOtR3Obnu6aqvs0xNKOjRfS Nk9b0+ClJfhcodj/HiPzajc1CHkZfH0qKBLoZGMKNbJ5RV5ahiXOQ8YuyDpRvy6P wsIHRyL5Ovs91KRgWGFms6nkH89hoMIfHHBbpIlB77uSSVCN3KDCWDk2N5egviWZ eDE7Go+H2ok= =Yl0S -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Aug 94 00:18:40 Subject: PGP-related filename conventions -----BEGIN PGP SIGNED MESSAGE----- [the following are the standard magicnames for various PGP-related files available from participating FidoNet systems. please adjust your magicnames to match those in the list. this will make it much simpler for folks to find PGP-related stuff they need. thanks] the following is the list of standard PGP-related magic filenames that should be used for uniformity by all who provide such files: PGPKEY for your public-key. make the filename distinctive with your Node number or name. mine is BAK37414.ASC. KEYRING for your public-keyring. make the filename distinctive likewise. mine is BAKPUB14.ASC. REVOKE for any key revocation certificates you might issue. mine is BAKREVOK.ASC. PGPFILES for your PGP/privacy/encryption filelist. mine is PGP37414.LST. PGP for the current version of MSDOS PGP executables and docs. PGPSRC for the current version of PGP source files. PGPALL for both executable and source. PGPAMIGA for Amiga version of PGP. PGPATARI for Atari version of PGP. PGPMAC for Macintosh version of PGP. PGPOS2 for OS/2 version of PGP. PGPUNIX for Unix version [if there ever is one] PGPVAX for Vax version [likewise] [send them the source if they request a Unix or VAX version!] if we all use the same conventions, it will be easy for anyone anywhere to file-request just what they want and get what they expect. [grin] thanks. TTFN. Chris p.s. in addition, some of us compiled PEM public-keys for Internet use. those keys and rings are available as: PEMKEY for your PEM public-key PEMRING for you PEM public-keyring C. -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: PGP 2.6 is LEGAL in Zone 1! So USE it! [grin] iQCVAgUBLjx3lMsQPBL4miT5AQEWiQQAkWarN4AacR1Pq0zacvZyeQ8JdGjomHRl zvR201+g+RbvzWvuLa9UEGJxNb+n4mHcP9bM63KI1fOF5UE4gtT+GU+FAnl3QZWT U5/n8u8preZR4/NgF6kXnPhJ2nbxVzzThhxNd0h/AtC0xUk7T00jEL0B1gWyu4Gv 7zwoSiCI4zc= =KtHr -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Aug 94 00:20:30 Subject: SecureMail Host Routing system info -----BEGIN PGP SIGNED MESSAGE----- The FidoNet (r) SecureMail System 30 Mar 94 Copyright (C) 1994 Jim Cannell [Source: GK Pace, 1993; Christopher Baker, 1994] Introduction: This document describes the SecureMail FidoNet (r) Routing System, its Statement of Purpose, and defines the principles by which it shall be operated. It should be noted that FidoNet is a registered trademark owned by Tom Jennings, used by permission to refer to the FidoNet, a hobbyist network of amateur, independent, interconnected systems (Nodes) providing E-Mail transfer services world-wide. Definition: SecureMail can be defined as a group of FidoNet Sysops who have volunteered to provide an alternative E-Mail routing service within the FidoNet Network. The SecureMail System is a component of the FidoNet Network. SecureMail is NOT an alternative, separate, or distinct network. Statement of Purpose: The primary purpose of Securemail, and reason for its creation is the desire for providing increased privacy in the routing of FidoNet E-Mail. The term privacy as used in the transfer of E-Mail is an arbitrary one. Absolute privacy cannot be expected. The degree of privacy obtained will always be related to the procedure(s), effort used to insure privacy, and should not be expected to be absolute if data is to be communicated from one place to another. Routing of E-Mail, as compared to sending it direct, cannot be expected to have as high of a degree of privacy as might be expected when sending it direct. Those who are engaged in operating the Securemail system do so with the primary goal of insuring that all E-Mail routed thru it be afforded the highest degree of privacy technically possible. Those using the Securemail System can expect to enjoy a higher degree of privacy than other forms of routing, but should not expect absolute privacy. Functional Description: The SecureMail System is a group of individual FidoNet Sysops who have volunteered to work together to provide the SecureMail Routing Service to FidoNet Sysops. This group is organized, but does not have authoritative positions. Each SecureMail Sysop is an independent volunteer furnishing a service. There are no monetary rewards, each Sysop contributes the resources he or she uses to provide the service, including all costs incurred in providing it. The operational structure may appear to have hierarchical order and indeed it does, however such structure implements a routing matrix, not positions of authority. The SecureMail operational philosophy can be described as cooperative autocracy. Each SecureMail Sysop is an independent operator who has volunteered to assume the various responsibilities required of an organized effort. No one is compelled to participate, but participation requires the performance of certain agreed upon functions, standards, and of course interaction as a group. Most of the activities parallel or are incidental to normal FidoNet activities. Routing Hierarchy: The basic routing strategy follows the normal FidoNet pattern of routing thru Zones, Regions, Nets, to Nodes. The difference is that SecureMail traffic is routed thru SecureMail Hosts rather than the FidoNet Hosts. A SecureMail Sysop serving in each position is referred to as a Host. There are functional (not Authoritative) positions such as Zone SecureMail Host (ZSMH) Region SecureMail Host (RSMH) and Net SecureMail Host (NSMH). An International SecureMail Host (ISMH) functions as a central coordinator for this functional hierarchy and maintains the routing lists and this document of intent and mission. Note that at any given time, all positions may not be filled, due to the fact that positions are filled by those who have the means and desire to provide the service of each position. Operational Practices: Each SecureMail Host (SMH) has agreed to route E-Mail (referred to as In-Transit mail) in a manner which provides the highest degree of privacy technically possible. Some variances can be expected, as the technical characteristics of each system differ, however each SecureMail Host strives to provide the best service possible. Specific operational practices include: - In-Transit mail shall not be read. Note that some systems do not provide the ability to restrict a Sysop from viewing In-Transit mail. In such cases the Sysop makes every effort to avoid noticing the content of such E-Mail as they scan thru their message bases. - The content of In-Transit mail shall not be disclosed, or given to anyone but the addressee, except as required for routing thru the SecureMail System. - All SecureMail Hosts agree to route any In-Transit mail they receive. This includes encrypted and clear-signed traffic now refused by some systems in FidoNet. In-Transit mail that cannot be delivered shall be returned to the sender along with a brief explanation of why it could not be delivered. If no local routing via another SMH is available, the mail will be sent directly to its destination by the receiving SMH. - In-Transit mail shall not be censored. Routing of In-Transit mail shall not be refused for any reason even remotely associated to the content of such E-Mail. Note: how could it be if it isn't read in the first place? Avoidance of Liability: Those participating in the SecureMail Routing System do so to provide a service at no cost to those who choose to make use of it. There is no guarantee of performance implied nor accepted by the SecureMail System as an organization, nor by the individuals who voluntarily participate to provide this service. Those who choose to make use of this service should recognize that although we strive to provide the best service possible, we cannot and will not offer any guarantees, nor do we accept any obligation for providing any service, or the performance of any service to a defined standard. Those who provide this service specifically deny any liability for the content of In-Transit E-Mail. Any liability that may apply must rest upon the originator. It is the stated practice of those who participate to provide this service, that In-Transit E-Mail is not read. On that basis, those who participate in the SecureMail Routing System will not have knowledge of the content of In-Transit E-Mail, will not censor, make judgements as to the legality, morality, nor suitability of any In-Transit E-Mail to be routed, before during or after having any contact with it. Those who participate in the SecureMail Routing System do so for the purpose of providing a service to others using the FidoNet E-Mail System. It is specifically denied that such service is supplied for the purpose of promoting, enhancement, implementation, or aiding the accomplishment of any illegal activity. No one participating in the SecureMail Routing System will knowingly allow its use to aid, abet, or otherwise participate in illegal activities, or make use of the SecureMail System for any illegal purpose. Further it is our stated operational practice that we shall not be engaged in viewing In-Transit E-Mail for the purposes of knowing whether or not the content of such could be considered illegal, and specifically deny that we could have any such knowledge. Those engaged in SecureMail Routing are constrained by the ECPA [Electronic Communication Protection Act] and FidoNet Policy in their ultimate handling of In-Transit E-Mail in regard to disclosure. Anyone who supports the goal of E-Mail privacy and who agrees to abide by the standards herein proclaimed, may apply to act as a SecureMail Host Routing System at their own expense and without regard to In-Transit E-Mail content. A list of current SMH Nodes is contained in the file SECUREML.MAP which accompanies this document. Applications may be made via direct Netmail to the ZSMH, RSMH, or NSMH closest to your area. International applications may be sent to the ISMH as listed in the map. All SMH Nodes are identified by the flags listed above in the FidoNet Nodelist. Any questions regarding the SecureMail Routing System may be directed to any SMH listed Node. A FidoNet Echomail conference for all participating SecureMail Hosts is available as SECUREMAIL from any listed SMH. -30- TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: PGP 2.6 is LEGAL in Zone 1! So USE it! [grin] iQCVAgUBLjx4AcsQPBL4miT5AQFFuAP9HwqZDUU8WoDPmVO139N4kUFLn0cwdP2Y jo17FnMw6XEwF+OQ/95kPBYkXrXxBb+d8aRzMhaw9bTvME55fFh+PcFSyFu6XPDs Bi2Ewi+Z+1+cnZriPvmefjOHb+xGD/NoFFWvZiC4eTwRWVOf4IAKoYw0L9BxJRb+ FhRfDm7ZhOQ= =Dsak -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Aug 94 00:21:46 Subject: SecureMail Host Routing system info -----BEGIN PGP SIGNED MESSAGE----- this is the current topology of the SMH system in FidoNet: SecureMail Host Systems Zone Sysop Address |--ISMH Jim Cannell 1:216/21 | | |--Z6SMH Open | |--Z5SMH Open | |--Z4SMH Open | |=================================================================== | |--Z1SMH Jim Cannell 1:216/21 | | RSMH Net Sysop Address Flag | |--- 10 Radi Shourbaji 1:143/110 X | | | |----- 2:51/2 Harry Bush 2:5100/2 X | | | SMH |-- 102 Dave Lord 1:102/338 | |-- 119 *none at present* | |-- 125 Barry Kapke 1:125/33 X | | |-- 352 John Burrows 1:352/333 X | | | |-- 143 Radi Shourbaji 1:143/110 X | |-- 161 Bill Faust 1:215/228 | | |-- 215 Joe Pye 1:215/25 | | | |-- 202 Guy Martin 1:202/905 X | |-- 203 Lee Dohm 1:203/111 | |-- 205 Zorch Frezberg 1:205/1701 X | |-- 206 Dan Wilson 1:206/2507 X | |-- 207* Dave Sparks 1:207/212 | |-- 210 Steve Garcia 1:210/11 X | |-- 216 Jim Cannell 1:216/21 X | | |--- 11 Jeffrey Oxenreider 1:226/560 | | | |-- 120 Ryan Anderson 1:120/379 | |-- 226 Jeffrey Oxenreider 1:226/560 | |-- 2202 Ryan Anderson 1:120/379 | |-- 2240 Ryan Anderson 1:120/379 | |-- 2410 Ryan Anderson 1:120/379 | | |--- 12 Jesse David Hollington 1:225/1 X | | | SMH |-- 167 Frederic Giroux 1:167/535 | |-- 221 Paul Henry 1:221/279 X | |-- 225 Brett Dubroy 1:225/100 X | |-- 252 *none at present* | | |--- 13 Marc Stuart 1:2624/402 X | SMH | | |-- 107 Glen Pannicke 1:107/398 X | |-- 2613 Jack Mooney 1:2613/108 | |-- 2624 Marc Stuart 1:2624/402 X | | |--- 14 Jason Buchanan 1:286/702 X | | | SMH |-- 285 Mike Riddle 1:285/27 X | |-- 286 Jason Buchanan 1:286/702 X | |-- 287 Danny Walters 1:287/507 X | |-- 291 *none at present* | | |-- 291 John Johnson 1:291/11 | |-- 296 *none at present* | | |--- 15 Dave Munhollon 1:128/86 X | | | SMH |-- 114 Allen Borovkoff 1:114/169 | |-- 128 Dave Munhollon 1:128/86 X | |-- 303 Thomas Lange 1:303/5 | |-- 314 Doug Preston 1:314/5 | | |--- 16 Todd Rourke 1:323/110 | | | SMH |-- 101 *none at present* | |-- 321 Todd Punderson 1:321/309 | |-- 322 *none at present* | |-- 323 Todd Rourke 1:323/110 | | |--- 17 Ted Rolle 1:105/36 | | | SMH |-- 105 *none at present* | |-- 340 *none at present* | |-- 346 *none at present* | | | |--- 18 Christopher Baker 1:374/14 X | | [cbak.rights@opus.global.org] | | | |---- 3:800/857 Jackson Harding 3:800/857 X | | | |------- 285 Mike Riddle 1:285/27 X | | | SMH |-- 116 Jim Pewitt 1:116/46 X | |-- 123 Scott Miller 1:123/416 X | |-- 135 Tom Cropper 1:135/327 | |-- 135* David Bobo 1:135/110 | |-- 365 Chris Britton 1:365/200 X | |-- 366 Rob Buckman 1:366/844 X | |-- 369 Bruce Kniffen 1:369/1701 | |-- 374 GK Pace 1:374/26 X | |-- 375 Tom Jones 1:375/1 X | |-- 378 Sydney Marcus 1:378/10 X | |-- 379 Shad Collins 1:379/51 | |-- 3647 Gale D. Wilkerson 1:3647/1 X | |-- 3649 Chris Hunter 1:3649/17 X | | |--- 19 Mike Lenker 1:106/1776 X | | | SMH |-- 106 Mike Lenker 1:106/1776 X | |-- 124 Bob Ratliff 1:124/7020 | |-- 147 Bill Teasley 1:147/3660 X | |-- 170* Jim Watson 1:170/610 | |-- 382 Chuck Haynes 1:382/502 X | | |=================================================================== | |--Z2SMH Harry Bush 2:51/2 | | RSMH Net Sysop Address Flag | |--- 51 Egons Bush 2:5100/8 | | | SMH |-- 5100 Egons Bush 2:5100/8 | | |=================================================================== | |--Z3SMH Jackson Harding 3:800/857 | | RSMH Net Sysop Address Flag | |--- 51 Jackson Harding 3:800/857 | | | |-- 800 Jackson Harding 3:800/857 Note: Those nodes listed with an asterisk "*" are accepting SecureMail for their Nets, but do not currently route mail from their Nets thru SecureMail channels. SecureMail Hosts are identified by the following flags in the FidoNet Nodelist: ISMH - International SecureMail Host ZSMH - Zone SecureMail Host RSMH - Region Securemail Host NSMH - Net Securemail Host SMH - SecureMail participating Node [these flags may or may not be preceded by a U in the Nodelist.] SecureMail Hosts are requested to ask their Local Coordinator for the appropriate UserFlag for their primary Node number. Those currently flying the ?SMH flag in the nodelist are show with an X by their node number. Complete information on the FidoNet SecureMail Host routing system is available by file-request or first-time download as SECUREML.ZIP from the ISMH or any of the RSMH systems. -30- TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: PGP 2.6 is LEGAL in Zone 1! So USE it! [grin] iQCVAgUBLjx4TcsQPBL4miT5AQGfgwP/U6IIH2OX9xVHrh33mChrRUkBJE35s7GA GOJQm9My/31UinZ21PAr4vXY0xV7YuuNbPJtkJ+QWRB1mqpdSPOwBFHKqcEuouZb BVByWVorNkXutapMTEK6aBMasZIBsL1VWAlRQYPklMFP7MUkBIc7IlAZfrxDSEOK rwVOloMNAM0= =2/39 -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Mike Lippai Area: Public Key Encryption To: All 30 Jul 94 20:10:06 Subject: Public Keys I have a burning question. How does one put out his public key? I mean what do you have to to to make the file or whatevr it is you send out?? I have read the docs a Gazillion times with no clue yet. Lets say I want to send encrypted messages to a freind, how do I get his public key, and how does he get mine?? I know how to add a key to my ring-[pgp -ka ????????.??? Pubring.pgp] I'm not sure this is the right conference for this, but...... ... I may have settled in shipping. 201434369420143436942014343694201434369420143436942014343694718 From: Shawn K. Quinn Area: Public Key Encryption To: Jim Cannell 24 Jul 94 13:56:24 Subject: PGP version controversy *** Quote: Jim Cannell to All on 18 Jul 94 02:44:26 *** Subject: PGP version controversy JC> I have switched to a new version of PGP. It identifies itself as JC> version 2.6, and as far as the external world is concerned, it is 2.6. JC> To avoid compounding the controversy over which version of PGP is JC> best, I am not going to say whether I really am using 2.6 or another JC> version hacked to identify that way. You can use my signature on PGP.EXE (generated on the un-PKLited version) to check it. -----BEGIN PGP MESSAGE----- Version: 2.6 iQCVAgUALjK4090U2ry4hanxAQEawwP+IHiT1SUO4lrF38d6l2Pkh4FhgwGLtjyu lk11AMoE2MxMqf9mbjrgIJ3eJRqmfNoIg/yytRtCrvLwP1leKG7IqERNvEfRQvYt hFlsyKJ5FX5z6Fhb0QeNJp106+fjPIFvic8flULJc/t18uAW5guDUROR1BOeSm/G XEFtv45ax/A= =1qVj -----END PGP MESSAGE----- Save that as PGP.ASC, then run "PGP PGP.ASC PGP.EXE". SKQ 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Christopher Baker 1 Aug 94 14:29:44 Subject: Re: New to PGP Despite the stern warnings of the tribal elders, Christopher Baker said this to Ryan Shaw: CB> FidoNews used to have a PGP public-key when Tom Jennings was CB> editor. [sigh] I think Sylvia uses PGP, but I'm not certain about that. Comments she's made imply that she does, but hasn't gotten around to putting info in the 'snooze. So let's bombard her with letters. :-) 201434369420143436942014343694201434369420143436942014343694718