From: Jim Bell Area: Public Key Encryption To: GK PACE 15 Jan 95 01:01:00 Subject: Re: Can I Freq Pgp? UpdReq -=> Quoting Gk Pace@1:374/26 to John Schofield <=- JS> It's a confusing question. Philip Zimmermann is being investigated by the JS> US JS> Attorney's Office, but he has not been charged with any crime, and it is JS> not JS> known if he will be charged with any crime. If Zimmermann is charged, we JS> should all take a close look at our setups. JS> You need to take all reasonable precautions to ensure that people outside JS> the United States and Canada are not downloading restricted software from JS> your system. However, the crux of the matter is on the definition of JS> reasonable. GP> I agree... my (unconveyed) point was that one should not assume that GP> one would not be harrassed or possibly charged with a criminal offense GP> if they allowed someone from a foriegn country to obtain it from their GP> system. And that one should not spurn the law in this matter. GP> Not being a lawyer, I cannot say with any certainty about GP> circumstances that may or may not have bearing. My definition of GP> reasonable efforts to comply with the law, may not follow those by a US GP> Attorney, and might not prove valuable in a Court. GP> I would assume that the first principal required, would be a stated GP> intent to comply, and to insure that my system is operated to insure GP> compliance. In the event that my efforts failed, I would certainly GP> argue that I had taken reasonable efforts to prevent such. The problem with that position is that "reasonable efforts" might be claimed to be defined as "removing PGP from your BBS so it can't be downloaded by ANYONE." GP>If the GP> prosecution were to produce a document (message) in which I had stated GP> an opinion that the laws were void, did not apply, or that I had an GP> intent to ignore them, my efforts to prove that I had taken reasonable GP> measures would be weak at best. I think you are clouding the already-cloudy issue a bit. Lawyers like to talk about "mens rea", or a "guilty mind." The idea is that in order to be guilty of a crime, you must have a "guilty mind": you must, in general, know you've committed a crime and intended it. If anything, expressing an opinion that you are not violating the law for any number of reasons like the ones you've listed above is, if anything, evidence that you DIDN'T have that "guilty mind." And BTW, law is not always written by legislatures. If you are really on the side of freedom, it is wise to "stretch the envelope" a bit and MAKE something effectly legal that was in question before. Suppose that EVERY BBS in the country, except one, took PGP offline, expressing merely a fear that keeping it on would subject the sysop to government harassment. The last system, keeping PGP online, would almost certainly get such harrassment, and one of the justification's they'll use for it is that "everyone else did the right thing and took PGP off, why not you?" If, on the other hand, every BBS made a concerted effort to post PGP, there is no way the Feds could prosecute them all. (They aren't even prosecuting the ones that do post PGP today!) The first one they tried to prosecute could reasonably argue that the government's interpretation of the law or regulation is wrong, and in any case every other BBS in the country made PGP available. The government's failure to demand that other BBS's take PGP off would be telling, and an individual operator could argue that his position MUST have been "reasonable" since every other BBS operator took the same position. "Strength in numbers," in other words. In effect, a favorable interpretation of the law can actually be forced on the government, by a reasonable concerted effort. But only if enough people with enough guts (and in this case, it doesn't take much) work together. ... The rest of this tagline is encryp*&l#1E0+=|>fcd}85^7@jowxz*7"[=- ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Mike Haglund Area: Public Key Encryption To: Jim Gorges 15 Jan 95 01:50:42 Subject: Quotes as Passphrase UpdReq Jim, There are ONLY three important considerations in picking a passphrase: 1: That it be easly remembered by YOU, and, 2: That it be large enough to render a search of the entire hash space of whatever version of PGP, (or keyspace of any other cryptosystem you might choose), too expensive of time or money to search by brute force. and... 3: If your cryptosystem has a general method of breaking, unknown to you - the worst case - the above is null and void... Even ONE out-of-place letter (or slight, but deliberate misspellnig of a word in a long (say 5 words of average 6 letters) will likely do. "This_Is_A_Tough_Key_Apple_Pie" would not be in any dictionary. The automatic application of brute force methods requires machine recognition of the target plaintext message. For what it's worth, a fairly simple method (and these methods MUST be simple to be FAST), is to take the LOGs of the first few letters of your trial and form their sum. The frequencies of the logs of "nWxenR" will sum to a vanishingly small number, tens of thousands smaller than "Now is". With a "hit", the machine prints the trial line and key; moves on. That is the general principle. One brake on using this is that the algorithm of the cryptosystem must be executed for EACH test trial; even on machines of advanced design, this is prehaps the worst stumbling block to cryptoanalizing of even a broken system where another method of entry is known. A simple key, predictable of use, is called a "crib". Change your key often... once a month..., ok, "Jan crib", "Feb crib"? Nope. Don't fall for trying somthing as simple minded as that, troops! Give some creative thought to your passphrase. And treat it as some indians treat their secret names obtained during the Vision Quest: An enemy could "eat your soul" if he learned your new "real name". Lord, if anyone EVER found out that my backyard vision quest gave me the name of Alphonse! However, brute force is NOT the method of choice of breaking a system, and is rarely used. Visit your library - good university libraries will have technical titles like "Cryptography: A New Dimension in Computer Security" (Meyer & Matyas) Wiley-Interscience, 755p, 1982. Or for history of the subject, David Kahn's dated but exhaustive "The Codebreakers" - a VERY good read. Mike (Alphonse) Haglund 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: Michael Mcbroom 14 Jan 95 10:37:58 Subject: Electronic Privacy BBS Li UpdReq -----BEGIN PGP SIGNED MESSAGE----- --== Hi John, sounds interesting. Howaboud I just netmail the application MM> to you? Sounds good. {grin} JS>Short Description JS> (75-word limit) : The 2nd Amendment BBS is dedicated to the Right MM> of the People to Keep and Bear Arms. We have over 150 international MM> echomail conferences on line, covering a wide range of subjects, and MM> are still growing. Doors and files are also available. Liberal access MM> privileges after validation. Since this is an electronic privacy BBS list, you may want to say a little bit more about what you offer the caller interested in electronic privacy. In any case, you have been added to the list. The next list should be released in February. Thanks very much for your help! John -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLxgYQmj9fvT+ukJdAQFbngP8DyoTOthp07F2fVS6W1FY21F6bKuIgDJ1 iYu+RHK7mXi8Kclmp6050PxU5Fnz3EkzIeOm+v9TEZ5aXSL4wxZhpoQONr4R1g/F DCasjjnPFzs5QYpCNW0Ut1T4bwsor8KiuVUl2TaYFGVn2UdQrN5t2osuEWmSi/Mc a5v+Ovz0Tek= =wCTf -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... I tried an internal modem, but it hurt when I walked. 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: All 14 Jan 95 11:23:18 Subject: Electronic Privacy BBS List UpdReq -----BEGIN PGP SIGNED MESSAGE----- --== Since this is an electronic privacy BBS list, you may want to say a JS> little bit more about what you offer the caller interested in JS> electronic privacy. In any case, you have been added to the list. The JS> next list should be released in February. Thanks very much for your JS> help! My apologies to all. This was supposed to be sent in private e-mail. Ooops! John -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLxgkfmj9fvT+ukJdAQFPegQArtxX9ndo5RorFyaFKSH0isYaT3sEK4TX dbT+d8NgEVFQCFqlmrtxqm7e0jVEUC6yDJgLWzR4DSbh+4EX7CfddbeFQQvGuUnF 8fwHd5pVZ635c0hvQTzbXwb8RDkMYSaFF4+KWakjjS+OYvcGORNOjzd4QAwXruNW SoTy/NhRtY8= =/bYs -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... He who gives up freedom for security deserves neither. 201434369420143436942014343694201434369420143436942014343694718 From: Alan Pugh Area: Public Key Encryption To: Glen Todd 14 Jan 95 22:49:12 Subject: KEY REVOKE UpdReq SM> So, if you're gonna do this, at least throw in some alphanumeric stuff. SM> And watch those lengths; 8 characters of Tibetan is still just 8 SM> characters. GT> Unfortunately, that length is limited by a lot of programs. As I GT> said, for stuff I want to be semi-secure, I use pseudo-random Radix-64 GT> sequences generated by a utility I wrote (that uses system time as it's GT> seed.) I'm also looking into ways to use PGP to secure/validate GT> packets. GT> Wind to thy wings, GT> Glen speaking of password utilities, do you (or anyone else here ftm), know where to get a program that generates pronouncable passwords? mcimail does not let you choose your own password. what they do is generate three 8 char password that is pretty much pronouncable like yakakutu horalita jantespi then make you choose from one of these three. i've written a password program in vrexx and would like to find an os2 or dos program what will generate these kinds of words. so i could incorporate this kind of functionality into it. later, amp <0003701548@mcimail.com> January 14, 1994 10:2 ... One cannot assemble a militia from an unarmed populace. 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Jan 95 00:12:48 Subject: PUBLIC_KEYS Echo Guidelines - regular repostUpdReq -----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 ASCII-armored or personal key encrypted messages that can be read by anyone with PGP 2.6+ and your public-key. Include your public-key in a separate message before sending such test messages in case the other end doesn't have it or make them aware of how to get it from your system. If you just want to post your public-key, use PKEY_DROP Echo. 5. Clear-signed messages are not encrypted and may be used freely in this Echo. 6. This Echo may be traveling around the world so try to be concise. Avoid excessive quoting for one-liner responses. 7. Be aware that Echomail is NOT secure. Don't take anything at face value. 8. The posts in this Echo are the sole responsiblity of the poster. If you need verification, use Netmail. 9. 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 Jens Mueller at 2:24/24 who sends it on to Harry Bush at 2:51/2. Consult Jens or Harry for Zone 2 feeds. The Echo is gated 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. Archives are no longer kept. 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. BACKUP! BACKUP! BACKUP! [clear?] [grin] Thanks. TTFN. Christopher Baker & GK Pace Moderators -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLxiu1csQPBL4miT5AQHX0QP/cGCkV2O7W7lVgGzvlu2w46gwwJ662Wtd vTDE21BnoojCk9InhsvKSn94YxUYfqgzSo8fiJExeYMg1UWF4syWgyuyCYfr9JBf ezbj+QX8lsdtCUE7xzlaptyIrf8emIJuJLhymz+SsqN1BGfyJzlu5qJPnKfSzItn k8QbXy+tM5o= =79e5 -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Jan 95 00:13:50 Subject: PGP-related filename conventions in FidoNetUpdReq -----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.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLxivEcsQPBL4miT5AQFS7wP/QWvkuBM54Mod6BOm4EtlP3fr8+K8nzpr TkZtu24sztBfRxnHZ3W/Hc0QOp6EjbdfJtguHkMmpBD5j8nukNcIAXhCshriOoN2 ogDfB8mRNpUaHzFiI+ELw6fx8ow9JXTRutB8CaCgNZCa0oUhY0qNRM3ihx3us5H6 8zC3u4BrYbU= =L/AQ -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Jan 95 00:15:12 Subject: SecureMail Host Routing system info UpdReq -----BEGIN PGP SIGNED MESSAGE----- The FidoNet (r) SecureMail System 30 Mar 94 Copyright (C) 1994, 1995 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. Most 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- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLxivZMsQPBL4miT5AQEk3gP/fZ6GdIwMK8Cme4/7J0GSLpnOU7g+jAiq UP90ozqZWp57q/ux9dvWHnaxClks0PJb7y69KhQx0+gSQ5uS4n2VlNUF5o6yDgeQ QfG+Wbf8+8M2tBdo05wjSPt7xiR4nWXtUhza5x31n6evvnpZcJvI4+r5u90pDiBC VIWwZpTi5+4= =7FJs -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Bill Katcher-Jr. Area: Public Key Encryption To: All 16 Jan 95 00:04:00 Subject: Verifying PGP Keys UpdReq Hello All! I'm still a newbie to PGP, I've used it to verify the authenticity of new versions of TBAV, and have played with it a little bit as far as encrypting and decrypting stuff, and a few other things. My main concern is what is the best way of verifying someone's public PGP key. If it's posted on FidoNet, it could possibly be a phony key, and even if it's signed by other people, what good is it if you don't have those other people's keys to verify it? And another thing, when you PGP asks you if you want to certify (or verify, whatever it asks when you add a new key) the key you're adding, what are you supposed to do? I normally say No and don't verify it, because I'm not 101% sure that it's the key of the person who posted it. I know I could freq everyones key (since I'm a point) and be semi-assured it's that person's key, but there has to be a a better more effective way of verifying someone's key. Any help, information, assistance, etc in this matter would be very greatly appreciated. Thanks in advance, Bill 201434369420143436942014343694201434369420143436942014343694718 From: Lawrence Garvin Area: Public Key Encryption To: Jim Bell 14 Jan 95 16:45:52 Subject: Can I Freq Pgp? UpdReq Jim Bell said in a message to JOHN GOERZEN: JB> See the problem? The people who try to argue that putting JB> PGP on a BBS, which then is called from outside the country, JB> results in a violation of the laws chargeable to the BBS JB> operator, are arguing a very selective and opportunistic JB> interpretation of the law. SCO (makers of fine Xenix and Unix products) have restricted the distribution of the Unix 'crypt' command since the product's inception. Along with the documentation comes a statement which reads as follows: "The crypt(C) command is not distributed with the XENIX (UNIX) System V Operating System. If you want the crypt(C) utility and associated crypt(S) libraries, and you live in the United States, contact the support center listed on the support information card included with the software." Now.. why do you suppose they handled the situation like that? My presumption is that it's the -only- way that SCO (as the original, and primary, distributor) can insure that the controlled applications are only distributed to -authorized- end users. And since the end user cannot 'transfer' their XENIX (UNIX) software license to another person without SCO's knowledge, the subsequent 'distribution' of the crypt(C) command or crypt(S) libararies is a violation of the SCO license, and itself subject to court action. Likewise, unless a BBS operator can guarantee that they are controlling the distribution of materials classified by the government as munitions (regardless of whether we or anybody agrees with the classification), they are subjecting themselves to the risk of being a party to the distribution. My suggestion to sysops desiring to make PGP available to users, is to place the software in a restricted filearea, and post a bulletin or announcement to all users that indicates that PGP is available by special arrangement, and then give access to that caller when you have verified with due diligence that they do reside inside the United States (or Canada, in this case). The other alternative is to develop a foolproof way of automating the domestic identity of every caller, thus insuring you are not accepting any international calls. I'm not aware of anyway to reliably do this at this time, though. Lawrence.Garvin@f6018.n106.z1.fidonet.org 201434369420143436942014343694201434369420143436942014343694718 From: Lawrence Garvin Area: Public Key Encryption To: Brian Giroux 14 Jan 95 16:57:12 Subject: PGP LEGAL OUTSIDE US? UpdReq Brian Giroux said in a message to All: BG> My question is this; what is Zone 1? Zone 1 is the North American continent. Basically Canada and the United States, as I'm not aware of any Fido nodes in Mexico. BG> There is a small thread in a local echo about the legality of BG> PGP, some people are under the impression that it isn't BG> allowed to leave the US, I'm under the impression that it BG> is legal all over Canada and the US Could someone clear BG> this up? Software encryption applications are restricted from export to foreign countries, however an exception to this rule permits the export to Canada. Lawrence.Garvin@f6018.n106.z1.fidonet.org 201434369420143436942014343694201434369420143436942014343694718 From: Michel Bertler Area: Public Key Encryption To: Brian Giroux 13 Jan 95 12:43:00 Subject: What is Zone 1? UpdReq -----BEGIN PGP SIGNED MESSAGE----- Hello Brian! In a message dated: 03 Jan 95, Brian Giroux was quoted as saying: BG> I've seen someone around here use the "Comment" line "PGP 2.6 is BG> legal in Zone 1 so use it ", or something to that effect. BG> My question is this; what is Zone 1? Legitimate question from a Fidoland outsider, Zone 1 is described as being North America (USA & Canada). In Fidonet, the globe is divided in 6 "Zones" as: Zone 1, North America Zone 2, Europe Zone 3, Australia Zone 4, Latin America Zone 5, Africa Zone 6, Asia Each one of the above are subdivided into "regions, net, hosts, hubs and nodes." A node is the smallest part of the network (commonly a bbs) and is fully & specifically identified from the whole network structure by an address such as 1:242/9930 for example. The first digit "1" before colon is Zone descriptive, second, third and fourth digits before slash "/" are "net" descriptive and finally last 3 or 4 digits are "node" descriptive. The whole thing builds up a so called "nodelist" which is nowadays, a file over 3 megs in size. Michel - --- GoldED 2.42.G0615+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLxa8DSS7hDvuVNVxAQHPnAP+NEIqn49suE/TvTvu77z2Zc/vHO1oOBls ZMDGq/BGn5gy5JgEw/5oC/HTTyjpfrlT1jVekQa2qRhW0cg0sHYzFzOUWQzvtUGZ unWymsTY1Mv5k6uCmeY/rIwHwQR5WZ6WB57vExMIljMKQGCqI8tN4VzUjfB7Ed9h HmpB3wHdqFk= =OKSo -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Ed Gills Area: Public Key Encryption To: All 11 Jan 95 14:09:00 Subject: Bbs Chat Encryption UpdReq I need your help, I'm looking for an encryption program that I can use during chat on a BBS I'm on... It seems like the sysop loves to emulate and see what's going on. I need someway to encrypt and decrypt chat message while still being able to send and receive non-encrypted messages to others in the chat room. It should be fairly automatic and easy to use,(only 4 people will be using this) and should have some sort of pass phrase I can set before starting, just in case the sysop gets a copy of the program. It doesn't need to be as secure as PGP, but just good enough to discourage the sysop from being a nosey jerk. thanks, Ed |------------|-----------------------------|----------------------| | Ed | Internet: EGILLS@DELPHI.COM | PGP Key available on | | Gills | FidoNet : 1:207/225 | E-Mail Request | | | Rime Network : ->326 | Or through various | | Fontana |-----------------------------| KeyServers on | | California | PGP FingerPrint: | Internet and FidoNet | | USA | 1F 20 DA CB 29 71 01 9E | | | | F9 18 C8 D3 79 23 42 28 | Key I.D. : 1EE9A251 | |-----------------------------------------------------------------| * SLMR 2.1a * I'm sorry, were the voices in my head bothering you? 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: Alan Pugh 16 Jan 95 17:57:34 Subject: word generators [Was: KEY REVOKE] UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 14 Jan 95, Alan Pugh was quoted as saying: AP> speaking of password utilities, do you (or anyone else here ftm), AP> know where to get a program that generates pronouncable passwords? i have an old program here that is used to make up alien names for science fiction writers. you choose the vowel/consonant arrangement and length as well as number of names. it's called ALIEN.COM and is freqable as: ALIENAME.ZIP if you'd like to try it out for that purpose. [grin] TTFN. Chris p.s. do you have that PGP freq list available in file form? i meant to write it out to a file but it scrolled off before i could do so. thanks. C. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLxr54ssQPBL4miT5AQEOpwP9H87U7UQvDy2fomm6rN1+oJjH5Qm3l1Bd 0j/joXxRQVmfP1fgkXWEqYa6KOeuD8gNp5vKteUzt7dET2P1Fi+jvV0LBrY2EV/8 aee+gVzr97xunh7Wj5FETSv2j9uMWHEiYoVH7M2j5BgIlmZeEbje6exmxCyt0cQp Bej7J1dcDrQ= =zJSv -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: Bill Katcher-jr. 16 Jan 95 18:01:24 Subject: Re: Verifying PGP Keys UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 16 Jan 95, Bill Katcher-jr. was quoted as saying: BK> what is the best way of verifying someone's public PGP key. the best way is to get it from them in person. barring that, getting it from their system by direct file-request of PGPKEY should be a good substitute. you can then verify the fingerprint with them if you still have worries. see the docs about the 'Web of trust'. BK> you PGP asks you if you want to certify (or verify, whatever it asks BK> when you add a new key) the key you're adding, what are you supposed BK> to do? you should NEVER certify a key you have not personally obtained directly from the source. BK> but there has to be a a better more effective way of verifying BK> someone's key. see above. BK> Any help, information, assistance, etc in this matter would be BK> very greatly appreciated. you're welcome in retrospect. [grin] TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLxr6xssQPBL4miT5AQEO1gP/cZ2lnoNgZttAbGEDD/AXTJPF5cWi+yyp JmPBJvVIIN/aXXKY0I4BK1lURxi0MlPdlnjkOybFp9GOwy+lHb+1ETqbE5AdWT1g 6OMQvKsKssyGnqRnL+tvIG5MWauzjkDjicriVw1bqXAYzyvvY/5rAYqtIxoRyDCV f+EG6QjKhcM= =tI8O -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: raph@netcom.netcom.com Area: Public Key Encryption To: All 16 Jan 95 18:43:06 Subject: Draft of editorial to SF Chronicle UpdReq * Original Message Posted via CYPHERPUNKS * Date: 13 Jan 95 22:23:07 * From: raph@netcom.netcom.com @ 1:102/825.111 * To: All * Forwarded by: Christopher Baker @ 1:374/14 * Message text was not edited! @MSGID: 1:102/825.111 00039c30 @REPLYTO 1:102/825 UUCP @REPLYADDR raph@netcom.netcom.com @PID GIGO+ sn 154 at borderlin vsn 0.99 pl3 @Sender: quake!toad.com!owner-cypherpunks @Received: from relay2.UU.NET by netcomsv.netcom.com with ESMTP (8.6.9/SMI-4.1) @ id XAA18546; Fri, 13 Jan 1995 23:16:17 -0800 @Received: from toad.com by relay2.UU.NET with SMTP @ id QQxypo09890; Sat, 14 Jan 1995 02:09:40 -0500 @Received: by toad.com id AA26291; Fri, 13 Jan 95 23:00:33 PST @Received: from netcom4.netcom.com by toad.com id AA26281; Fri, 13 Jan 95 23: 00:08 PST @Received: by netcom4.netcom.com (8.6.9/Netcom) @ id WAA14448; Fri, 13 Jan 1995 22:23:07 -0800 Date: Fri, 13 Jan 1995 22:23:07 -0800 From: raph@netcom.netcom.com (Raph Levien) Message-Id: <199501140623.WAA14448@netcom4.netcom.com> @To: cypherpunks@toad.com, downey@cs.netcom.com @Subject: Draft of editorial to SF Chronicle @Sender: owner-cypherpunks@toad.com @Precedence: bulk Chaos and Anonymity keep the Internet Vital I could not let Martha Siegel's editorial ("Anarchy, Chaos on the Internet Must End", 2 Jan 1995) go unchallenged. To the uninformed reader, her arguments may seem plausible. However, her distortions give a picture of the Internet quite at odds with the true nature of the Net. Her views are by no means representative of those who actually use the Net. Of the dozens of messages I saw in response to the editorial, not a single one was in favor of her proposals. As Ms. Siegel correctly points out, the Net is not governed by any one individual person or organization. Rather, it is collectively run by those who use it as part of their daily lives. The operation of each Internet node is subject to the individual judgement of the people who own it. Ms. Siegel is wrong, however, in believeing that such a state of affairs is intolerable. Rather, this state of affairs has brough us a remarkable flowering of discourse, ideas and culture, which is just now beginning to be recognized in the mainstream press. In a lawyer's dream world, there is a rule covering every action in every situation, along with a well-functioning system to enforce the rules. This is the exact opposite of the spirit of the Net, and of Usenet in particular. Rather, there has evolved an informal set of guidelines for promoting open, civil discourse, collectively known as "netiquette." These guidelines may seem arcane to newcomers, but basically they simply ask people who use the Net to be considerate of other people, their time and their resources. A violation of netiquette brings on not legal action, but responses pointing out why the action was inconsiderate. Continued violation brings on ridicule and scorn -- people who engage in this are considered to be either sociopathic or just obnoxiously self-promoting. The single most infamous breach of netiquette in Usenet history was almost certainly the "green card spam," in which thousands of advertisements for green card services were posted to completely unrelated message areas, or "newsgroups." Advertisements presented in a way considerate to others are tolerated and even welcomed on the Net. Posting thousands of copies, though, is just going too far. Negative response was immediate. The perpetrators were asked to stop, but they refused to. One Norwegian hacker took it upon himself to track down and "cancel" the offending messages. Most people on the Net considered this to be entirely appropriate. A number of other self-promoting hucksters have sensed an opportunity, and have performed similar spams. In response, the Net evolved a defense mechanism to counter these spams and minimize the damage. The person currently serving this role is known by the pseudonym "CancelMoose." Almost everyone on the Net supports this effort, and agrees that it improves the overall value of Usenet. Who was responsible for the original green card spam? Why, Ms. Siegel herself, the same one who is complaining about "chaos and anarchy." Chaos, anarchy, and anonymity are a large part of what keeps the Net so vital. Particularly galling is Ms. Siegel's appeal to free speech. Usenet in its present form is perhaps the most conducive forum for free speech in history. The threat to free speech is not from chaos or anonymity, but from the sorts of changes that Ms. Siegel proposes. Usenet is astonishingly effective in getting around the practical barriers to free speech. These barriers come in many forms, including libel, trademark, and copyright laws, fear of retribution, etc. Because of its decentralized, communal nature, Usenet resists direct attempts to censor. The main tool for circumventing more these more indirect barriers is anonymity. As an example of such barriers, take the t-shirt commemorating the green card incident. It was emblazoned with the words, "Green Card Lawyers - Spamming the Globe" and a fist clutching a green card. Shortly after the shirt was proposed, Canter & Siegel threatened to sue if the shirt was in fact produced. It was only after several outraged lawyers promised to defend against such a case pro bono that I and others could be proud owners. Or take one of the sexual abuse recovery newsgroups, where anonymity is the norm. If someone were to post a message asking for support, saying "my uncle did it" under their real name, they would be vulnerable to a libel suit from said uncle. On the other hand, if they used an anonymous service such as the one in Finland, they would not simply escape punishment for the libel, but prevent it from happening at all. In many countries (and even China is on the Net these days), writings critical of the government, such as exposure of human rights abuses, are illegal. The authors face imprisonment, torture and death. By posting anonymously to the Net, the information can be brought safely to the attention of the world. Not all anonymous messages are pleasant or popular. Unpopular speech is a necessary consequence of free speech. At least to the founders of this country, the benefits of free speech outweigh the discomfort. Our founding fathers were also comfortable with anonymity -- the Federalist papers were originally published under the pseudonym Publius, because the authors felt the ideas should be evaluated on their own. Judging from the materials already published by Ms. Siegel, an Internet built according to her vision would free of such disturbing ideas, but would readily support five hundred channels of green card ads, impassioned pleas to purchase American flag plaques, and, yes, anonymous testimonials for radial keratotomy specialists. 201434369420143436942014343694201434369420143436942014343694718 From: Glen Todd Area: Public Key Encryption To: Alan Pugh 16 Jan 95 21:33:00 Subject: KEY REVOKE UpdReq *** Answering a msg posted in area PERSONAL_MAIL (Glen's personal mail). Bright the day, Alan! Saturday January 14 1995 22:49, Alan Pugh wrote to Glen Todd: AP> * Forwarded from area 'PUBLIC_KEYS' GT>> Unfortunately, that length is limited by a lot of programs. As I GT>> said, for stuff I want to be semi-secure, I use pseudo-random GT>> Radix-64 sequences generated by a utility I wrote (that uses system AP> speaking of password utilities, do you (or anyone else here ftm), AP> know where to get a program that generates pronouncable passwords? 'Fraid not. The stuff my utility generates is anything but pronouncable. (You try to pronounce 4W0O+V42.) AP> mcimail does not let you choose your own password. what they do is AP> generate three 8 char password that is pretty much pronouncable like AP> yakakutu AP> horalita AP> jantespi AP> then make you choose from one of these three. i've written a password AP> program in vrexx and would like to find an os2 or dos program what I could probably get one of the MCI Mail types in our building to tell me the algorithm, if I tried real hard. Any particular reason why it needs to be pronouuncable? Wind to thy wings, Glen My other ferret is a Wolverine 201434369420143436942014343694201434369420143436942014343694718 From: mark lewis Area: Public Key Encryption To: jason carr 15 Jan 95 23:20:36 Subject: KEY REVOKE UpdReq jc> Just delete the revocation from your ring and add in this jc> file. All will be well, Grasshopper. ml> oh?? what about his secret key?? jc> Well, it's the same thing he would have re-added after a jc> proper revocation, right? the secret key is the local only key that no one else is ever supposed to get hold of... jc> I still think it will work. If it does, anyone with a copy jc> of your key should be able to extract it back out to you. jc> All is not lost... that's only the public key... it's no good without the secret key... they are a matched pair... )\/(ark # Origin: (1:3634/12) * Origin: PODNet <-> FidoNet EchoGate! (93:9600/0.0) SEEN-BY: 107/946 147/1077 259/212 382/7 640/217 3611/19 9600/0 9608/0 9609/0 201434369420143436942014343694201434369420143436942014343694718 From: Armando Ortiz Area: Public Key Encryption To: gk pace 15 Jan 95 14:22:34 Subject: Re: Can I Freq Pgp? UpdReq -> -> How about Phillip being the target of a US Grand Jury for alledgedly ->placing PGP upon a medium which "allowed" it to be obtained by someone ->outside of the US? That's like one who sells a gun to a felon who claims never to have been arrested at all... The case against him won't hold water...I think the government is just afraid that encryption standards won't be broken and that people will use them to protect their private interests. I could see if spies actually used it to transfer information back and forth and then banning it, but not now...why would a foreign spy use something that is almost COMPLETELY nullified by better encryption on their side? >>> --- POW 1.2 0052 And on the 8th day, God replaced OS/2 with CHICAGO! VQWK 6.20 [Rev H - 04/04/94] 201434369420143436942014343694201434369420143436942014343694718