From: Zorch Frezberg Area: Public Key Encryption To: Shawn McMahon 14 Sep 94 05:48:36 Subject: Net 106 still at it? UpdReq In a msg on , Shawn McMahon of 1:19/34 writes: jc>> It re-addresses, bounces, or alters the handling bits on jc>> netmail depending on the FROM, TO, ADDRESS (from and to), jc>> SUBJ, or handling bits... SM> Sounds an awful lot like necessary system maintenance to me. I SM> doubt the program itself would be a violation, although you could SM> certainly use it to create a violation. I use it here for the PORTER echo...it has, unfortunately, a severe limitation as far as I'm concerned. I use it to bounce messages from/to certain individuals into a special reading area for me; the problem is that it won't/can't/doesn't tag what message base that the message comes from. Beyond that, I can set it to scan for your name, bounce and readdress it, and send it in a completely different area or netmail path. No reading of your mail; but I would have to know you're going to send something in order for it to work . I haven't found anything that will do the equivalent of a 'pass-through' in NetMail short of this or UFGATE. -zf- 201434369420143436942014343694201434369420143436942014343694718 From: Zorch Frezberg Area: Public Key Encryption To: Richard Walker 14 Sep 94 05:55:44 Subject: Re: New to PGP UpdReq In a msg on , Richard Walker of 1:106/960 writes: RW> Envelopes do not provide security. They only provide physical RW> protection for the letter inside from the mail flinging RW> machinery. This is wrong. Envelopes provide security. Harken to the 'olden dayes' when a scroll was rolled and sealed with wax to keep prying eyes from reading it or as proof that it wasn't tampered with. RW> Simple physical possibility: RW> 1.) Postal inspector wants to open envelope and read mail Has to have cause. Obviously, you've never met or talked with postal inspectors. To do this, the PI would have to *find* your specific mail in order to do this. In order to get your mail separated, there is an interesting procedure that must be followed. Ask about "Mail Intercept" at your local postal inspector's office. RW> 2.) Postal inspector takes blank envelope and photocopies the RW> front of yours onto theirs (minus stamp and postmark). RW> [if careful, will instead place on a light table and RW> trace it with the same color ink, to give written vs photo RW> quality] Uh-huh. I can see the FBI or CIA doing this, but the USPS doesn't have the time or energy. RW> 3.) Postal inspector opens yours and reads it. And? In an delusional paranoiac, I can see this as a possibility, but the postal inspectors don't have time or energy to do this. Again, this would be a FBI or CIA action, and the interagency hassles would be tremendous. RW> 4.) Postal inspector places your letter in his envelope, RW> restamps and post marks it. Why bother? This happens all the time. You've never received a 'OPENED IN ERROR' notice stapled to the envelope? I've gotten four in my life, and on three of these, it was obvious that someone tore the envelope open by hand===once was obviously a machine mangling. Throws out your theory that an envelope is to protect the contents from a machine, doesn't it? RW> 5.) Recipient recieves envelope, opens it, removes the RW> letter, wadds up the envelope and tries for the three pointer RW> from across the room, and reads the letter, none the wiser. Even more so is an easier method... Initial the spot where you put the stamp. Cover it completely with the stamp and send it. If you can't see the initial under the stamp when it arrives, you know its been tampered with. RW> Besides, a letter costs about $.40, a direct crash sent email RW> will cost you only $.23 even instate and during the business RW> hours. So if you want security, send it direct. Still not correct. If I want something secure, I'll send it direct. To be _CERTAIN_ it is secure, I will also encrypt it to make it absolute in my mind that the addressee and only the addressee will read it. Sheesh. Anyone who's ever written love letters knows this one as a basic fact of life. -zf- 201434369420143436942014343694201434369420143436942014343694718 From: Oliver McDonald Area: Public Key Encryption To: Jim Bell 14 Sep 94 15:45:38 Subject: ENCRYPTION... UpdReq Jim Bell wrote in a message to JESS WILLIAMS: JB> However, if such keys are eventually crackable, it will JB> probably be because of an algorithmic breakthrough, not an JB> increase in CPU capability. That's because even if CPU JB> power increases by a (very optimistic) factor of 2 each JB> year, that's "only" a factor of 1000 per decade, or a factor JB> of 1E15 in 50 years. And obviously, as computer power increases, the bit size of the key can be increased as well, so brute force will only ever work on those people who aren't worried about having their data decrypted. Oliver -*- Practice Random Kindness & Senseless Acts of Beauty. 201434369420143436942014343694201434369420143436942014343694718 From: Oliver McDonald Area: Public Key Encryption To: Shawn McMahon 14 Sep 94 15:49:14 Subject: Re: New to PGP UpdReq Shawn McMahon wrote in a message to Richard Walker: SM> Despite the stern warnings of the tribal elders, Richard SM> Walker said this to Shawn McMahon: RW> Considering McD's just got nailed for 2+mil for some lady RW> spilling coffee on herself, I'd say the liability is very RW> real. SM> Numerous court precedents, going all the way to the Supreme SM> Court, and the opinions of every single communications SM> attorney I've ever seen quoted, disagree with you. It does depend somewhat upon which legal jurisdiction one resides in. According to my resident net legal expert, the policy of examining mail that passes through your system for legalality would probably stablish mensrea in Canada. This would mean, in all likelyhood, that a conviction could be obtained if you allowed unlawfull material to pass through your system in the form of routed netmail. If however you never see, let alone inspect, the routed netmail, you are unlikley to be charged, let alone convicted. Of course this is in Canada, YMMV in the US or other countries. A final point, is that should the government want to take you down as a BBS operator, they don't need a conviction that will through you in jail, all they need to do is make it to expensive in legal defence costs to continue to run the BBS. Oliver -*- Practice Random Kindness & Senseless Acts of Beauty. 201434369420143436942014343694201434369420143436942014343694718 From: Bert Byfield Area: Public Key Encryption To: John Schofield 13 Sep 94 23:57:00 Subject: Re: Signing My Own Key. UpdReq JS> AP> i'm still confused. JS> Yep. {grin} JS> ... I tried an internal modem, but it hurt when I walked. I'm confused, too. I know some cryptography, but I'm still back in the ACA mindset, not having upgraded to kilobit key thinking yet. But I have a question. Has ANYONE made a serious attempt to crack PGP? Anyone who would tell us the result, I mean. If I was an executive at the NSA, it would be high on my pert chart. < P.S. Consider that tagline snatched! :-) > * JABBER v1.2 * Banned Novels by CARAVELA BOOKS Henrietta NY (716)359-9709 201434369420143436942014343694201434369420143436942014343694718 From: Frits Spieker Area: Public Key Encryption To: Christopher Baker 14 Sep 94 00:19:04 Subject: PGP 2.6.1 hatched UpdReq Christopher Baker to All, Friday September 9 1994 about "PGP 2.6.1 hatched". CB> license. file-requests from outside Zone 1 may not be honored for CB> these files. Hello Chris, How is anyone going to stop someone from outside Zone 1 from freqqing that file? I mean, it's *real* easy to set up my mailer temporarily with a nodenumber and matching sysop-name from any zone1 system. Besides, if these files may not be exported outside the US, how do you handle Canadian freqs? I feel it would be safer NOT to put this version up for freqs. You know me, always looking for a back door ;-). Talk to you later, // Frits // 201434369420143436942014343694201434369420143436942014343694718 From: Frits Spieker Area: Public Key Encryption To: Carl Hudkins 14 Sep 94 00:25:04 Subject: Intermail mangling... UpdReq And then Carl Hudkins mumbled something about 'Intermail mangling...'. CB>> "Badly formed Armor checksum" is what is reported here on your CB>> mangled signature block. CH> Thank you for confirming that outgoing stuff is also CH> being pureed. :) I won't bother signing any of my posts here until CH> we get this fixed. The only thing you have to do is go into imsetup -> editor -> line length and decrease it to something like 60 characters per line. Some editors, the internal editor of Intermail being one of them, have some word-wrapping scheme that causes problems like described above when/if the the maximum length of a line is set to high in the editor. (One of the *many* reasons I don't use Intermails internal editor ;-)) CH> Any InterMail experts out there???? Send mail to Anthony Please forward it to him. Grtz, // Frits // 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: Frits Spieker 14 Sep 94 12:39:46 Subject: Re: PGP 2.6.1 hatched UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 14 Sep 94, Frits Spieker was quoted as saying: FS> How is anyone going to stop someone from outside Zone 1 from FS> freqqing that file? I mean, it's *real* easy to set up my mailer FS> temporarily with a nodenumber and matching sysop-name from any zone1 FS> system. if they did so, they'd be engaging in illegal activity. FS> Besides, if these files may not be exported outside the US, how do FS> you handle Canadian freqs? Canada is in Zone 1. FS> I feel it would be safer NOT to put this version up for freqs. you can't put it up since it cannot be exported to you. that's why we now have a PUBKEYZ1 for restricted stuff. it only goes to Zone 1. FS> You know me, always looking for a back door ;-). it is my understanding that the 2.6 source is already over there. simply debugging it better than MIT did would produce a 2.6.1. and wouldn't require anyone breaking U.S. export law. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLncnRcsQPBL4miT5AQE7PQP+KrxRNoGtCXlZwo2JD+RoJqFmezkTcOPj 2o9oJc8+3xkHPIeTmd3We3Ygpn6wGxOuHPgz7JVnO1qgHHCHcMS52vXEiWbTTBgE ghGvvhH6GBMEKiBW7YeXFA8QBiw+2D5+IcZzeTrmvFFt412KR66ccLtkUhMTkd5l 2KxDwfPQEQU= =1h4r -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: gk pace Area: Public Key Encryption To: Christopher Baker 14 Sep 94 14:35:34 Subject: Re: Re: PGP 2.6.1 hatched UpdReq In a message dated: 14 Sep 94, you were quoted as saying: CB> FS> You know me, always looking for a back door ;-). CB> it is my understanding that the 2.6 source is already over there. simply CB> debugging it better than MIT did would produce a 2.6.1. and wouldn't CB> require anyone breaking U.S. export law. It is my understanding (and that ain't always a good guide!) that only the RSAREF toolkit, or anything containing or derived from it is restricted, since PGP 2.6.1 lacks the ability to function without it... If one obtains that portion of the source code, adds the files RSAGLUE.c and RSAGLUE.h from version 2.3a, making the necessary adjustments to interface with it, one would have a version of 2.6.1 that doesn't use RSAREF. Those of us in the US are advised not to do so, since use of the non-RSAREF functions "may" violate US patent laws. -gk 201434369420143436942014343694201434369420143436942014343694718 From: Wes Perkhiser Area: Public Key Encryption To: Ed Wilkie 13 Sep 94 19:56:24 Subject: revoking? UpdReq In a message of , Ed Wilkie (1:236/51@fidonet.org) writes: EW>revoke it I realized I was having a problem. PGP said something EW>about a revoke key certificate but absolutly nothing on how it's EW>done. Revoke the key (as you have done already) then eXtract the key (-kx[a]) to get the certificate that you can then post. Wes 201434369420143436942014343694201434369420143436942014343694718 From: Tim Bradley Area: Public Key Encryption To: Wes Landaker 14 Sep 94 16:05:16 Subject: Net 106 still at it? UpdReq -----BEGIN PGP SIGNED MESSAGE----- WL> But it doesn't _censor_ the messages. If you were deleting every WL> message that came through your system that constained the words "hello" WL> and "bye," I think you'd probably run into a little trouble. :) You'd WL> probably be pretty upset if the phone company set up a little device to WL> make your phone conversations disconnect whenever you said the word WL> "okay," wouldn't you? I sure would be! =) RW>> Just because you get a signed message bounced back to you, does not RW>> prove that it was read by anyone unauthorized to do so. WL>> As surely as you've read this message, someone did. Maybe that isn't WL>> _PROOF_, but it's pretty damn close. :) RW>> Don't see as how the action in regards to a public posting to an RW>> echmail conference has anything to do with the handling of private RW>> netmail. WL> You quoted my message, and replied to it's content. The person I was WL> talked about, QUOTED my message, and told me not to send encrypted WL> traffic through his system. Maybe he didn't _READ_ it, just as you may WL> have not _READ_ my last message--but at the very least, eyes had to WL> stare at my message when it's in the same screenful of a message as the WL> response to it. :) You might as print out someones private mail, and WL> write comments about what he wrote on the paper, then try to say you WL> never read the mail, 'because it's the same exact thing. =) Just to throw a little more fuel on the fire now that I can do mail again -- I would be willing to bet that leagally speaking, there is a BIG difference between an automatic "bounce" with a automatically placed header and a quoted message -- but I still don't agree that there are going to be ANY convictions based on BOUNCING traffic of ANY sort -- Fido is volunteer-run, and I really think you'd get chewed up in court trying to say you have a right to FORCE someone to do something that they feel (with some justification) puts them at risk. Sure, if they spread your info around, bust 'em. If they PERSONALLY read your EMail, MAYBE. But I really think that just bouncing encrypted mail is going to get NO kind of conviction. And to be honest, the main reason I gripe about people who are ranting that it WILL is because in my observation, the fact that the "Touch my EMail and I'll take your System" people ignore some seriously obvious flaws with their position -- among other things, no matter HOW much explicit protection the ECPA does or does not provide EMail, it does **NOT** say that EMail & snail mail are equivelent under the law... and every time people draw that comparision as if it had ANY legal weight at this point, they HURT the cause of gaining REAL electronic civil rights. And anyone that thinks the judicial community has ANY clue about modern technology would be advised to check out the Patent Office and the judicial decisions that routinely SUPPORT the idiocy that comes OUT of the Patent Office -- Phil Zimmerman's case is a prime example, as he based PGP on Academically published algorythms -- the RSA Patent wasn't even APPLIED for for three months AFTER the algorythm was published. Yet Phil STILL got slammed in court. For a good many years to come, RATIONAL judicial decisions are going to be a completely random occurance, and the sooner those of us who *DO* want a guarenteed right to privacy REALIZE that, the shorter we can cut the period of misinformation & bad legal precedent. As a perfect example, someone cross-posted Phil's comments on PGP v2.6 to the Amiga PD Review Echo, and (predictably), the Moderator barked about the digital sig -- "No encrypted messages on Fido". She got half a dozen comments that a} It wasn't encrypted, and b} Get used to it -- we WILL have encryption everywhere soon. NO-ONE actually explained what the d@mn Signiture WAS or why it was useful, or WHY those illegible ASCII bits weren't exactly true "encryption" by FCC standards. So Jeanie's left with yet another impression that those Cypherpunk Crypto-paranoids want to take over the net and don't care who gets in their way -- which isn't the case at ALL in this instance, and in the vast MAJORITY of instances, but it *IS* the impression that this kind of "Route my mail or I'll take your system, and if my traffic's illegal and you get busted for carrying it, tough" Attitude gives people who don't really understand the issue. And THEY are in the Majority -- survey after survey lately has said that the average citizen is HAPPY to give up some of their civil rights (some privacy among them) in order to be protected from crime -- and radical cypherpunkhood ENCOURAGES that kind of reaction. Which is not, I think, what ANY of us want... Later Daze, -- Tim Bradley -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: Would you send a letter without an envelope? iQBVAwUBLndzbTDp94PCS+V9AQFUVgH8Cm7AUOkHtJ9zcpPOFZvEtQ+81PvUca8/ 2yJjme9JIH1uvLzI2c/49mF/XcDnKRkvoDwZMTxVIVNQCefypCYvVA== =2IeH -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Tim Bradley Area: Public Key Encryption To: Richard Walker 14 Sep 94 16:22:48 Subject: New to PGP UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message of 11 Sep 94 Richard Walker wrote to Shawn McMahon: RW> Better off simply terminating the availability of routed netmail. That RW> solves the problem start to finish. And it is a policy that is all too often followed these days. Bah, humbug. Too much paranoia, too little real information, and WAY too much ranting & raving on both sides. I REALLY want to find a SecureMail Hub local to Atlanta so I won't have to worry about paranoid sysops any more. How are you going to get busted for carrying something you CAN'T read? RW> Considering McD's just got nailed for 2+mil for some lady spilling RW> coffee on herself, I'd say the liability is very real. Proof of my point, though that's probably not how it was intended -- in a world with such irrational legal decisions, you CAN'T protect yourself 100%, so the marginal risk involved in carrying encrypted mail EXISTS, but it's not even as risky as walking down the street , so why worry about it?. And yes, Richard, I *KNOW* you don't route mail, but you've set yourself up as the spokesperson for Sysops Who Won't Route Encyrpted Mail (Do I see a Geraldo show?), so what I'mm saying applies to the POINT you seem to be trying to make... Later Daze, -- Tim Bradley -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: Would you send a letter without an envelope? iQBVAwUBLnd3qjDp94PCS+V9AQFZJQH9Gsvdss5njpNkIf0gopbJ8UmvhN35bGyu VQep5s1NWa0J9gpe1YSEHaAjjgSRW+sNsAXLYrcllDBN+o0plUjhzg== =Snwq -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Tim Bradley Area: Public Key Encryption To: jim bell 14 Sep 94 16:32:44 Subject: RSA Broken UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message of 06 Sep 94 jim bell wrote to GEORGE HANNAH: jb> Well, the current best systems for factoring large numbers are FAR jb> better than "brute force" systems. For example, the factoring of a jb> 430-bit number (equal in size to that recently factored to "break" a jb> particular RSA key) would presumably take an average of 2**214 "tests" jb> if you checked every number up to sqrt-N, or perhaps 1/1000 of that if jb> you could somehow only check prime numbers. Even that is somewhere jb> around 2**200, or a trillion trillion trillion trillion trillion. The jb> fact that such a factorization could have been done in a "reasonable" jb> amount of time should warn us that further improvement may be possible. Um, I am given to understand that the particular "family" of *RSA* keys that can be broken are a specific, easy-to-crack subset containing a high number of redundant zeroes. Odds against a key from that subset in an ACTUAL *PGP* key are quite low, and fairly easy to avoid -- I expect that the next key-generation algorythm used will autodetect such keys and cut them out completely ... if you have access to LOTS of back messages on this echo, someone posted a run-down on the mathematical details, but I don't have the post where I can get to it at the moment. The post included a simple way to check your key to see if it fell into the "crackable" catagory (mine wasn't, so it was a file-&-forget ... sorry). So the point was that PGP is still FAR more secure than current and even immanent cracking power, but that there are some avoidable vulnrabilities with the RSA scheme... Later Daze, -- Tim Bradley -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: Would you send a letter without an envelope? iQBVAwUBLnd5/TDp94PCS+V9AQGoJwH/ZTj23ObioloV3SZrWj9SWF/AoLZr+d3x Las/V/g4eEyRKXZsVr5oe5JJVMMq5vV2N8D1/iC+AKTxhEAOV/kEYg== =WBZW -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Tim Bradley Area: Public Key Encryption To: Brad Stiles 14 Sep 94 17:02:28 Subject: New to PGP UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message of 05 Sep 94 Brad Stiles wrote to Shawn McMahon: BS> Hello Shawn! TB>>> "Electronic Mail"), but those rights are predicated on the message TB>>> being placed in an area where there is "A reasonable expectation of TB>>> privacy" -- and all other issues of that SM>> Mike Godwin, a legal counsel for the EFF, [...] says that if the SM>> messages have restricted viewership, [...] then they're covered by the SM>> ECPA. SM>> He's a communications attorney, Tim. Why should any of us take your SM>> word over his? BS> While I'm inclined to agree with you on this one Shawn, let's look BS> at why others might not. Tim has at least attempted to justify his BS> opinion in the context of the ECPA itself, while all I've seen from Mr BS> Godwin is a second-hand statement that such private messages are BS> covered by the Act, *without* referencing it, rather just saying that BS> it is covered. The "I heard him say..." type of thing. BS> Now I am *not* saying that just because Tim offers an explanation BS> for his position, it is necessarily the right position, but he *has* BS> offered a reason. Whether or not that reason is a good one, remains to BS> be seen. BS> What I *am* saying is that a statment from an expert, without BS> giving the reasons for that statment, isn't any more worthy of BS> automatic acceptance that the opinion of a non-expert who has at least BS> taken the time to provide some reason. BS> That said, is there any chance that Mr. Godwin has published the BS> rationale for his opinion? If so, where can it be had? If I missed BS> it, I apologize and withdraw the above statement, and could somebody BS> repost or netmail it? T'anks for the support -- I THOUGHT I'd tried to give an explanation . And I have *NO* problem with being disagreed with, btw -- especially since I'm very definately *NOT* saying that my interpretation of "reasonable expectation of privacy" is THE legal one -- what I'm saying is that until a body of APPLICABLE case law is built up, NOBODY knows the "REAL" legal protections, limits, & responsabilities. And while Mike Godwin's no doubt a great guy and wonderful legal expert, it's kind of important to mention that a} He works for the EFF -- great people whose work I'm very much in favor of, but they *DO* have an agenda -- and by fostering the belief in legal & BBS circles that his *IS* the only valid interpretation DOES help establish it as being so: iow, anything Mike says needs to be taken with the understanding that he gets PAID to say things like that; and b} Mike Godwin went straight to the EFF from Law School -- he has NEVER practiced law OUTSIDE of the EFF. So again, while I RESPECT his opinions, he IS biased in his OWN exposure to Communications Law ... it's not THAT unreasonable to wonder how much of his comments are FACT and how much are HYPE -- and without a bit more quote available, that's impossible to tell... heck, from the ellipsed state of the Quote, it could have been taken TOTALKLY out of context even if it IS Mike's exact words & was originally based on solid evidence... Later Daze, -- Tim Bradley -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: Would you send a letter without an envelope? iQBVAwUBLneA8jDp94PCS+V9AQGuqAIAk799ZMvFz4HNkyy6rPxKv+d8dcFYrIql hl74BZYu2xx6AaDMp6O4Dsanf8bL+kC10lIs6J/dhcInVU6ToLWIEg== =b/QK -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Tom Almy Area: Public Key Encryption To: Christopher Baker 15 Sep 94 10:29:00 Subject: PGP 2.61 alternate and source UpdReq -=> Once upon a time, Christopher Baker said to All <=- CB> once again, a bug fix for PGP is available while we wait for a fully CB> functional MIT release. OK, what's *wasn't* fixed in 2.61? Tom 201434369420143436942014343694201434369420143436942014343694718 From: Tom Almy Area: Public Key Encryption To: Jeff Hancock 15 Sep 94 10:35:02 Subject: There goes more freedom! UpdReq -=> Once upon a time, Jeff Hancock said to *.* <=- JH> - (UPI) WASHINGTON, DC. The White House confirmed today that the FCC JH> will become the Federal agency to assume responsibility for regulating JH> the so-called "Information Super Highway." [...] I hope nobody is taking this post seriously. It is obviously a joke (but a good one!) Tom 201434369420143436942014343694201434369420143436942014343694718 From: Peter Tan Area: Public Key Encryption To: Jesus Rafael Lee 13 Sep 94 16:50:10 Subject: ftp site with keyrings UpdReq Jesus Rafael Lee said to All (13 Sep 94 02:10): JRL> Does anybody here knows which tp site has the key rings of most of the JRL> PGP users? Isn't the site listed in the PGP DOCs?! _____ |____) - PGP 2.6 public key available! |eter - FREQ "PETER.KEY" from 6:600/403 ... Eat faeces! 500 billion flies can't be wrong! --- RemoteAccess 2.02+ 201434369420143436942014343694201434369420143436942014343694718 From: Leroy Ang Area: Public Key Encryption To: John Schofield 15 Sep 94 18:17:10 Subject: New To Pgp UpdReq On 31 Aug 94 04:13pm, John Schofield wrote to Richard Walker: JS> -----BEGIN PGP SIGNED MESSAGE----- ... JS> -----BEGIN PGP SIGNATURE----- JS> Version: 2.6 JS> Comment: Call +1-818-345-8640 for information on Keep Out JS> iQCVAgUBLmUN2Wj9fvT+ukJdAQGL8QQAoih/qnT+3bt2u59fJ6x1JFDdz25w7NTG JS> YHSiGCBNr1CtGo3KDnf8Z43g2IWbFFZgZ3Xc0AUnM6IGlIvmqWLiIhzEEhqGTu1Z JS> lx7rZI2NCMRTj8V/raTwwJAfksd555bKy+nLD5J4eFZpLzu3mbkaoYQifkF25x2D JS> wubXLYhgNqQ= JS> =XAE0 JS> -----END PGP SIGNATURE----- JS> **EZ-PGP v1.07 JS> ... A day without sunshine is like night. JS> --- Blue Wave/RA v2.12 Do you mind teaching me how to use PGP with BlueWave? I tried using batch files to sign my mails but not very successful and my knowledge on batch programming is very limited. So can you help suggest any solution? +----------------------------------------------------------------+ | Leroy Ang. | Sending greetings to Everyone. || Internet : Leroy.Ang%oconn@csah.com || May all beings be always well and happy. +----------------------------------------------------------------+ ... Thought of the day....... To QuaWK or not to QuaWK? * Evaluation copy of Silver Xpress. Day # 3 * Silver Xpress V4.01 --- Maximus/2 2.01wb 201434369420143436942014343694201434369420143436942014343694718 From: Jesus Rafael Lee Area: Public Key Encryption To: All 14 Sep 94 21:02:10 Subject: ftp site with keyring UpdReq From: jrlee@ztorrida.UUCP (Jesus Rafael Lee) In article <779454231@f403.n600.z6> Peter Tan writes: >> Isn't the site listed in the PGP DOCs?! Oh yah, just saw it, thanks. -- +----------------------------+ +-----------+ Jesus Rafael LEE PUAY YORK +----------+ | jrlee%ztorrida%linuxpub%csah.sg.com@jaring.my | | Jesus.Rafael.Lee@p1.f203.n600.z6.fidonet.org | | uunet!m2xenix!puddle!6!600!203.1!Jesus.Rafael.Lee | +---------------------------------------------------+ --- ifmail v.2.5 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Sep 94 07:27:44 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 public-keys or public-key signed messages that can be read by anyone with PGP 2.4+ and your public-key. Include your public-key when sending such messages in case the other end doesn't have it or make them aware of how to get it from your system. 5. This Echo may be traveling around the world so try to be concise. Avoid excessive quoting for one-liner responses. 6. Be aware that Echomail is NOT secure. Don't take anything at face value. 7. The posts in this Echo are the sole responsiblity of the poster. If you need verification, use Netmail. 8. The Moderators will deal with off-topic traffic. Don't respond for them. Links to this Echo will only be curtailed when absolutely necessary so please don't make it necessary. [grin] The Moderators are Christopher Baker [KeyID: 1024/F89A24F9 1994/05/18] and GK Pace [KeyID: 1024/EE38FB41 1994/05/14] at 1:374/14 and 1:374/26, respectively. It is Gated into Zone 2 by 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. Archived volumes of past traffic [P_ECHO1.ZIP - P_ECHO99.ZIP for example]. Files on this system are available anytime except 0100-0130 ET and Zone 1 ZMH at 1200-9600+ HST/V32 for FidoNet listed systems only. Request FILES for complete listings. This Echo is currently available on the Zone 1 Backbone. It has been EListed as of ELIST211. Please feel free to announce this Echo in all Nets and Networks. A companion Echo for the purpose of submitting public-keys only is now available as PKEY_DROP Echo. PKEY_DROP may be obtained via the same channels as PUBLIC_KEYS. NOTE: If you lose your secret-key password [or forget it] or your secret-key in a drive crash [because you failed to back it up on floppy], you cannot issue a revocation certificate. In that case, you should make a general announcement in all related Echos that your old key should be disabled using the PGP disable command [PGP -kd userid] for your userid. That keeps your useless key on their keyrings [so they won't be replaced from other lists who didn't get the word] and permits them to add a new key from you without one interfering with the other. Thanks. TTFN. Christopher Baker & GK Pace Moderators -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLngvo8sQPBL4miT5AQFXnwP/eIVF8kCeIcIokjMROjEickvpoNn4gYle zQ3+3gs7QC6hYW2rFo0LCKQ4kUypHtM54W1KOWnhOO0kPrUN54h/OeVo6LPUWvQr P6Cn4vNiHCIGVz/ccwzs+t4i4D8Jojpqao+yKi4q+wibk+n9cAPWd4/L3rLn4thz MXUOziLO5gg= =yMna -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Sep 94 07:28:38 Subject: PGP-related filename conventions UpdReq -----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.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLngv2csQPBL4miT5AQHhtgQAsc58AyaAfjtr4NSpLrTIqXQveU5ltuqh 9XkX731h8nZwGQeLHwpET06pc+zNHohkrkwxmO0croY5/xhr7E5Hl/1AwQGUPemR hmXiW3eZJqW6iohgPAzjhw5XCE9Ao4dl9EGG3V/L7H6oGje9MyutHLZrZKNwUQtK +IbD+Z5hD9g= =Ph0u -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Sep 94 07:29:34 Subject: SecureMail Routing system info UpdReq -----BEGIN PGP SIGNED MESSAGE----- The FidoNet (r) SecureMail System 30 Mar 94 Copyright (C) 1994 Jim Cannell [Source: GK Pace, 1993; Christopher Baker, 1994] Introduction: This document describes the SecureMail FidoNet (r) Routing System, its Statement of Purpose, and defines the principles by which it shall be operated. It should be noted that FidoNet is a registered trademark owned by Tom Jennings, used by permission to refer to the FidoNet, a hobbyist network of amateur, independent, interconnected systems (Nodes) providing E-Mail transfer services world-wide. Definition: SecureMail can be defined as a group of FidoNet Sysops who have volunteered to provide an alternative E-Mail routing service within the FidoNet Network. The SecureMail System is a component of the FidoNet Network. SecureMail is NOT an alternative, separate, or distinct network. Statement of Purpose: The primary purpose of Securemail, and reason for its creation is the desire for providing increased privacy in the routing of FidoNet E-Mail. The term privacy as used in the transfer of E-Mail is an arbitrary one. Absolute privacy cannot be expected. The degree of privacy obtained will always be related to the procedure(s), effort used to insure privacy, and should not be expected to be absolute if data is to be communicated from one place to another. Routing of E-Mail, as compared to sending it direct, cannot be expected to have as high of a degree of privacy as might be expected when sending it direct. Those who are engaged in operating the Securemail system do so with the primary goal of insuring that all E-Mail routed thru it be afforded the highest degree of privacy technically possible. Those using the Securemail System can expect to enjoy a higher degree of privacy than other forms of routing, but should not expect absolute privacy. Functional Description: The SecureMail System is a group of individual FidoNet Sysops who have volunteered to work together to provide the SecureMail Routing Service to FidoNet Sysops. This group is organized, but does not have authoritative positions. Each SecureMail Sysop is an independent volunteer furnishing a service. There are no monetary rewards, each Sysop contributes the resources he or she uses to provide the service, including all costs incurred in providing it. The operational structure may appear to have hierarchical order and indeed it does, however such structure implements a routing matrix, not positions of authority. The SecureMail operational philosophy can be described as cooperative autocracy. Each SecureMail Sysop is an independent operator who has volunteered to assume the various responsibilities required of an organized effort. No one is compelled to participate, but participation requires the performance of certain agreed upon functions, standards, and of course interaction as a group. Most of the activities parallel or are incidental to normal FidoNet activities. Routing Hierarchy: The basic routing strategy follows the normal FidoNet pattern of routing thru Zones, Regions, Nets, to Nodes. The difference is that SecureMail traffic is routed thru SecureMail Hosts rather than the FidoNet Hosts. A SecureMail Sysop serving in each position is referred to as a Host. There are functional (not Authoritative) positions such as Zone SecureMail Host (ZSMH) Region SecureMail Host (RSMH) and Net SecureMail Host (NSMH). An International SecureMail Host (ISMH) functions as a central coordinator for this functional hierarchy and maintains the routing lists and this document of intent and mission. Note that at any given time, all positions may not be filled, due to the fact that positions are filled by those who have the means and desire to provide the service of each position. Operational Practices: Each SecureMail Host (SMH) has agreed to route E-Mail (referred to as In-Transit mail) in a manner which provides the highest degree of privacy technically possible. Some variances can be expected, as the technical characteristics of each system differ, however each SecureMail Host strives to provide the best service possible. Specific operational practices include: - In-Transit mail shall not be read. Note that some systems do not provide the ability to restrict a Sysop from viewing In-Transit mail. In such cases the Sysop makes every effort to avoid noticing the content of such E-Mail as they scan thru their message bases. - The content of In-Transit mail shall not be disclosed, or given to anyone but the addressee, except as required for routing thru the SecureMail System. - All SecureMail Hosts agree to route any In-Transit mail they receive. This includes encrypted and clear-signed traffic now refused by some systems in FidoNet. In-Transit mail that cannot be delivered shall be returned to the sender along with a brief explanation of why it could not be delivered. If no local routing via another SMH is available, the mail will be sent directly to its destination by the receiving SMH. - In-Transit mail shall not be censored. Routing of In-Transit mail shall not be refused for any reason even remotely associated to the content of such E-Mail. Note: how could it be if it isn't read in the first place? Avoidance of Liability: Those participating in the SecureMail Routing System do so to provide a service at no cost to those who choose to make use of it. There is no guarantee of performance implied nor accepted by the SecureMail System as an organization, nor by the individuals who voluntarily participate to provide this service. Those who choose to make use of this service should recognize that although we strive to provide the best service possible, we cannot and will not offer any guarantees, nor do we accept any obligation for providing any service, or the performance of any service to a defined standard. Those who provide this service specifically deny any liability for the content of In-Transit E-Mail. Any liability that may apply must rest upon the originator. It is the stated practice of those who participate to provide this service, that In-Transit E-Mail is not read. On that basis, those who participate in the SecureMail Routing System will not have knowledge of the content of In-Transit E-Mail, will not censor, make judgements as to the legality, morality, nor suitability of any In-Transit E-Mail to be routed, before during or after having any contact with it. Those who participate in the SecureMail Routing System do so for the purpose of providing a service to others using the FidoNet E-Mail System. It is specifically denied that such service is supplied for the purpose of promoting, enhancement, implementation, or aiding the accomplishment of any illegal activity. No one participating in the SecureMail Routing System will knowingly allow its use to aid, abet, or otherwise participate in illegal activities, or make use of the SecureMail System for any illegal purpose. Further it is our stated operational practice that we shall not be engaged in viewing In-Transit E-Mail for the purposes of knowing whether or not the content of such could be considered illegal, and specifically deny that we could have any such knowledge. Those engaged in SecureMail Routing are constrained by the ECPA [Electronic Communication Protection Act] and FidoNet Policy in their ultimate handling of In-Transit E-Mail in regard to disclosure. Anyone who supports the goal of E-Mail privacy and who agrees to abide by the standards herein proclaimed, may apply to act as a SecureMail Host Routing System at their own expense and without regard to In-Transit E-Mail content. A list of current SMH Nodes is contained in the file SECUREML.MAP which accompanies this document. Applications may be made via direct Netmail to the ZSMH, RSMH, or NSMH closest to your area. International applications may be sent to the ISMH as listed in the map. 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.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLngwEcsQPBL4miT5AQHZswQAkAZqDnHGEhRpuLN6LfUJtBRFuZVD2fN9 1fhYpuLbvhKO6Yp0SrbtvbiTSO/2VZji8ln2u+xIf0Ztl73z0f8BhJ7o1yqBxCsw FzM5IPOEdQ4Jailjl7bP5RNojnfDcfn8VOarzGoCwpVM3k/xvKaFYE4qeSHhVE/2 wNyXM9vdD3w= =Ar1k -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Sep 94 07:31:24 Subject: SecureMail Routing system map UpdReq -----BEGIN PGP SIGNED MESSAGE----- SecureMail Host Systems Zone Sysop Address |--ISMH Jim Cannell 1:216/21 | | |--Z6SMH Open | |--Z5SMH Open | |--Z4SMH Open | |=================================================================== | |--Z1SMH Jim Cannell 1:216/21 | | RSMH Net Sysop Address Flag | |--- 10 Radi Shourbaji 1:143/110 X | | | SMH |-- 102 Dave Lord 1:102/338 | |-- 119 *none at present* | |-- 125 Barry Kapke 1:125/33 X | | |-- 352 John Burrows 1:352/333 X | | | |-- 143 Radi Shourbaji 1:143/110 X | |-- 161 Bill Faust 1:215/228 | | |-- 215 Joe Pye 1:215/25 | | | |-- 202 *none at present* | |-- 203 Lee Dohm 1:203/111 | |-- 205 Zorch Frezberg 1:205/1701 X | |-- 206 Dan Wilson 1:206/2507 X | |-- 207* Dave Sparks 1:207/212 | |-- 210 Steve Garcia 1:210/11 X | |-- 216 Jim Cannell 1:216/21 X | | |--- 11 Jeffrey Oxenreider 1:226/560 | | | |-- 120 Ryan Anderson 1:120/379 | |-- 226 Jeffrey Oxenreider 1:226/560 | |-- 2202 Ryan Anderson 1:120/379 | |-- 2240 Ryan Anderson 1:120/379 | |-- 2410 Ryan Anderson 1:120/379 | | |--- 12 Jesse David Hollington 1:225/1 X | | | SMH |-- 167 Frederic Giroux 1:167/535 | |-- 221 Paul Henry 1:221/279 X | |-- 225 Brett Dubroy 1:225/100 X | |-- 252 *none at present* | | |--- 13 Marc Stuart 1:2624/402 X | SMH | | |-- 107 Glen Pannicke 1:107/398 X | |-- 2613 Jack Mooney 1:2613/108 X | |-- 2624 Marc Stuart 1:2624/402 X | | |--- 14 Jason Buchanan 1:286/702 X | | | SMH |-- 285 Mike Riddle 1:285/27 X | |-- 286 Jason Buchanan 1:286/702 X | |-- 287 Danny Walters 1:287/507 X | |-- 291 *none at present* | |-- 296 *none at present* | | |--- 15 Dave Munhollon 1:128/86 X | | | SMH |-- 114 Allen Borovkoff 1:114/169 | |-- 128 Dave Munhollon 1:128/86 X | |-- 303 Thomas Lange 1:303/5 | |-- 314 Doug Preston 1:314/5 | | |--- 16 Todd Rourke 1:323/110 | | | |-- 323 Todd Rourke 1:323/110 | |-- 325 Frank Perricone 1:325/611 | | |--- 17 Ted Rolle 1:105/36 | | | SMH |-- 105 *none at present* | |-- 340 *none at present* | |-- 346 *none at present* | | | |--- 18 Christopher Baker 1:374/14 X | | [cbak.rights@opus.global.org] | | | |---- 3:800/857 Jackson Harding 3:800/857 X | | | |------- 285 Mike Riddle 1:285/27 X | | | SMH |-- 116 Vacant | |-- 123 Scott Miller 1:123/416 X | |-- 135 Tom Cropper 1:135/327 [Down] | |-- 135* David Bobo 1:135/110 | |-- 365 Chris Britton 1:365/200 X | |-- 366 Rob Buckman 1:366/844 X | |-- 374 GK Pace 1:374/26 X | |-- 375 Tom Jones 1:375/1 X | |-- 378 Sydney Marcus 1:378/10 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 | |-- 147 Bill Teasley 1:147/3660 X | |-- 170* Jim Watson 1:170/610 | |-- 382 Chuck Haynes 1:382/502 X | | |=================================================================== | | |--Z2SMH Harry Bush 2:51/2 | | | RSMH Net Sysop Address Flag | |--- 50 (Russia) Dmitry Kiselev 2:5026/3 | | | |-- 5022 Dmitry Turevsky 2:5022/8 | SMH |-- 5026 Dmitry Kiselev 2:5026/3 | | |--- 51 (Latvia) Egons Bush 2:5100/8 | | | SMH |-- 5100 Egons Bush 2:5100/8 | | |=================================================================== | |--Z3SMH Jackson Harding 3:800/857 | | RSMH Net Sysop Address Flag | |--- 51 Jackson Harding 3:800/857 | | | |-- 800 Jackson Harding 3:800/857 Note: Those nodes listed with an asterisk "*" are accepting SecureMail for their Nets, but do not currently route mail from their Nets thru SecureMail channels. SecureMail Hosts are identified by the following flags in the FidoNet Nodelist: ISMH - International SecureMail Host ZSMH - Zone SecureMail Host RSMH - Region Securemail Host NSMH - Net Securemail Host SMH - SecureMail participating Node [these flags may or may not be preceded by a U in the Nodelist.] SecureMail Hosts are requested to ask their Local Coordinator for the appropriate UserFlag for their primary Node number. Those currently flying the ?SMH flag in the nodelist are show with an X by their node number. Complete information on the FidoNet SecureMail Host routing system is available by file-request or first-time download as SECUREML.ZIP from the ISMH or any of the RSMH systems. -30- TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLngwfssQPBL4miT5AQFHNgQAvMELw9IGHyseRXHo+wQVkSXgcNE5tIrV w73oDpB5aloceO7tp0IAp/c0bq2jHlIMpt5YbGBa/plQWRfEiNRdz3z6HqHbQk6T RsB1eibk8JC7TE6sTGiNi0Zz2JWCR/uStt/45Vk7uvDp0BxxJRARhSqE8vvi4RNV torO5H7DGXo= =xjQy -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: All 16 Sep 94 16:22:46 Subject: Need recommendations UpdReq Well, it's finally happened; my cryptography hobby is going to pay me a little money. A client needs to secure a computer against intrusion from a computer-knowledgable (but not encryption-knowledgable) attacker with hours of uncontrolled physical access time. Only certain data needs to be protected, and the attacker is more computer-knowledgable than the user of that computer. My instinct is to use SFS (no need to mess with SecureDrive, since there's no need to protect this information from the NSA) to encrypt the drive upon which the data is stored, since the client has a second hard drive dedicated to output from the program in question and has no problem with paying the $25 license fee. Secondary security will be a CMOS password, which will of course just slow the intruder down while he hunts for a screwdriver. Anybody got any other recommendations? 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Brad Stiles 16 Sep 94 16:31:46 Subject: New to PGP UpdReq Despite the stern warnings of the tribal elders, Brad Stiles said this to Shawn McMahon: BS> Does he have an e-mail address? [asked in re: Mike Godwin] I seem to have misplaced it, but I believe it's mnemonic@eff.org. 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Bert Byfield 16 Sep 94 16:49:40 Subject: Re: Signing My Own Key. UpdReq Despite the stern warnings of the tribal elders, Bert Byfield said this to John Schofield: BB> yet. But I have a question. Has ANYONE made a serious attempt BB> to crack PGP? Anyone who would tell us the result, I mean. If I BB> was an executive at the NSA, it would be high on my pert chart. Lots. And if you broaden the question to "has anyone (who would tell us the result) made an attempt to crack any of the algorithms used in PGP" the answer is "yes, everybody." The whole cryptographic community worldwide has had access to these algorithms since their invention. IDEA is the least-tested portion, and even it has had quite a bit of attack. It's not "proven" by any means, but it DOES withstand the same attacks that other popular algorithms fail. Does this mean the NSA can't have cracked it? No, it doesn't. However, understand something; the considered opinion of a whole bunch of cryptographers is that cracking it will require a breakthrough in the factoring of really really large numbers. Said breakthrough is one of the Holy Grails of mathematics. The entire world mathematical community is looking for the solution to that problem, and isn't finding it. The odds are in our favor. Especially if you consider that any such breakthrough would render all alternative encryption methods weak as well, meaning you don't have a better alternative. Unless the entire world community of publishing cryptographers is barking up the wrong tree. Which is, of course, possible. There are very few of them who wouldn't admit that the very best in the US are working for the NSA. 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Tim Bradley 17 Sep 94 02:08:28 Subject: RSA Broken UpdReq Despite the stern warnings of the tribal elders, Tim Bradley said this to jim bell: TB> subset containing a high number of redundant zeroes. Odds TB> against a key from that subset in an ACTUAL *PGP* key are TB> quite low, Very low; in fact, any that exist were probably created on purpose. The weak point in PGP remains the MD5 algorithm, which doesn't meet one of it's design goals. (It has collisions.) However, nobody's yet proven (that I know of) that this failing can be exploited in a fashion that is faster than brute-force search of the keyspace. However, I don't follow the technical journals, so if I'm wrong hopefully someone who does will jump in now. 201434369420143436942014343694201434369420143436942014343694718 From: Phillip Barker Area: Public Key Encryption To: Jim Bell 14 Sep 94 12:07:00 Subject: Please respond... UpdReq Hello, Jim...yr making it to Southern Oregon...Cheers!...Phil * SLMR 2.1 * Will you come quietly, or shall I use earplugs? 201434369420143436942014343694201434369420143436942014343694718 From: Shawn K. Quinn Area: Public Key Encryption To: Shawn McMahon 12 Sep 94 00:00:00 Subject: Changes In PGP 2.6.1 UpdReq -----BEGIN PGP SIGNED MESSAGE----- *** Quote: Shawn McMahon to Kevin Lo on 09 Sep 94 14:14:33 *** Subject: Changes In PGP 2.6.1 SM> 1024 is secure enough to give you years to change; 2048 is believed to SM> be secure enough that you'll never want to change again. I suggest about 1250-1300 (1280?) as a realistic length for long-term security. It should give the average 6th grader enough time to not worry about making a new key until after he/she gets out of college. SKQ -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLnPgSDzG+cClnFb5AQE6pQP/d6ajD6UiCDacYcBgolYpL/UU2vD66FH4 4yYSCoEHcYVWLfZA8xBq1Dy8Bqa+msgzJCQAgkQ0Nx8vW656iXiYCXEbqSYFwLd3 4bnnBGAh/x8DAZmSgx+KUnkeaiFPo67VtmgV7hL0zVdjA+DV25rvjbjqvbbxUJiY aiIBbO2kr50= =Czo7 -----END PGP SIGNATURE----- ... 9 outta 10 men who have tried Camels prefer women 201434369420143436942014343694201434369420143436942014343694718 From: Shawn K. Quinn Area: Public Key Encryption To: Richard Walker 12 Sep 94 00:03:42 Subject: Re: New to PGP UpdReq -----BEGIN PGP SIGNED MESSAGE----- *** Quote: Richard Walker to jason carr on 11 Sep 94 11:25:24 *** Subject: Re: New to PGP JC> An inspector who opens/reads/jacks with your 1st class letter without a JC> warrant is going down... RW> If yall truly believe that, you are more nieve than I thought. OK, apply as a postal inspector, and open/read/jack with a letter without a warrant. See you in the pen... :-) SKQ -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLnPhJzzG+cClnFb5AQGNsQP+Le3bkDiP6pUoMkHnGdB8nfNzPVTGdZKt erpQq6dAZQX+xYxP6DIJlFtj9U68/I3zhPXIClvBXJAoEPSjg6t96YO3CG1XEtbN brKnLiappJ0YZ0YEdQn7CAilu7H25Gvp9uZpmzUWUG8zYKOG/m7PvyBxmVPeyORH cuv/izVo6xI= =yaSY -----END PGP SIGNATURE----- ... Security, confine Ensign Walker to the brig. 201434369420143436942014343694201434369420143436942014343694718 From: Thomas Hughes Area: Public Key Encryption To: pgp authors 16 Sep 94 04:05:46 Subject: 2.6.1 vs. 2.6ac UpdReq {-- actual dull unretouched snapshot(s) of the screen --} | (C:\Z\9) 4:27 | $pgpac -kv mwe | Pretty Good Privacy(tm) 2.6a - Public-key encryption for the masses. | (c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. | FreedomWare compiled by the Rebellious Guerrilla. [MIT - RSAREF] | EXPORT OF THIS SOFTWARE MAY BE RESTRICTED BY THE U.S. GOVERNMENT. | Compiled Aug 26 1994. Current time: 1994/09/16 10:27 GMT || Key ring: 'c:\z\d\pgp\pubring.pgp', looking for user ID "mwe". | Type bits/keyID Date User ID | pub 1515/CFCC1745 1994/09/15 tfh (1:130/908.2) | pub 1999/E4B56259 1994/09/15 tfh (1:130/908.2) | pub 1024/98CBE9BD 1994/07/17 tfh (1:130/908.2) | pub 1264/61D40719 1993/11/04 MWE | 4 matching keys found. ||| (C:\Z\9) 4:27 | $pgp -kv mwe | Pretty Good Privacy(tm) 2.6.1 - Public-key encryption for the masses. | (c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. 29 Aug 94 | Distributed by the Massachusetts Institute of Technology. Uses RSAREF. | Export of this software may be restricted by the U.S. government. | Current time: 1994/09/16 10:28 GMT || Key ring: 'c:\z\d\pgp\pubring.pgp', looking for user ID "mwe". | Type bits/keyID Date User ID | pub? 0/00000000 tfh (1:130/908.2) | pub? 0/00000000 tfh (1:130/908.2) | pub 1024/98CBE9BD 1994/07/17 tfh (1:130/908.2) | pub 1264/61D40719 1993/11/04 MWE | 4 matching keys found. {--} v2.6.1 will also not "add" in any keys that are over 1264bits. (and [surprise] it won't "work with" any of those "pub? 0/0*" keys.) a "changes" file with v2.6.1 claims that it will not generate, but never-the-less will "support" keys up to 2048bits in size. i've tried it under SunOs4*, Ultrix, and Linux with the exact same results. did MIT lie to me, or should we expect a big-bug-fix-release shortly? (should i just think of v2.6ac as the bugfix?) (net-dist.Guerrilla.org has the source code?? [for a *NIX version]) has anyone gotten v2.6.1 to work with >1264bit keys? 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: Carl Hudkins 15 Sep 94 15:28:36 Subject: Intermail mangling... UpdReq -----BEGIN PGP SIGNED MESSAGE----- --== CB> "Badly formed Armor checksum" is what is reported here on your mangled CB> signature block. CH> Thank you for confirming that outgoing stuff is also CH> being pureed. :) I won't bother signing any of my posts here until CH> we get this fixed. CH> Any InterMail experts out there???? Send mail to Anthony I run Intermail, and nothing on my messages is getting mangled (that anyone has reported). It's probably your BBS software or your tosser. My messages go from: Bluewave Off-Line Mail-reader with EZ-PGP --> Bluewave Remote Access mail door --> Gecho 1.02+ tosser --> Intermail 2.29 --> my hub Let me know if I can help with anything. JMS ... I thought about being born again, but Mum said no. -----BEGIN PGP SIGNATURE----- Version: 2.7 iQCVAwUBLnjEDWj9fvT+ukJdAQG3YAP/RmdFim84meiK8YsApb6LI6IbeYX9zmcC 5Xi9pkitOTYzEeIcGmV7WfMg1MfKydMnN+b3xsJ9lf83PAZ6tPWF09xCHIX9GDo2 hjVl58gz3/aBj+maBoKDJlQ4EHfUHrwIQBf0408PdRzTq/AOZn9tqYcnqdTMCPJd uwTi78Lhkwc= =g6Ug -----END PGP SIGNATURE----- **EZ-PGP v1.07 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: Bert Byfield 15 Sep 94 15:28:38 Subject: Re: Signing My Own Key. UpdReq --=== BB> I'm confused, too. I know some cryptography, but I'm still back BB> in the ACA mindset, not having upgraded to kilobit key thinking BB> yet. But I have a question. Has ANYONE made a serious attempt BB> to crack PGP? Anyone who would tell us the result, I mean. If I BB> was an executive at the NSA, it would be high on my pert chart. A concerted effort was made to crack a message sent using the algorithm that PGP uses, RSA. This message was about 450 (roughly) bits, and was cracked in 6 months using 600 computers. The effort was coordinated over the Internet. Note that this effort was to crack ONE message. An equivilant effort would be required to crack another. Current PGP keys are 1024 bits. The consensus is that 512-bit keys will be cracked before year 2000, but 1024-bit keys are safe for the forseeable future. JMS ... TECHNICALITY: Someone *ELSES* Constitutional rights... 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: All 15 Sep 94 23:41:58 Subject: Keep Out electronic release UpdReq -----BEGIN PGP SIGNED MESSAGE----- Keep Out--The Journal of Electronic Privacy Information on electronic privacy is too important to limit it to those who can afford a subscription to Keep Out. The first issue of Keep Out, released August 1, is now available electronically. The first issue of Keep Out focused on encryption, with a lengthy interview with Philip Zimmermann, author of the Pretty Good Privacy (PGP) data encryption program, a beginner's introduction to PGP, and a review of PGP to off-line mail-reader shells. Because the electronic version of Keep Out contains the same commercial advertisements that the paper version does, it will not be posted to this area. However, anyone may get this issue, simply by sending e-mail to "KEEP-OUT-CURRENT@EXPRESSNET.ORG." You will receive, in ASCII-text format, the full text of Volume 1, Issue 1 of Keep Out. The current issue of Keep Out will always be available at this address. There is also a moderated Keep Out mailing list, where discussion about Keep Out and future issues, will be distributed. To subscribe, send mail to "LISTSERV@EXPRESSNET.ORG," with a line of "SUBSCRIBE KEEP-OUT" in your message body. If you wish to get this issue of Keep Out through Fidonet file request, you can FREQ "VOL1-NO1.TXT" from 1:102/903 (14.4k) or 1:102/904 (28.8k). Future issues of Keep Out will follow this naming convention. If you would rather download Keep Out from our BBS, you can call the Sprawl at (818) 342-5127. The magazine is a free download, available on the first call. The electronic version of Keep Out may be freely distributed, and in fact, I would appreciate hearing about any FTP sites or dial-up BBS's that carry it. If you have any questions, you can also reach us through the Internet at ac086@lafn.org, or through Fidonet at "Keep Out" at 1:102/903.0. To speak with someone at Keep Out voice, call (818) 345-8640. Thanks very much for your time. John Schofield Publisher, Keep Out SysOp, the Sprawl -----BEGIN PGP SIGNATURE----- Version: 2.7 iQCVAwUBLnjzKmj9fvT+ukJdAQHEyAP9HXthL0BWWxoxndef5xvqHKdHrlU54pUv uG16UWR80HHqtH6+mz5pJ8JgRrI9bjoGvBB7uwO7iaIPQhxq8vwril+yrsWmyRAV gn3ucGhwwwhldaXlMQ1GWdoXq3lHxS2L35bdhkXtSDFKXbDouObFOE8s/kEwRMsv Xow13IT4zX0= =i8LW -----END PGP SIGNATURE----- ... Call 818-345-8640 for info on Keep Out, the Electronic Privacy Journal 201434369420143436942014343694201434369420143436942014343694718 From: Shawn K. Quinn Area: Public Key Encryption To: Jeff Hancock 15 Sep 94 23:06:54 Subject: There goes more freedom! UpdReq -----BEGIN PGP SIGNED MESSAGE----- *** Quote: Jeff Hancock to *.* on 12 Sep 94 23:11:47 *** Subject: There goes more freedom! JH> The practice portion of the examination is likely to be the most JH> controversial. Reportedly, all candidates must pass a typing skills JH> examination and achieve no less than 40 words per minute to obtain a JH> (temporary) novice license. This must be raised to 80 words per JH> minute before a regular-status license will be issued. Novices will JH> restricted to operating networked computers having speeds of less JH> than 5 Mhz or operation of SLIP or dial-up connections of no greater JH> than 2400 baud. (It is rumored that the FCC will make 5 Mhz JH> replacement crystals available at a nominal charge to temporarily slow JH> computers of novice operators). Gee, too bad. This great country lasted 218 years, almost all of those with the same constitution. :-> You can't do jack with a 5 MHz computer or 2400 bps modem. What, do they think a modem is a lethal weapon or something?! I can't type 80 words per minute. The best I've done on a typing test is in the high 50's. I can tell you this right now: I will *NOT* slow my computer or my modem to get on Internet. JH> The FCC also recognizes that there are conditions when terminal JH> emulators are not available. Therefore, an expert class will be JH> established for communication using only numeric keypads and bi-digit JH> numeric displays. Although needing a minimum of equipment, this mode JH> will require sending, receiving and manual translation of raw ASCII JH> codes. Guidelines for minimum communication rates for this mode have JH> yet to be established while the FCC awaits public input. Although JH> felt to be a desirable goal for all users, this class of license will JH> only be required by individuals operating wireless (RF) LANS. This is the most RIDICULOUS thing I have EVER HEARD! What the heck do they think this is? The UNIVAC days? JH> Asked what the effect of proposed regulations would have on the JH> Internet, a highly placed official noted that these rules "should not JH> be considered prohibitive, as they simply bring regulation of the JH> Internet in line with other communication modes under FCC JH> governance." However, the source did feel that such regulations should JH> be very helpful in restraining the rapid growth of the Internet. Oh yeah, they will accomplish that goal very well. They will bring the Internet to a SCREECHING HALT and effectively step us BACKWARD by a decade or better! JH> Now we must all understand that as with all government procedures any JH> resulting regulations will be 'for our good'. Yeah, right. I think we need to send whatever BEANHEAD wrote this a very strong message! (At 28800 bps on a Pentium-90 at that!) SKQ -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLnkZ1jzG+cClnFb5AQH0EQP/Zm9Gbe2x+WLvWmjldKYlmGLE7tnR/vTP G5l3kDfPdijMSct3PbN2GWteq8yU3RuJesICPLGWKzj9deQvmQvQc6DStoEUqLwC qYOKsYi96USqaQBWqYIkrKjLIRlzBLB85DFylyb2cOJb73a96YC7O5L93Cy5HyWL Ki+qjhVG8x8= =hA6/ -----END PGP SIGNATURE----- ... FCC - F**ked-up Computer Curmudgeons 201434369420143436942014343694201434369420143436942014343694718 From: Peter Bradie Area: Public Key Encryption To: Alan Boritz 15 Sep 94 16:21:00 Subject: New indecency rules propo UpdReq -=> Quoting Alan Boritz to All <=- AB> The Exon amendment which is now part of S.1822, expands section AB> of the Communications Act to cover anyone who "makes, transmits, or AB> otherwise makes available" obscene or indecent communication. AB> If enacted into law, these amendments would require that anyone AB> who "makes, transmits, or otherwise makes available" indecent AB> communication take prescribed steps to assure that minors are AB> prevented from having access to these communications. AB> These provisions raise serious First Amendment concerns. AB> Overbroad carrier liability forces carriers to stifle the free AB> flow of information on their systems and to act as private censors AB> If carriers are responsible for the content of all information AB> and communication on their systems, then they will be forced to AB> attempt to screen all content before it is allowed to enter the AB> system. In many cases, this would be simply impossible. It appears you are making a straw man. While it is true that an obscene or indecent communication could be buried in an echo devoted to encryption, such as we have here, the likelihood of 1) it happening, 2) being accessed by a minor, and 3) it being reported to the authorities are slim to none. The "obscene or indecent" communications are typically routed to O/I areas; it then becomes relatively easy for the sysop to ensure that those areas are off limits to minors. AB> Carriers are often legally prohibited from screening messages. AB> In fact, under the Electronic Communications Privacy Act of AB> 1986, electronic communication service providers are generally AB> prohibited from examining the contents of messages or information AB> carrier from one subscriber to another. 'Tain't so, McGee! The ECPA prohibits the divulging of material that is 'not readily accessible to the general public' to a third party. If the material is public in an echo, it can be read and divulged. If flagged "private" to a particular recipient, it may be screened by the sysop but not divulged to others. If the private message is O/I, then the ECPA bars authorities from picking up on the message without court orders. AB> In sum, it should be content originators, not carriers, who are AB> responsible for their content. Any other approach will stifle the AB> free flow of information in the new digital media. The content originators should be held liable for what they send to the carrier. But unless you're strictly a conduit and no more, then you as a carrier have to bear responsibility for what you carry. I seriously doubt that any BBS contains obscene GIFs without the sysop being fully aware of them. I also seriously doubt that holding a carrier liable for private, obscene E-mail would pass scrutiny under constitutional or statutory law. ... Law is common sense... but very, very refined. ... Blue Wave/QWK v2.10 201434369420143436942014343694201434369420143436942014343694718 From: Richard Walker Area: Public Key Encryption To: Shawn K. Quinn 16 Sep 94 08:31:26 Subject: Re: New to PGP UpdReq JC>> An inspector who opens/reads/jacks with your 1st class letter JC>> without a warrant is going down... RW>> If yall truly believe that, you are more nieve than I thought. SK> OK, apply as a postal inspector, and open/read/jack with a letter SK> without a warrant. See you in the pen... Amazing that you trust big brother so much... Besides, I already have a job, and it pays more than the post office. SK> ... Security, confine Ensign Walker to the brig. I'm not the one who's got a criminal record... Yours truly Richard Walker 201434369420143436942014343694201434369420143436942014343694718 From: Tim Bradley Area: Public Key Encryption To: Jeff Hancock 16 Sep 94 02:17:18 Subject: There goes more freedom! UpdReq In a message of 12 Sep 94 Jeff Hancock wrote to *.*: JH> (UPI) WASHINGTON, DC. The White House confirmed today that the FCC... JH> [...] {Stuff Deleted for Brevity...} JH> Now we must all understand that as with all government procedures any JH> resulting regulations will be 'for our good'. Jeff -- If you (or anyone else) could come up with the names of whoever will be involved in drawing up these requirements, I would REALLY appreciate it. I think that this would be a very good issue to get an INFORMED campaign going on: And I also think that going off half-cocked would be the WORST way for those of who USE the Infobahn to react: reliable source or not, too much of the restrictions mentioned seem to be drawn DIRECTLY from out-of-date Ham requirements: and the FCC has shown an amazing amount of awareness of modern digital communication for a government agency. F'r instance, Packet Radio [digital data transmission] operation is possible with just a technician's license, which requires no Morse Code or typing proficiency at all, and just enough technical expertise to avoid screwing up your neighbor's TV reception -- I can't see ANY reason that moniterable TELEPHONE Data Communication would be MORE restricted by the SAME agency. On the other hand, far be it from me to imply that our government makes sense ... so I'd like to hear more specific info from anyone who HAS some. As the virtual death of the Clipper has shown, calm, well reasoned appeal to economic practicality is able to preserve freedom in the face of rampant government control mongering. This could very well be another case where that's needed, but we need to react REASONABLY, or all that will happen is that we CONFIRM the idea that a bunch of rabid anarchists hold the nation's data hostage . Later Daze, -- Tim Bradley 201434369420143436942014343694201434369420143436942014343694718 From: Tim Bradley Area: Public Key Encryption To: Oliver McDonald 16 Sep 94 02:33:46 Subject: New to PGP UpdReq In a message of 14 Sep 94 Oliver McDonald wrote to Shawn McMahon: OM> It does depend somewhat upon which legal jurisdiction one resides in. OM> According to my resident net legal expert, the policy of examining mail OM> that passes through your system for legalality would probably stablish OM> mensrea in Canada. This would mean, in all likelyhood, that a OM> conviction could be obtained if you allowed unlawfull material to pass OM> through your system in the form of routed netmail. If however you OM> never see, let alone inspect, the routed netmail, you are unlikley to OM> be charged, let alone convicted. Of course this is in Canada, YMMV in OM> the US or other countries. It's true in the US as well -- we just have some folks here who don't pay too close attention to anything BUT the ECPA. FCC Regulations dealing with Packet transmissions of illegal materials have covered this for years. Now, admittedly, Federal *LAW* supercedes FCC Regs, but in most cases where a Federal Law is open to interpretation and a Federal Regulation COVERS that interpretation, the Judge follows precedent. But BOTH sides in the encryption controversy are hung up on whether a Sysop *HAS* to carry encrypted mail or is ALLOWED to read/bounce mail -- I suppose it's an attitude thing . Most fail utterly to realize that whether or not a a Sysop HAS to carry encrypted mail, he's actually *LESS* legally liable if he does. When I finally get around to running a BBS, I'm going to use one of the several that PREVENTS the Sysop from reading Private Mail, for just that reason: If I COULDN'T know what was there, I'm less likely to be busted for it. Of course, if someone DOES get busted using my board, I'll also fully cooperate with the police as well, just on the general principle that someone who'd risk MY stuff without telling me about it certainly doesn't deserve any consideration he didn't give. OM> A final point, is that should the government want to take you down as a OM> BBS operator, they don't need a conviction that will through you in OM> jail, all they need to do is make it to expensive in legal defence costs OM> to continue to run the BBS. No doubt! That's what too many of the people arguing about this ALSO seem to miss -- liability is basically irrelevent as long as you take minimal precautions: If they want you, they'll get you, no matter HOW well you cover your rear. And if they DON'T want you, most of the more draconian security measures aren't necessary. Some people just like ulcers I suppose... Later Daze, -- Tim Bradley 201434369420143436942014343694201434369420143436942014343694718 From: Jim Warren Area: Public Key Encryption To: All 15 Sep 94 22:59:58 Subject: armored & zipped UNencrypted UpdReq I don't see this in the PGP documentation but I may just have missed it: PGP -a SOURCE.EXE makes UN compressed UN encrypted files totaling MORE bytes than SOURCE.EXE which requires no password or keyring files to restore. This is ALMOST what I want. SOURCE.EXE is restored neatly with a simple "PGP SOURCE.AS1". PGP -ae SOURCE.EXE receiver -u sender makes compressed encrypted files totaling FEWER bytes than SOURCE.EXE but requires a password and key ring files to restore at receiving end. Is there a command to make COMPRESSED armored files totaling fewer bytes than the source file and that doesn't require a password and key ring files to restore at receiving end? Yes, I know I could START with a compressed source file but that adds extra steps at BOTH ends. ... 15 Sep 94,Jim Warren,PO Box 284,San Lorenzo CA 94580,USA 201434369420143436942014343694201434369420143436942014343694718