From: David Chessler Area: Public Key Encryption To: Jeffrey Bloss 17 May 95 20:45:00 Subject: Re: encrypted messages UpdReq On 05-12-95 (01:04), Jeffrey Bloss, in a message to David Chessler about "RE: ENCRYPTED MESSAGES", stated the following: JB>Correct me if I'm wrong David, but you haven't READ any of the specific >documents/sections I've referenced... have you? Your lack of possession >or motivation to lay hands on a resource is hardly an indication of it's >adequacy. :( Anything that is so out of step with the information that I do have suggests that it is using unreliable definitions. This is not worth my while tracking down. It is very easy to find obsolete laws or laws that apply in very limited circumstances, or that apply only to certain types of communications, and then say "statutes exist." Perhaps, but they are irrelevant. >thousands of hours pouring over long since shredded and dissolved >paperwork telling me specifically what could and could not be installed >where, and who could use it or not. That's called first hand experience >working within the very same environment I'm speaking about, in more >places than I can remember. In my last 18 months active duty alone I >worked in 27 different countries. The US military has its own rules. Whether it is governed by rules or statutes of the foreign country concerned, US Law, or something else, depends on the Status of Forces Agreements, which have little or nothing to do with normal law which applies to 1. natives of the countries concerned 2. civilian foreigners in the countries concerned (who are usually much more restricted than natives. JB>This the very same sort of "situation specific" reference you're trying >to say *I'M* using!!! ITU/CCITT defines a microscopic >subsection of the world wide communications picture. It used to be the whole thing. And this is what I think your sources are picking up. JB>DC>> It denies your claim. There was no regulation of encryption UNTIL >a recen JB>Smoke and mirrors... you conveniently deleted the part about "tightening >restrictions", and I've never claimed the Soviet Union as evidence to >anything else. Lame David... very lame. Tightening? Imposing where none had been. And that's in the soviet union: they didn't have operative and applicable law, in a country that had previously licensed typewriters. JB>DC>> If you have so little sense of humor don't bother us. We were >happy enoug JB>Us and we David? I seriously doubt you have the authority to speak for >anyone but yourself, and how my tagline affects *your* happiness isn't >exactly "topical" or "important" either. It *is* humorous though... I can probably speak for the others who have found my comments on it interesting and amusing. > * Origin: Meadville Online (1:2601/551.0) -- ___ __ david.chessler@neteast.com d_)--/d chessler@capaccess.org chessler@trinitydc.edu * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: Jeffrey Bloss 17 May 95 22:26:00 Subject: Re: encrypted messages UpdReq On 05-12-95 (00:14), Jeffrey Bloss, in a message to David Chessler about "RE: ENCRYPTED MESSAGES", stated the following: JB>Again... ITAR has been rewritten, superseded, it's obsolete. PLEASE >bring yourself up to speed on the subject at hand before you suffer any >more self-inflicted gunshot wounds to your feet. In the previous packet I received information on a lawsuit being filed last week against ITAR regulations by a publisher. Maybe it's obsolete, but State is still enforcing it, and it *is* state and not NSA that was named as defendant. check current issues of Computer Underground Digest and EFFector Online for current information on lawsuits being filed in the last few weeks--the full text of the complaint is available, I think on the EFF ftp site (the exact location is in EFFector Online. > * Origin: Meadville Online (1:2601/551.0) -- ___ __ david.chessler@neteast.com d_)--/d chessler@capaccess.org chessler@trinitydc.edu * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: Glen Todd 17 May 95 22:28:00 Subject: Encrypted messages UpdReq On 05-12-95 (15:47), Glen Todd, in a message to David Chessler about "ENCRYPTED MESSAGES", stated the following: GT>DC> ITAR refers to the STATE department and is administered by them. >Grady >DC> Ward posted the regulations, and his correspondence with them. NSA >is >DC> so secret that it can't have any direct enforcement. GT>Yeah -- one of the worst-kept secrets in history.{g} Still, the current lawsuit, filed within the last couple of weeks, names State as the defendant, and ITAR as the regulation. An agency cannot, under the administrative procedures act, enforce any rule or law, unless it has a public interface (appeals process, administrative law judges, the whole schmere). >(1:128/203.1) -- ___ __ david.chessler@neteast.com d_)--/d chessler@capaccess.org chessler@trinitydc.edu * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: John Stephenson 17 May 95 18:33:20 Subject: Re: "Watch the Skies!" UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 14 May 95, John Stephenson stated: qu> Watch the skies! JS> Shouldn't this be in a humor echo? we need a little levity now and then. [grin] TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: SUPPORT the Phil Zimmerman Legal Defense Fund! iQCVAwUBL7p5pMsQPBL4miT5AQGoPQP/XpSImGFXHb7w1ShE9GN+MHEA+HRvYODq 2H2J9Lb/ih7GWXLrhz1vfR70qYJVYZ6KpYdG/i/9/x1SfQCFPfAho0oenIr3uJul uLefRYVcGgi3F26+Jw6rvox4hc0Dl0K0X7g7uoCw02nThaX0JzOIVvvJUhPNtzmv 6JdO79yPRB0= =VWQ+ -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Glen Todd Area: Public Key Encryption To: jason carr 18 May 95 09:36:40 Subject: Pgp Stuff Available UpdReq Bright the day, jason! Tuesday May 16 1995 13:27, jason carr wrote to Ted Rolle: LP>> files in the directory containing my PGP program files are LP>> available only to Zone 1 callers. TR>> How do you enforce this? jc> You could compile your nodelist index using only Zone 1, then set your jc> mailer to only allow FREQs from nodelisted systems. Kind of hard when you're running a multi-net international hub. Wind to thy wings, Glen ... The very rats instinctively have quit it. 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 17 May 95 18:35:42 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: SUPPORT the Phil Zimmerman Legal Defense Fund! iQCVAwUBL7p6MssQPBL4miT5AQEu/QP/f9xuPbQ089uEh5Atzg+CH+xesKP7u3DT rQzTCH9q1zMMavmk0w1M5/4hG8Po9q3dT1E+wFop+R96+rmCTkcNCIGmZuxUsqAC B3YzgjP7Qvb5e2nBnAq3nXNptA1qE7jjLsthZdRXsCmKfQvaaSVuH/H6HrOabgph +vmNLqRLdGM= =tpJI -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: John Stephenson Area: Public Key Encryption To: L P 16 May 95 19:46:36 Subject: Pgpwave Source Cod(1) UpdReq JS> You seem to have quite an attitude on you. PGPWave JS> is a great program LP> I have had most of the same problems that Mr. Junker LP> complained of, but I still think that it is a great program LP> just doing what it does do, which is encrypt and sign mail LP> very conveniently. I use it regularly. Thank you very much. Well it's great to hear you've worked around the bugs :) LP> It does eat the input message here too: 1) configure LP> PGPWAVE according to the docs -- I have PGPWAVE in the LP> same directory as BlueWave 2.12 at c:\bwave, my LP> work directory is ramdrive d:\bwavwork, PGP LP> is running from d:\temp, and it has 605k in which LP> to run; 2) load a mail LP> packet with something to be decrypted in a message; LP> 3) invoke PGPWAVE with the R)eply command; 4) tell LP> PGPWAVE to D)ecrypt the message; 5) Unlike when simply LP> invoking the message editor with the M command, the LP> temporary reply file in the d:\bwavwork\reply LP> directory either does not come into existence, or ...?; Okay. I've found the error. It's not in PGP as I previously assumed. It's my fault (g), it's an error when it strips the quotes, it attempts to rename the original file across the drives. Of course you can't rename a file from a ramdrive to the hard drive, so it doesn't work at all. Right now I'm using PGPWave v1.10a where I use the copy function I wrote to do the copying. I've removed the bug fix I previoulsy posted from my batch file, and it worked fine when I wrote a message, encrypted it, exited, read it, then decrypted it. LP> 6) PGPWAVE complains that it has nothing to work on. Yes, because it erases the temporary file, so then -both- files are gone! LP> This has happened here too, using BlueWave 2.12 -- see LP> the above setup. It didn't lock up. It simply said "Message not found". JS> Odd. That isn't something I've seen happen. JS> Tell me how to duplicate that error as well. LP> This happens to me too, in a fashion. When I invoke LP> the configuration command from the PGPWAVE menu and LP> make changes, it doesn't eat the config file upon LP> saving it, but it deletes the line telling PGPWAVE LP> which editor to use (and possibly another line too): LP> 1) invoke configuration/set up from the PGPWAVE menu; LP> 2) save the changes by any means available on the LP> menu; 3) the config file gets screwed up. Interesting, I can't duplicate the error. LP> What drive/directory setups were successfully LP> used so that all of the PGPWAVE functions worked LP> properly? PGPWave: C:\PGP\PGPWAVE BWave: C:\BWAVE PGP: C:\PGP Work dir: C:\BWAVE\WORK\REPLY Seems to work ok. I did find when you use a RamDrive it will not work correctly. This error has been fixed in PGPWave v1.10a (but I still have quite a ways to go before it is finished) - John ... Oxymoron: Environmentalist bumper sticker. 201434369420143436942014343694201434369420143436942014343694718 From: Alan Pugh Area: Public Key Encryption To: John Stephenson 14 May 95 20:27:00 Subject: PGPWave source code gone UpdReq -=> John Stephenson was saying something about PGPWave source code gone JC> "You should" unplug your modem until you learn some gratitude for JC> freeware authors. JS> JS> Yes! Finally someone sympathizes with what it's like to be a freeware JS> software author and respond to people who send you their bug list with JS> an attitude. john, from what i've heard about pgpwave, it is an excellent product. i haven't had time to hunt it down and play with it but intend to get to that soon. even though i haven't used it, i =thank= you for making it publicly available as freeware. it's folx like you what made the pc an enjoyable platform to work with. you mentioned you'll be including batch file support of some kind. have you considered _rexx_ support? i've got ibmdos 7.0 which has rexx support for batch files and it _really_ makes batch files powerful. if you get a chance, check it out. i'm looking forward to playing with your current effort and look forward to your next release! amp <0003701548@mcimail.com> May 14, 1995 21:26 ... "Who is John Galt?" 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 17 May 95 18:34:54 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: SUPPORT the Phil Zimmerman Legal Defense Fund! iQCVAwUBL7p6AssQPBL4miT5AQFC5QP+NlpHUSG7IWREPwy0mPMiydfn4dVB/czj 5heFUlxcr0/pr3j44SHn80XDTLQJFF8jIBXwsVho0D0PVSEYekofAWVz4uEYrXEU 0ojIJJXjq9w4rYPsRuMpGmHzjKZQdnnQMae+PfTIdDkEl2AxAs3V/uc5QB9YwBoH X7CwHXArRXU= =naYM -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: John Stephenson Area: Public Key Encryption To: John Schofield 16 May 95 19:46:34 Subject: RSA UpdReq JS> I'm sorry to give you a standard answer, but the best I can tell you JS> is to buy and study _Applied Cryptography_ by Schneier. It has C JS> source, and all the explanations you should need. I have to give you JS> the reference, because I have no clue how to answer your question. I dislike people who say RTFM, even if it is done politely and is actually good idea. :) JS> Btw I live in Canada, so it's legal :) JS> Although electronic transmission is a little iffy, talking about the JS> principles involved should be fine. It's only when you start JS> distributing source code (or executables) that you run into problems. True. - John ... Oxymoron: Terribly Nice. 201434369420143436942014343694201434369420143436942014343694718 From: John Stephenson Area: Public Key Encryption To: Shawn McMahon 16 May 95 19:46:34 Subject: RSA UpdReq JS> But.. how do I find out D & E with knowing P & Q? I'd eventually JS> like to implement a Pascal program using the formula.. but I JS> can't get past that "little" road block. SM> E is randomly generated, such that E and (P-1)x(Q-1) are relatively SM> prime. Okay, so say x = (p-1)*(q-1).. So that means that I just pull a number from the hat that: gcd(x,e) = 1? SM> D equals E^-1(mod(P-1)x(Q-1)) Ok.. so d = e^-1 mod x Huh? Can you explain that? What it looks like is: E to the exponent negative one, modulus X. SM> That's for encryption. For decryption, you *DON'T* find them; D is SM> the private key. E and N together comprise the public key. You SM> either know 'em or you don't know 'em. SM> But, of course, you should ignore me because Richard Dale says I don't SM> know anything about this stuff. Hrph. If you can explain how to find D a bit more clearly that would be great. Also, when you take say a data like letter 'd', (ASCII:100) and say, E is a number with 100 digits, how do you raise E to that exponent? That's nuts! I don't even think the computer has enough memory to store the results. (I think if the data was ASCII:10 you'd have a number with a googol (10^100) digits, now if it were 100 the result (if say d was precisely 1 followed by 100 zeros) would be 100^(10^100)). Yikes!!! So what's the trick to this problem, because even a large number library -still- won't hold a number -that- big? - John ... Hippie: One that leaves no turn unstoned. 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 17 May 95 18:36:48 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: SUPPORT the Phil Zimmerman Legal Defense Fund! iQCVAwUBL7p6c8sQPBL4miT5AQHeVwQAljadBXVy5rD9PocLaSEVyNAwo/JW35mb P9P3F181T7Kf9xTgvPK9Q4eqRtnIkb9ZR0jhMHCy0HIU1HiMTPK7aRj/faRvby/k Ow2Sbgdb45bb9VCbF8/QaO9Kfsc8Hd9bggSry72SIW8aiJYMrz0Nma8UN0LyTRUJ /4QyYjRFFmM= =I5sS -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Shawn McMahon 18 May 95 20:28:20 Subject: Re: Pgp Stuff Available UpdReq -----BEGIN PGP SIGNED MESSAGE----- Shawn McMahon wrote in a message to jason carr: SM> In which case, you're no longer entitled to an Xx flag in SM> the nodelist. A lot of people forget that; you can't A small price to pay to avoid sharing a cell with Phil Z. :P SM> Not that loss of your Xx flag is any big deal, of course. SM> Just pointing it out, since wrong nodelist flags are a pet SM> peeve of mine. I agree the change would need to be made on one's node info. jason timEd B9 - aperitifs consumed _en masse_ display their owners on the grass -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Cryptography and echomail aren't mutually exclusive. iQCVAwUBL7wQvEjhGzlN9lCZAQGUlAP+JItOkSVDe7ZvEgePRoatY0QBPF1pevO4 H4lTxyLDt1atvjq6y12itWVzgWUyK8niwFmkUyODVGqMLaSd8NsbSFxENe73a8gk MMCT/icUpRwXTERAQN5VhF3uwBI03USDeuhBoJxiRKGxVnSJvJWc+OdpdKud/9CK z9dprMmy5H4= =Uqso -----END PGP SIGNATURE----- >> Encrypt it all. Let the NSA sort it out. << ... Key fingerprint = 60 97 B2 AE 7D 90 11 2F 05 1C 35 98 E9 B9 83 61 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Scott Mills 18 May 95 11:42:28 Subject: OS/2 PM shell for PGP UpdReq Despite the stern warnings of the tribal elders, Scott Mills said this to Shawn McMahon: SM> I freqed this over an hour ago and still know nothing about it SM> except that it has very annoying beg screens I don't think "very" is a strong enough word; the damn things steal the focus from other aps! SM> and that it isn't worth a damn for large keyrings. It's SM> been crunching for about an hour trying to read my public SM> ring and is still working on it. It opens another thread and runs PGP -kc on your keyring. *EVERY* time you run it. My keyring is 80k, and it still takes several minutes. Yours would probably take all day. It's worse if you have *ANY* keys with unverifiable signatures. Too bad; the program looks nice. But I'll never know, because I'm not going to wait on it and I *HATE* it when I'm typing a message and another program yanks the focus out from under me, just because I've committed the unpardonable sin of running it for a whole 1 minute without registering it. I don't even think I'm going to express my concerns to the author; I'm just gonna delete the silly thing. 201434369420143436942014343694201434369420143436942014343694718 From: Jim Cliffe Area: Public Key Encryption To: Christopher Baker 18 May 95 02:20:00 Subject: Text of the Russian crypto ban hatched UpdReq -=> Quoting Christopher Baker to All <=- CB> the following has been hatched into PUBKEYS file distribution: CB> YELTSBAN.ZIP Russian/English translation of Yeltsin's crypto ban. [4K] CB> all PUBKEYS links please poll upon receipt of this msg. Im acronyms of on syllable (or less) how can I get this file? I speak passable Russian, but Cybertongue is Greek to me. (I know D for download and Z for Z-modem but I'm on shakey ground after that.) Thanks JC jim.cliffe@deepcove.com 201434369420143436942014343694201434369420143436942014343694718