From: Mark West Area: Public Key Encryption To: John Schofield 27 Jan 95 02:55:34 Subject: Bbs Chat Encryption UpdReq JS> **EZ-PGP v1.07 Does EZ-PGP work in a similar fashion to AutoPGP? I've tried AutoPGP v2.12 with Win-D a front-end for Delphi Internet Services. The email.txt (ASCII) file contains all the inbound email. AutoPGP sounded as if would work, but it would chop the last 1/2 to 2/3 of the file and the worst and at the best the chars that signal a new message, "-*-", could end up part way thru the header lines ect. I know AutoPGP was made for QWK packets, but the docs did say OLRs that used ASCII file would work. What I need is something to scan thru a large ASCII, find PGP signatures and encyrpted text, process it and put the processed message in the same place where the encrypted and/or signed one was. And not add an EOF marker as well. Can EZ-PGP handle this sort of task? 201434369420143436942014343694201434369420143436942014343694718 From: Richard Dale Area: Public Key Encryption To: Jim Bell 30 Jan 95 20:41:10 Subject: PGP News UpdReq FD> Nothing like good old vigilante action when we don't agree with something, FD>*huh Jim? JB>*First, I did not mention "vigilante action," you did. (What I did JB>*suggest was a little peer pressure, a little "friendly persuasion.") Perhaps instead of "vigilante action" he meant "lynching"??? * 1st 2.00b #567 * Jethro Tull, the Lay's Potato Chips of rock music. 201434369420143436942014343694201434369420143436942014343694718 From: Richard Dale Area: Public Key Encryption To: Alan Pugh 30 Jan 95 20:43:10 Subject: Re: Can I Freq Pgp? UpdReq AP>*it. in the rtkba echo, you can't even send a signed message because AP>*the moderator is paranoid that there may be some kind of message AP>*hidden in the key. Is that the one where his initials are BK? * 1st 2.00b #567 * The problem with taglines is that there is never enough spac 201434369420143436942014343694201434369420143436942014343694718 From: Michael Babcock Area: Public Key Encryption To: RICH VERAA 28 Jan 95 01:36:00 Subject: Can I Freq Pgp? UpdReq Rich said something about Can I Freq Pgp? to Gordon on 01-13-95 08:14 ... GC> I'd argue this point. Canadians are subject to ITAR only to GC> the point that we are allowed to use the versions that are GC> subject to it. The export restrictions are not enforceable GC> in Canada. RV> Are you sure that's still true? I thought there was something in RV> NAFTA about Canada adopting a whole bunch of US laws, including ITAR. RV> (just asking; I don't know for sure) Canada is considered almost as an equal of the US when it comes to munitions exports as far as my knowledge goes. You can send PGP 2.6.2 to canada as legally as sending it next door... ... Insane? Yes, I might be. I'll ask myself and let you know. ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Michael Babcock Area: Public Key Encryption To: ALAN PUGH 28 Jan 95 01:36:00 Subject: Can I Freq Pgp? UpdReq Alan said something about Re: Can I Freq Pgp? to Jim on 01-18-95 18:58 ... AP> =-lots of reasoned discourse snipped= AP> indeed. there is strength in numbers. however, if you are going to AP> use encryption, it is important to make encrypted mail acceptable in ... AP> i really like fido and related nets, which is why i read and post AP> here and in more areas than i can sanely keep up with, but as a AP> network, fido needs to grow up a little. Had to beg my local sysop to let me 'sign' my messages, and got removed from fidonet for two weeks because someone sent ME an encrypted message via netmail...as if. ... All gave some...some gave all. ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Michael Babcock Area: Public Key Encryption To: WES PERKHISER 28 Jan 95 01:35:00 Subject: KEY REVOKE UpdReq Wes said something about KEY REVOKE to Jason on 01-20-95 10:04 ... WP> Well, I HATE to admit I might have been wrong, but it looks like your WP> way will work if you answer "NO" when PGP asks if you want to remove WP> the secret key as well. WP> I would have sworn that the revocation would also revoke the secret WP> key as well, but it looks like it only affects the public half. At WP> least, I tried your way and it DID work. Is the failure to effect the WP> secret key a bug or a feature? Scenario - you revoke your key. You get E-Mail (encrypted) from someone that hasn't gotten your revocation. How do you decrypt it unless you still have the secret key? ... "Armies are paid to kill people and break things." -- Limbaugh "Blame ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Michael Babcock Area: Public Key Encryption To: TIM WITTEVEEN 28 Jan 95 01:41:00 Subject: PGP and BWave UpdReq Tim said something about PGP and BWave to All on 01-19-95 19:02 ... TW> I recently acuired PGP 2.6.2. I have tried to send a message to the TW> friend who gave it to me. I am useing BWave 2.12 Off-line mail reader. TW> How should I go about actually doing this. Do you find it easier to TW> write your messages before or after you go into your Mail-reader? If TW> you do write it before, do you sign and/or encrypt it before you load TW> it into your reader, or do you wait until you have your reader open, TW> write your message, save it, shell to dos, sign, encrypt and ASCII TW> armour it, then add your address to the top line? TW> I would appreciate any hints or help with this. I have not had any TW> luck so far. Grab an editor...or... Reply to your message (or edit a new one) - when you save, hit ALT-D for a dos shell (do this when you're all done editing if you want). CD WORK\REPLY ... now, for me, all the messages in this echo are 4011.??? So I type PGP -S 4011.001 then DEL 4011.001 REN 4011.ASC 4011.001... you can automate this with a cheap batch file though... SIGN.BAT - called as SIGN 4011.001 4011.ASC PGP -S %1 DEL %1 REN %2 %1 Then to do multiple signatures, try FOR %a in (1,2,3,4,5,6) do call sign 4011.00%a 4011.asc That batch file, and the following line are what I use...or you can get a PGP compatible editor... ... How come pizza gets to your house faster than the police? ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Michael Babcock Area: Public Key Encryption To: WILLIAM HATTENHAUER 28 Jan 95 01:44:00 Subject: PGP Forever !!! UpdReq William said something about Re: PGP Forever !!! to Jim on 01-20-95 16:59 ... WH> government can NOT read) that could possibly cause them to REACT as WH> they are now doing? WH> Answer: a. The Truth! WH> b. Political Incorrect Ideas. WH> c. Unfiltered News. WH> d. Alternative Thought Sources. WH> e. ALL OF THE ABOVE + f. Foreign Government on whom we are spying uses PGP... g. Foreign Government who is spying on us using PGP... Although they could tighten up security instead of suing Phil...(which is going to do what? GEt us to stop using PGP?) ... Lie to opinion pollsters. ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Michael Babcock Area: Public Key Encryption To: JEFF TROWBRIDGE 28 Jan 95 18:09:00 Subject: pgp problems UpdReq Jeff said something about pgp problems to Aaron on 01-19-95 20:37 ... JT> I haven't put out a public key yet. Mainly I followed your advice JT> and the pgp sig turned out like it was supposed to. Right now JT> I'm just using the 512(?) bit key until I get more proficient with JT> pgp. Then I'll do the big key for public consumption. BTW, JT> when you encrypt a file with the ascii armour (.asc extension) is it JT> just as secure as one encrypted by binary (.pgp extension)? Sorry to interject... The ascii armored file is basically a "uuencode" type version OF the binary file...that's all... ... These opinions are my own - I reserve the option to be DEAD WRONG! ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Rob Szarka Area: Public Key Encryption To: Jim Bell 0 Feb 95 10:12:06 Subject: PGP NEWS UpdReq -=> Jim Bell spake unto Rob Szarka, saying <=- -=> Quoting Rob Szarka to Jim Bell <=- JB> [JB note: Somebody ought to find William Keane's _home_ address and JB> post it on the Internet. After a few hundred nasty-grams have JB> arrived, maybe this numbskull will get the picture.] RS> That would only confirm his belief that PGP users are a bunch of RS> lawless buttheads. Bad idea. JB> Why do people so often misinterpret posts? I said "nasty-grams," NOT JB> "letter-bombs." JB> I want that turkey to think: JB> "They all know where I live and they don't like the fact that I'm JB> harassing one of them. If I actually file charges who knows what'll JB> happen. I think I'll drop the whole thing." I understood you just fine, and I stand by what i said. Try to get yourself into the mind (tight fit!) of this prosecuter dude... ... :)8-< - Naked ASCII women, on the next Geraldo! 201434369420143436942014343694201434369420143436942014343694718 From: David McIntyre Area: Public Key Encryption To: Brian Mitchell 29 Jan 95 10:20:22 Subject: Re: PGP News 2 UpdReq -----BEGIN PGP SIGNED MESSAGE----- -=> Quoting Brian Mitchell to Chris Adams <=- BM> Chris Adams, BM> In a message on 23 January, to Jim Bell, wrote : CA> On (21 Jan 95) Jim Bell wrote to All... CA> CA> JB> Contrary to popular belief, the NSA can decrypt public keys of most CA> JB> practical key sizes. However, the computer resources needed to decr CA> JB> public-key-encrypted messages make it difficult for the NSA to perfo CA> CA> Does anyone know what they consider practical size? Also, has anyone CA> considered moding the PGP code for, say, 32kb keys? (Sure, it's a LITTLE CA> slower, but most of it is done in IDEA anyway. BTW, has anyone increased CA> the complexity of IDEA (ie, larger sizes, etc)?) Wouldn't hurt to use CA> the added capacity of these expensive computers... BM> It probably just isnt as easy as just 'modding' the source. It would BM> be extremely slow. The PGP math library may not even support BM> manipulation of numbers that big, so I would say it would be difficult BM> at best. If it could be done, it would be incredibly slow though... Hmm... It would make it slow, but probably put the time-to-crack at about a billion or so years, instead of the thousands that it would take to crack a 2048-bit key. :) My numbers are probably off, but they are to illustrate a point, rather than to be accurate. ~~~ PGPBLUE 2.0 ~~~ PGPBLUE 2.0 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: What language is this in? iQEVAwUBLytr+cdUIcX3jbSBAQEv6Qf8DfbYOF/WVDxhYaGIhjWv3tnC9smjZzCF 9icybZlHMrmBv96H7qg12bHUAhllbtYoOtqGrxywxsjQUvAZtAgNvp+lBsGv758/ 1uHcg37kztIQhdlclowDYUjnKnARksPnSNejx7/u0W2jwet03m1PqJiwbVvhf4sA 8JLU3kiPXwJScbuf1grGVi7/1OBTB3rUKk8F6+X0yEVPV+INuK5vBZfBuWA27blI pNvBJCdTlC4cEMrPGOhPg0f9uWrKofd4VosU5llF1MuU8A8T/I0ck5Xu/u7oKlAu OzxALOFTTdxeeeRDR7I32mWD6U5zYo/a/ZWKmIHexW2PLnnCloHfWA== =BQFM -----END PGP SIGNATURE----- **EZ-PGP v1.07 201434369420143436942014343694201434369420143436942014343694718 From: Ian Hebert Area: Public Key Encryption To: Jim Bell 1 Feb 95 07:39:10 Subject: PGP NEWS UpdReq JB> -=> Quoting Rob Szarka to Jim Bell <=- JB> JB> [JB note: Somebody ought to find William Keane's _home_ address and JB> JB> post it on the Internet. After a few hundred nasty-grams have JB> JB> arrived, maybe this numbskull will get the picture.] JB> RS> That would only confirm his belief that PGP users are a bunch of JB> RS> lawless buttheads. Bad idea. JB> Why do people so often misinterpret posts? I said "nasty-grams," NOT JB> "letter-bombs." JB> I want that turkey to think: JB> "They all know where I live and they don't like the fact that I'm JB> harassing one of them. If I actually file charges who knows what'll JB> happen. I think I'll drop the whole thing." I think Rob Szarka's comments are still on the money. If anything, harassing the prosecutor will only strengthen his resolve, convince him that he is right, that PGP and the people behind it are lawless and dangerous. Such harassment will also cause his fellows to close ranks behind him, and support him. If you harass the prosecutor, basically, you're looking at a public relations disaster of the first order--you're risking all the potential public good will that Phil, his lawyers and outfits like the EFF are trying to generate. Look at it another way--how much good will has the anti-abortion crowd gotten with all their harassment tactics towards doctors who perform abortions? Picketing people's houses and harassing them only earns the harassment victims public sympathy; both the people doing the harassing, AND THE CAUSE THEY REPRESENT end up getting a black eye. The anti-abortion crowd has learned this the hard way--no matter how much they claim that the harassment is only the work of a small, militant minority, nevertheless, the entire movement has suffered. Ian Hebert London, Ontario, Canada RIME: HOMEBASE (5508) Fido: 1:2401/114 Internet: ian.hebert@homebase.com PGP Key: 1024 / 077A2F7F 1993/02/11 PGP Key Fingerprint: A2 15 DE 22 DA FE D4 DC 0F 17 43 24 1F F2 1E 7B 201434369420143436942014343694201434369420143436942014343694718 From: Ian Hebert Area: Public Key Encryption To: L P 1 Feb 95 07:40:10 Subject: Pgp News 2 UpdReq LP> SM>The weak point in PGP is the RSA encryption LP> Is this something that you could explain here (if so, please do) or do LP> I need some background to understand? LP> Does this have anything to do with the difference (if any) between the LP> encryption used in pgp23a as opposed to the MIT versions? This LP> question no doubt displays my ignorance, but there's no such thing as a LP> dumb question, right? No. The reason why RSA is regarded as the "weak point" in PGP is that the IDEA algorithm has been estimated as roughly equivalent in strength to a 3100-bit RSA key. Thus, it is easier to try to factor the RSA modulus, rather than attack IDEA directly. Ian Hebert London, Ontario, Canada RIME: HOMEBASE (5508) Fido: 1:2401/114 Internet: ian.hebert@homebase.com PGP Key: 1024 / 077A2F7F 1993/02/11 PGP Key Fingerprint: A2 15 DE 22 DA FE D4 DC 0F 17 43 24 1F F2 1E 7B 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Feb 95 16:37:38 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] iQCVAwUBLy//JcsQPBL4miT5AQHnxwP8DwjCqTRGD2S4T5reOiM/7d7fk27Lr71D R/WASX1StITO4hs++wXfrw3Q7PYIOG5mCbzRbFuhgIK6e4lFGvDx/N4HUmiaGMAQ RVa5Sb0FyNTy/qp/n5iYnUItAhb/zxvM2ybYcMnRgR/FtudPfgr8IztGoO8yWC5O 6svGObL0h+Y= =TeaZ -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Feb 95 17:30:44 Subject: FidoNet filename conventions for PGP-related filesUpdReq -----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] iQCVAwUBLzALm8sQPBL4miT5AQEIvgQAjwUJOLvz5n+EHGG2LoLpYcV0IZBumxwU iwW75JMsMBkjIvedIMMDT2DCTobjXvu+XZxUC1h6BqaUKoiZSmy59M6zPn46tm7D FoIjgxImnllN5lQUhAolfAEC2cDAHQQlHaG68+A7KaHqfbTUGjHS5lskdWEOlluC QF0Ybf3hJag= =W8tE -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Feb 95 17:31:46 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- TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLzAL1ssQPBL4miT5AQEtIQP+IPV1OQKenZBwlHGMM0ycbIdeIxRfVlAI e3M/ofUkw0IADrUINTKkeMk8hnjXtcjRBzFtmVw5WHzEZifV34BPr7IMRra8EoEF 55SezNtY3HA/5Hl/EZVJg3cjSrZHG53FFibGUIQkRAR6dVKFPMWNTwTEmr8heFS2 ZLwKMGZTYk4= =UjPY -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Feb 95 17:33:16 Subject: SecureMail Host Routing System topographyUpdReq -----BEGIN PGP SIGNED MESSAGE----- SecureMail Host Systems Zone Sysop Address |--ISMH Jim Cannell 1:216/21 | | |--Z6SMH Open | |--Z5SMH Open | |--Z4SMH Open | |--Z3SMH Open | |=================================================================== | |--Z1SMH Jim Cannell 1:216/21 | | | |-- 4:97 Juan Jose Rodriguez 4:970/4 | | | RSMH Net Sysop Address Flag | |--- 10 Dan Wilson 1:206/2507 X | | | SMH |-- 102 Dave Lord 1:102/338 | |-- 119 Richard Ratledge 1:119/88 | |-- 125 Barry Kapke 1:125/33 X | | |-- 352 John Burrows 1:352/333 X | | | |-- 143 Radi Shourbaji 1:143/110 X | |-- 161 Mike Burgett 1:215/705 X | | |-- 215 Joe Pye 1:215/25 | | | |-- 202 Guy Martin 1:202/905 X | |-- 203 *none at present* | |-- 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 | |-- 2215 Jim Bailey 1:2215/480 | |-- 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 | | | |-- 107 *none at present* | |-- 267 *none at present* 1:267/109 X | |-- 2613 Jack Mooney 1:2613/108 X | |-- 2623 Cindy Ingersoll 1:2623/71 | |-- 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 *none at present* | |-- 291 *none at present* | |-- 296 *none at present* | | |--- 15 Dave Munhollon 1:128/86 X | | | |-- 114 *none at present* | |-- 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 | | | |-- 132 Allan Hitchmoth 1:132/209 | |-- 323 Todd Rourke 1:323/110 | |-- 325 Frank Perricone 1:325/611 X | | |--- 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] | | | |------- 285 Mike Riddle 1:285/27 X | | | SMH |-- 116 *none at present* | |-- 123 Scott Miller 1:123/416 X | |-- 135* David Bobo 1:135/110 | |-- 151 James Barrett 1:151/132 X | |-- 360 Stephen Frazier 1:360/23 X | |-- 362 Jack Whaley 1:362/940 X | |-- 365 Chris Britton 1:365/200 X | |-- 366 Rob Buckman 1:366/844 X | |-- 369 *none at present* | |-- 374 GK Pace 1:374/26 X | |-- 375 Michael Hess 1:375/48 X | |-- 378 Sydney Marcus 1:378/10 X | |-- 379 *none at present* | |-- 3608 Michael Smeby 1:3608/3 X | |-- 3636 Chris Chastain 1:3636/16 X | |-- 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 | |-- 130 Dale Hopkins 1:130/908 X | |-- 147 Bill Teasley 1:147/3660 X | |-- 170 *none at present* | |-- 382 Chuck Haynes 1:382/502 X | | |=================================================================== | | |--Z2SMH Harry Bush 2:51/2 | | | RSMH Net Sysop Address Flag | |--- 50 (Russia) Dmitry Kiselev 2:5026/3 | | | SMH |-- 5022 Dmitry Turevsky 2:5022/8 | SMH |-- 5026 Dmitry Kiselev 2:5026/3 | SMH |-- 5057 Andrey Semiuglov 2:5057/1 | | |--- 51 (Latvia) Egons Bush 2:5100/8 | | | SMH |-- 5100 Egons Bush 2:5100/8 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.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLzAMMcsQPBL4miT5AQHa6QP/QUc7YChUNATC14USCzphnYYio+M4Q29Q LeqFqlsE6NAb6ww4vpRm+tJPWhukA9UKu7O+fbgWF7iHcgVa0JBD4K8aFwo/uPrK g44sOoDb3bnD544MHPodZYdZKqh7vGUqNxk7rJr6FZVIuZBgL4PUAbFTyX1zguOj wxiWvGGORvY= =Q2pk -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: Alan Pugh 1 Feb 95 17:35:46 Subject: Re: that availability list you posted in parts [Was: Re: Can I Freq Pg -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 30 Jan 95, Alan Pugh was quoted as saying: AP> i'll be posting it on the board as the file wherepgp.zip in file AP> area 1000. i don't know if you can freq it as i'm not the sysop. my AP> friendly sysop is stacy powers. i'll leave him a copy of this AP> message (if i can figure out how to cc messages with this software) let me know when it's available. thanks. AP> the file is periodically revised and posted to the cypherpunks AP> mailing list. as long as we don't have to bother my sysop every AP> time it is updated, i can kill the existing and update it with the i pull that now. i'll keep an eye out for it and compile my own copy in the future. AP> address, i can send the thing to you there. i've had difficulty AP> posting through fido, so if you have another way of recieving mail, AP> that would be preferable. i don't think i can do netmail, and some AP> sysops won't pass encrypted mail due to their own paranoia. you can use the address at the bottom of this msg for Netmail. AP> if you can send me a message to the address 0003701548@mcimail.com AP> i can more easily get messages back to you. okay. thanks, for the info. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLzAMxMsQPBL4miT5AQF6kgP/ac1oAcCQJrdu6bfWc+By3TgpGDLHJp/S hH1s7gjwkcj0BBmGCplfO49fF3bfoYNe78R5Z8GlYLAHLmd12G5fEGJDeiesRqcS UddxdnVtJ5iHwYKAMFUcU1ybdK/LU8LL1JofFJ9ws6WMKP5Fko4E1ClZHY5oyE1I sLd0YGiiaLg= =uBGO -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Rich Veraa Area: Public Key Encryption To: DAVID BROOKS 31 Jan 95 17:15:32 Subject: PassPhrase UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message to Rich Veraa, DAVID BROOKS wrote: DB> So tell me, how did you get the comment added to your DB> sig? I have not seen any mention of it in the PGP docs DB> nor have I seen any mention of it anywhere in the program DB> itself... how do you do it? If you've got v. 2.6.x, put a line in your CONFIG.TXT file saying: comment="This is a comment." Cheers, Rich -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: rveraa@907.sunshine.com iQCUAwUBLy6M9Z80iJ+tnwVVAQHo3gP2OJtkO94crCRWDFkPiZwHQStx7ic43T0i JhMvYTSd/HekF6CZemiOzD6jT2XqDQnNiP7bFbIAj3lUjUomRfZD65U4KWL8cx7/ mtzEdOcKBIHRttOLlPFr6Z1g3owFfwA03XJ0UnOxlVUpgKl4y/yXdPfcMUbafnyZ fCMywdxNGw== =Q8gs -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: Chris Adams 31 Jan 95 00:30:00 Subject: Quotes as passphrase UpdReq On 01-28-95 (14:43), Chris Adams, in a message to David Chessler about "QUOTES AS PASSPHRASE", stated the following: CA> CA>Which is why it would be neat if PGP had a FAKE password that, when > >entered, would "accidently" reformat the harddrive after wiping the >key! CA> DC> That would be more appropriate for a program like SECDRV, SECDEV, >or SFS > DC> (or the forthcoming CryptDisk for the Mac), which set up an >encrypted > DC> partition. CA>Okay, how about something which deletes the message AND the key? Would >complicate their job a bit. A bit. By analog means they can read an erased and overwritten sector, depending on your disk technology (it's harder on modern disks; certain caching schemes and intelligent controllers make it easier). CA> DC> Of course, if you did that, they would spot the formating >(overwriting a > DC> disk takes a l-o-o-o-o-ng time), and then they might use more than >just > DC> rubber hoses. CA>Not that kind of format, just wipe the key, file, and zap the fat. Makes it a bit harder, but possibly nothing serious, since they might be able to reconstruct these. Wiping the fat (and the directory) is more difficult than you think. The file has to be renamed, then the name overwritten, and then the file overwritten. Look at the docs for a good file-overwrite program some time. And then they still have the option of trying to read the disk in analog mode. And working you over with the rubber hoses. -- ___ __ 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: David Mcintyre 31 Jan 95 10:13:00 Subject: Re: quotes as passphrase UpdReq On 01-25-95 (05:55), David Mcintyre, in a message to Chris Adams about "RE: QUOTES AS PASSPHRASE", stated the following: DM> DC> At some point the passphrase can only be attacked by brute force >(which may > DC> mean rubber hoses on the person who knows the phrase). Generally, DM> CA> Which is why it would be neat if PGP had a FAKE password that, when > CA> entered, would "accidently" reformat the harddrive after wiping the > CA> key! DM>Write it into your code. The source is freely available. The only >problem is, if the person trying to decrypt your message was smart, >they'd just use your keyfile and their binaries. Actually, it's a rule of thumb to never work on an original document, but only on a copy. We can assume that they'll take an image of your hard disk, and work on that. So the password idea should really be part of the thread we had a while back on ways of automatically wiping a hard disk to make it totally unreadable (big magnets, etc.) In any event, if you're under surveillance, now that PGP is available, and SECDRV and SECDEV and SFS, you can figure that the surveillance will include a Tempest attack (monitoring what you type and what appears on your screen. Putting the cover back on your PC will help :-), as will switching to a portable, but you're really going to have to line your room with aluminum foil and do other strange things to really defeat a Tempest attack. They just sit in a van (labeled phone company or CATV or something) on the street, and watch you, and listen to you. Seen any strange trucks lately? My neighbor parks two vans and a truck in front of his house. Maybe it's not really for his business.... -- ___ __ 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