From: Scott Miller Area: Public Key Encryption To: Richard Dale 15 Jan 95 12:19:00 Subject: Problem generating keys UpdReq I figured it out, thanks. The signing problem just cured itself for some reason. [shrug] ------------------------------------ Scott PGP v2.6.2 key available FREQ PGPKEY ------------------------------------ KeyID: 4CA7DD5D and 201434369420143436942014343694201434369420143436942014343694718 From: Scott Miller Area: Public Key Encryption To: Wes Perkhiser 15 Jan 95 21:23:00 Subject: Problem generating keys UpdReq No, it seems to have fixed itself. Isolated incident. Scott Miller 201434369420143436942014343694201434369420143436942014343694718 From: Rich Veraa Area: Public Key Encryption To: Gordon Campbell 13 Jan 95 08:14:02 Subject: Can I Freq Pgp? UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message to Ian Hebert, Gordon Campbell wrote: IH> Technically, citizens of both the U.S. and Canada are subject to ITAR, IH> and therefore both may legally obtain PGP 2.6.2. I would urge IH> Canadians, though, to use PGP 2.6.i. 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. Are you sure that's still true? I thought there was something in NAFTA about Canada adopting a whole bunch of US laws, including ITAR. (just asking; I don't know for sure) Cheers, Rich -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: rveraa@907.sunshine.com iQCVAwUBLxZTUJ80iJ+tnwVVAQEBygQAnsJLegqY2NicmELkDlpOYuY3h2/InGDW JqeRRF5xb9U0Rd6zVHeL5rh/Xgr31OBt2lyb1ViAgkZyRKql1uCZE9EGC4yFAmNS UKmQ0feTEeE0EHCsDhzNWHZ12GL7WfTujBBFS+CNJ1bzmDSzZkFth6nl3zCr0Xwp qEkNJzx9s5I= =1onj -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Brian Giroux Area: Public Key Encryption To: Jason Carr 15 Jan 95 20:35:00 Subject: KEY REVOKE UpdReq JASON CARR pounded out random words to BRIAN GIROUX, and it looked something like this: JC>That's why almost =everybody= messes up at first. It takes more >attention than we're used to giving to new aps. Actually, I read the manual in great detail before I even unziped the archive. But I set it aside for a few months, and when I got back to it, my memory was foggy. BG> There were no explanations as to why the step was BG> important, so I just skipped the stuff that looked to weird BG> to me. JC>Heh heh. Maybe that's not the =best= method. :) It seemed like a very good method, it just wasn't commented very well. JC>re-add it. Let's try. In the next msg I'll quote your key back to you, >and you can try to re-add it. No need to quote my key back to me. I extracted it to a text file last November and it's still sitting on my HD in ASCII format. I just havn't got the guts to try to add it to my public key. Brian Giroux True-Tech Computer Supplies * 1st 1.11 #1757 * WRE00004 Autodesk Home Series:Landscape v2.0 Cdn$65.00 201434369420143436942014343694201434369420143436942014343694718 From: Jeff Trowbridge Area: Public Key Encryption To: Aaron Goldblatt 16 Jan 95 19:56:44 Subject: pgp problems UpdReq -----BEGIN PGP SIGNED MESSAGE----- JT>> response, save it, back to Ppoint, open the editor again, but when I run JT>> pgp -sat response.asc I get a completly encrypted message. JT>> Does anyone know why it does this? AG>It's likely that your message text file contains ^a kludge lines, or high-ASCII >characters. PGP sees these and assumes a binary file, even if you specify >plaintext. Since you specified ASCII armouring, it did ... the entire thing, >rendering the message useless ... >The only way around this is to be sure that your message doesn't have high >ASCII in it. >D'Artagnon Thanks Aaron, If I did it right, This will come through with just a pgp sig on it. TTYL, Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLxs/82RY5iFpzdvJAQF9sgIAgxpmdMONQutvuSj+R4fzvJ8ZZ3Xc/H5k 0wZlz9KKEp94xRV4T7X4crVTsnwHW51wwlmdAFICUBb1QmCTG1yn0g== =WBVj -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Michael Mcbroom Area: Public Key Encryption To: John Schofield 16 Jan 95 10:57:00 Subject: Electronic Privacy BBS Li UpdReq Hi John, JS>Since this is an electronic privacy BBS list, you may want to say a little b JS>more about what you offer the caller interested in electronic privacy. In a JS>case, you have been added to the list. The next list should be released in JS>February. Thanks very much for your help! You're welcome, and thanks for adding me to the list. Actually, other than offering PGP for d/l on my board and carrying the FIDO conferences, there isn't much else. I would, however, like to learn more about it, and would like to offer any increased exposure I can to my users. I thought this may be a good way to help out in that regard. Mike * OLX 2.1 TD * "Imagination is more important than knowledge"- Einstein 201434369420143436942014343694201434369420143436942014343694718 From: Jim Grubs, W8GRT Area: Public Key Encryption To: All 16 Jan 95 19:14:02 Subject: International public keyring UpdReq * Forwarded from "PKEY_DROP" * Originally by Jim Grubs, W8GRT, 1:234/1@fidonet * Originally to All * Originally dated 15 Jan 1995, 20:37 Now that I'm again reachable for f'req, you can get the informatik.uni- hamburg.de server keyring by requesting "keyring". Make sure you really want it because it's virtually 3 megs now. Also, if you want alt.security.pgp, sci.crypt, or the cypherpunks mailing list as echomail, let me know. Sincerely, Jim Grubs, W8GRT 201434369420143436942014343694201434369420143436942014343694718 From: Aaron Goldblatt Area: Public Key Encryption To: Jeff Trowbridge 18 Jan 95 12:26:34 Subject: pgp problems UpdReq JT> If I did it right, This will come through with just a pgp sig JT> on it. It had the sig, but I couldn't check it because I don't have your public key. D'Artagnon ... Thoroughly have we seen a person fail who has rarely followed our path. --- GoldED v2.50.B1016+/1111 201434369420143436942014343694201434369420143436942014343694718 From: Jim Bell Area: Public Key Encryption To: Lawrence Garvin 18 Jan 95 14:05:00 Subject: CAN I FREQ PGP? UpdReq -=> Quoting Lawrence Garvin to Jim Bell <=- JB> See the problem? The people who try to argue that putting JB> PGP on a BBS, which then is called from outside the country, JB> results in a violation of the laws chargeable to the BBS JB> operator, are arguing a very selective and opportunistic JB> interpretation of the law. LG> SCO (makers of fine Xenix and Unix products) have restricted the LG> distribution of the Unix 'crypt' command since the product's inception. LG> Along with the documentation comes a statement which reads as follows: LG> "The crypt(C) command is not distributed with the XENIX (UNIX) System LG> V Operating System. If you want the crypt(C) utility and associated LG> crypt(S) libraries, and you live in the United States, contact the LG> support center listed on the support information card included with the LG> software." LG> Now.. why do you suppose they handled the situation like that? My LG> presumption is that it's the -only- way that SCO (as the original, and LG> primary, distributor) can insure that the controlled applications are LG> only distributed to -authorized- end users. But I presume that even this precaution will not, absolutely prevent the subsequent diversion of the software. LG> And since the end user cannot 'transfer' their XENIX (UNIX) software LG> license to another person without SCO's knowledge, the subsequent LG> 'distribution' of the crypt(C) command or crypt(S) libararies is a LG> violation of the SCO license, and itself subject to court action. Yes, but that doesn't mean that SCO will ACTUALLY sue for this violation; merely that they COULD do so. LG> Likewise, unless a BBS operator can guarantee that they are LG> controlling the distribution of materials classified by the government LG> as munitions (regardless of whether we or anybody agrees with the LG> classification), they are subjecting themselves to the risk of being a LG> party to the distribution. But the same argument applies to somebody who sells (or gives away) copies of PGP on floppy at their local computer club meetings! See, if you have any inclination to apply DIFFERENT standards to BBS's as you would to physical distribution, on (for example) floppies, I recommend that you reconsider your position. I don't think there's any logical basis for such a distinction. I don't even think there's a LEGAL distinction here, based on black-letter law and/or regulations. ... Way Too Much is Not Nearly Enough. ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Bill Lambdin Area: Public Key Encryption To: Bill Katcher-jr. 18 Jan 95 06:23:10 Subject: Verifying PGP Keys UpdReq BILL KATCHER-JR. To ALL about Verifying PGP Keys on 01-16-95 BK> decrypting stuff, and a few other things. My main concern is what i BK> way of verifying someone's public PGP key. If it's posted on FidoNe BK> possibly be a phony key, and even if it's signed by other people, wh It could be a phony. The best way to check the key is to look doe signatures on the public key. There are lots of signatures on my key. Bill 9CCD47F3C765CA33 bill.lambdin@woodybbs.com C77D698B260CF808 <-PGP fingerprint codes --- * CMPQwk 1.4 #1255 * CASPER activates Apr 1st 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Brian Giroux 18 Jan 95 08:39:16 Subject: KEY REVOKE UpdReq -----BEGIN PGP SIGNED MESSAGE----- Brian Giroux wrote in a message to Jason Carr: BG> No need to quote my key back to me. I extracted it to a BG> text file last November and it's still sitting on my HD in BG> ASCII format. I just havn't got the guts to try to add it BG> to my public key. Can't possibly =hurt= anything to try to re-add. Just pull out the revoked key and re-add the November key. I'm really curious to see if it will work. I think it will. jason ... Boy cries wolf. Has a few laughs. I forget how it ends. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP_ECHO: CypherEcho to the gods... iQCVAwUBLx1Ei0jhGzlN9lCZAQFXZQP+IYHym9o1lvyY8JqQeLZUhxefGry02KWk rtGRVpVIYa6RrZ3lc3LEOWkOmCei/p/lk/ts16016GB0edKXR07HoAQ6MDs1quNl BbHF90+yOxoMPP8TL5PJsQ3TFy3TA/AcycggqeYIHzDjYhCR5oK/oIsi3OijMZGM pZKbKo1bX2E= =L07d -----END PGP SIGNATURE----- ... Key fingerprint = 60 97 B2 AE 7D 90 11 2F 05 1C 35 98 E9 B9 83 61 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: mark lewis 18 Jan 95 08:45:06 Subject: KEY REVOKE UpdReq -----BEGIN PGP SIGNED MESSAGE----- mark lewis wrote in a message to jason carr: ml> the secret key is the local only key that no one else is ml> ever supposed to get hold of... I know. ml> that's only the public key... it's no good without the ml> secret key... they are a matched pair... OK, let's try it this way. Here are the steps involved in properly revoking a key and storing the revocation off the pubkey. I will use GOODKEY for the pub key we want to revoke and re-add, and REVKEY for the revocation we want to have handy. 1) Extract GOODKEY to a file (GOODKEY.ASC) 2) Revoke the GOODKEY on the public ring. It is now REVKEY. 3) Extract REVKEY to REVKEY.ASC (this is the stored revocation all this is designed to produce). 4) Delete REVKEY from the public ring. 5) Import GOODKEY.ASC into the pub ring, recreating GOODKEY. The =only= difference in our scenario here is that our unfortunate fellow forgot to do step one. Or did he? No, he'd extracted GOODKEY to GOODKEY.ASC in November. So all he has to do is step five. PGP doesn't know if the GOODKEY.ASC was extracted for the purpose of dissemination your key, or just to be re-added after REVKEY is extracted and deleted from the ring. jason ... Just because I'm moody doesn't mean you're not irritating -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP_ECHO: CypherEcho to the gods... iQCVAwUBLx1I1EjhGzlN9lCZAQF7yAP+KkrlQzOXRGPj46Ye/WF1s3vDYulSLJwV 3+Qei+mP+hTibTVlV0eSBMjkxIv7h682D1bzlWr9ilPKnmfuYY0ZEHrg0+Iwb/Xn xyIIle+KtKVgOsVWnbcWKChbAIAoTqAW+L9m7FnMIk1xd6i+E+SPBnFbPjjG6np+ Gl+E/FUxgVM= =7h8R -----END PGP SIGNATURE----- ... Key fingerprint = 60 97 B2 AE 7D 90 11 2F 05 1C 35 98 E9 B9 83 61 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: Ed Gills 18 Jan 95 14:06:16 Subject: Bbs Chat Encryption UpdReq -----BEGIN PGP SIGNED MESSAGE----- --====-- EG> I'm looking for an encryption program that I can use during chat on a EG> BBS I'm on... It seems like the sysop loves to emulate and see what's EG> going on. I need someway to encrypt and decrypt chat message while EG> still being able to send and receive non-encrypted messages to others EG> in the chat room. CHATCRPT.ZIP 2557 Basic source code and description for a program that promises to encrypt your conversation in a BBS's chat mode. This is NOT good encryption, just simple letter substitution. It should keep your talk from the prying eyes of a sysop, though. Available for FREQ or download from 1:102/903 (1-818-342-5127). John Schofield -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLx2P42j9fvT+ukJdAQHsCwQAxYkiwOMmo6YFuC56MNkqDrl8GfUnOx7k iQbS/uMZnv6gPRxB8bdMukZYDVYwduqc+FZi0RF/phoFHKH1RZbn2HMRcpk8fhLY Ft3pgNGzFwq0m2jJ1UAYWqwTQIIYcnCKna8QGV8OPc8LDiEyd9XZh0Xiq+AcbeTu ssGzmJDNqfI= =OUXA -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... "Press to test." "Release to detonate." "Uh-oh." 201434369420143436942014343694201434369420143436942014343694718 From: Jim Bell Area: Public Key Encryption To: All 19 Jan 95 01:02:00 Subject: Clipper Collapsing UpdReq Here's a short note from Electronic Buyer's News, January 16, 1995, page 6. "VLSI Steps around Clipper's Back Door." VLSI Technology Inc. Last week moved to expand its data encryption offerings as it licensed the RC4 Symmetric Stream Cipher security technology from RSA Data Security Inc. VLSI said it plans to offer the RSA data security technology as part of its Functional SYstem Block ASIC core library. The company now offers ASICs that implement the Clipper encryption technology developed by the federal governemnt. However, industry support for CLipper has eroded as companies and foreign governents expressed concerns about the inclusion of a back door in Clipper that would allow the government to access supposedly secure information. +++++++++++++++ end of article +++++++++++++++++ This news is good, because it indicates that the actual manufacturer of the Clipper Chip is apparently branching out into other types of encryption, apparently those without the flaw that Clipper included. Not surprising: It's been almost two years since Clipper was publicly revealed, and I'm sure that VLSI hasn't exactly had the door broken down with people wanting to buy the Clipper chip. Anyway, the following is VLSI's address and phone numbers, and subsequent to that are a couple of miscreants, Mykotronx and AT+T. VLSI Technology, 1109 MacKay Drive, San Jose CA 99131 phone 408-434-3000; fax 408-434-7926 District Manager: John Levers The name of the company that did the design of the crypto-chip is: Mykotronx, 357 Van Ness Way, Torrance, CA 90501, phone 310-533-8100, fax 310-533-0527. This is a chip-design place. They use someone else's chip manufacturing capability (a "foundry"). One of their customers-to-be is AT+T. [my guess is that Mykotronx is an NSA front organization.] AT&T AT&T Secure Communications Systems is headquartered in Greensboro. For more information about the AT&T Telephone Security Device 3600 and other AT&T Secure Communications Products, call David Arneke at 919-279-7680. CONTACT: David Arneke of AT&T Secure Communications Systems, 919-279- 7680,or after hours, 919-273-5687, or Herb Linnen of AT&T Media Relations, 202-457-3933, or after hours, 202-333-9162 ------------------------------------------- To recap: On April 16, 1993, the White House announced a proposed standard encryption system for voice telephones, and possibly for data transfer also. All the keys for such systems would be given to the government, split into two 40-bit sub-keys. It will do this do give the illusion that the codes are safe and cannot be misused, but in reality the security of this system depends totally on your view the trustworthiness of government. In other words, believing that this system is secure is up there with belief in Santa Claus and the Tooth Fairy. The telephones manufactured under this system will be sold under fraud: The average customer will not be told that the codes for the system are shared with the government. He will not be told, certainly by the manufacturer, that the system is therefore defective. The government has tried to portray this as if it would be a voluntary system. But it cannot control technology manufactured in the rest of the world. If it's truly voluntary, there would be a bigger demand for encrypted telephones whose codes were not shared by government. They would be available to you and others, cheaply. Nobody seriously contemplating a crime would depend on faulty encryption, so they would buy the truly secure phones. This would make the "voluntary" standard almost totally useless. In a few years, the government will pretend to "discover" this weakness, and will act to make truly secure telephones illegal. At the time, they will claim that only criminals will want telephones secure even from the government. Here's what you can do to stop this: Call these organizations to complain, loudly and often. These people don't expect that their actions will "come back to haunt them." It would only take a few phone calls to "wake them up" to the problem they've caused. Write letters-to-the-editor to newspapers in their area. Raise ethical questions about the activities of these companies. ... The rest of this tagline is encryp*&l#1E0+=|>fcd}85^7@jowxz*7"[=- ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Richard Dale Area: Public Key Encryption To: Jason Carr 19 Jan 95 18:58:10 Subject: KEY REVOKE UpdReq BG> No need to quote my key back to me. I extracted it to a BG> text file last November and it's still sitting on my HD in BG> ASCII format. I just havn't got the guts to try to add it BG> to my public key. I encrypted a bunch of files (as "messages" to myself) using PGP 2.3a. For some reason I thought you had to generate a new key when switching to 2.6x. Apparently that is not the case. I believe I could have simply used the 2.3a key, moving it over to 2.6x. In any case, I now have a 1024-bit and a 2047-bit key on 2.6.2, and can decrypt messages/files sent with either key. I suspect that if I put the 2.3a key on my ring, I can decrypt the files without having to move to a second computer, use 2.3a to decrypt them, copy them over to this computer, and re-encrypt them with 2.6.2. The point being is that I have loads of back-up copies of my PGP files. I've got \PGP23, \PGP261 and \PGP262 on this computer and \PGP23 on another computer. I have dual-redundant back-ups on floppies which are kept in different locations. The key files are backed up using both .BAK and .OLD files. I've extracted the public and private keys (for some reason) and have revocation certificates made. If you take precautions, you can play around with PGP and have no worries. If you don't make the back-ups, you can find yourself erasing some files which can never be decrypted. I found that out the hard way. I didn't lose anything, as I was working on copies, but it helped me learn what to do. * 1st 2.00b #567 * Reach down under the monitor and yank on it a few times. 201434369420143436942014343694201434369420143436942014343694718