From: Zorch Frezberg Area: Public Key Encryption To: Jim Cannell 13 Nov 94 17:50:32 Subject: PKZIP security UpdReq In a msg on , Jim Cannell of 1:216/21.1 writes: JC> Does anyone know about a method for cracking PKZIP passwords? Is JC> there a program (or a least an algorithm) available for this? JC> If so, where can I get a copy. Thanks. There is such a program. It was used by local police to access my PKZIPped log files in hopes of finding child pornography, credit card fraud and proof of my complicity in an international computer smuggling ring. I do not know the name of the program, other than that such exists, nor how available it is outside law enforcement. The officers involved routinely attend FBI training on computer crime, yet have not to date had a conviction based on any computer investigations thay they have conducted. Needless to say, I have not been charged with child pornography, credit card fraud nor complicity in an international computer smuggling ring. However, in the nearly 18 months that they have been holding my computer system and drives, I have been told that these will never be returned because the officers could _not_ find what they had wanted to prosecute me for. If my sources of information are correct, the officers found one large file and tried to use the various decoders on it with no success...unfortunately, it was the STACKER.VOL file for the Stack'd hard drive. When they went to reload it, they discovered that the back-up would not operate because certain read-only files didn't copy. I do not know if this story is true, but considering the "Modem Virus" story one officer told me, I do not doubt that it could be true. The "Modem Virus" was a 'flash notice' from FBI, he said, about a virus which activated *during* modem transfers _inside_ the data stream. PGP...best way to go. -zf- 201434369420143436942014343694201434369420143436942014343694718 From: John Mudge Area: Public Key Encryption To: Carl Hudkins 15 Nov 94 02:53:02 Subject: GOP vs. Clipper...? UpdReq Hello Carl! Tuesday November 08 1994, Carl Hudkins writes to All: CH> Even though I would rather have seen my party keep control of CH> the legislative branch (home-team kind of thing :) I am hoping that CH> since the Republicans say they are against "big government" they will CH> help put Clipper in the pine box where it belongs. CH> Does anybody have any educated info on this? It was written under the Bush administration....even Maria Cantwell's opposition to it was misguided...she thought it would hinder sales of US products abroad...she had no concept of the privacy issues involved. She is also now unemployed. John Mudge jmudge@wln.com 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Shawn McMahon 15 Nov 94 08:15:06 Subject: Hpack KEYCVT UpdReq Shawn McMahon wrote in a message to jason carr: jc> Whass it s'posed to do? SM> After you do that, Hpack can use your digital signature to SM> sign the archive, and other people can encrypt Hpack SM> archives with your public key so that only you can unarchive SM> them. Great stuff, when KEYCVT works. Thanks for the info. jason ... Bad command. Bad, bad command. Sit. Staaay.... 201434369420143436942014343694201434369420143436942014343694718 From: Basil Hoyl Area: Public Key Encryption To: Ian Hebert 15 Nov 94 20:54:24 Subject: PKZIP brute force cracker UpdReq This sounds like an interesting file. Is there some non-internet bbs on which this file may be found?[+6JQuB>(G L|!yrt-=DbgAt-^|.{mCb[R[|~r 201434369420143436942014343694201434369420143436942014343694718 From: David McIntyre Area: Public Key Encryption To: Jim Cannell 14 Nov 94 05:58:08 Subject: Re: PKZIP security UpdReq -=> Quoting Jim Cannell to All <=- JC> Does anyone know about a method for cracking PKZIP passwords? Is JC> there a program (or a least an algorithm) available for this? If so, JC> where can I get a copy. Thanks. There is such a program, but you need to throw a wordfile at it. It works kinda like Crack for UNIX passwd files, but with no rules to modify the wordlist. You would be best off using something like the Crackerjack preprocessor to create a unbelievably huge wordfile. Even then, it's possible to not ever hit upon the correct password after tying up your computer for many hours or even days. The program name is Zipcrack. Good luck, but I think you may be fighting an uphill battle. 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: John Stephenson 12 Nov 94 20:57:52 Subject: PGP versions UpdReq -----BEGIN PGP SIGNED MESSAGE----- --====-- JS> I'm curious about something.. I've heard that RSAREF is simply another JS> method of using RSA, but it's a slower alogrythm.. It didn't kick in JS> for a while but whoever said that is wrong, or else RSAREF could JS> decode, and encode to RSA -- which of course is false. So, what truely JS> IS the difference between RSA & RSAREF? I know that RSAREF has been JS> tested less throughly, but what about the actual alog.? Sigh. RSAREF uses the RSA algorithm, which earlier versions of PGP also used. See the latest issue of Wired (the one with the Whitfield Diffie interview) for an explanation of how RSAREF became integrated into PGP. The incompatibility is because of file formats, NOT a change in algorithm. JMS -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLsWb32j9fvT+ukJdAQFv/AP8COhqe7xbebvx4zhKdsoq3chnkCdtwceL cOVKWyHR2KbxxEfbTJPIMrqEFBG2pqYtW1ihC9krQMHS69muUmtI4cNTHH61+gsV qazYDbMK8oSqZ3+CkDxI44EzI5hxClgC5wCYfs6lR9ZKYUfmDGLgnJs7V9imD4cd VHxNYEZ9Z9A= =x9UE -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... "Stop that, son! You'll go blind." "I'm over here, Dad." 201434369420143436942014343694201434369420143436942014343694718 From: Mark Carter Area: Public Key Encryption To: Brian Giroux 16 Nov 94 10:39:50 Subject: MULTIPLE QUESTIONS... UpdReq In a msg on , Brian Giroux of 1:225/330 wrote: BG> What are the pros and cons of doing this instead of issuing a BG> separate key for each ID? The pro is you don't have to issue a separate key for each ID. I think doing so(issuing separate keys) would be more of a con than not. BG> Is there a way to get keys from a key server through FidoNet? Sure, just send through the 1:1/31 gateway. BG> What happens if I certify someone's key, and they turn out to be BG> someone who just certifies people's keys without checking them BG> out? Then keys signed by that person shouldn't be trusted. This doesn't reflect on you, however, since your certification of that person only says that you guarantee the key actually belongs to the person, not that the person can be trusted. Mark 201434369420143436942014343694201434369420143436942014343694718 From: James O'meara Area: Public Key Encryption To: David Chessler 13 Nov 94 01:06:00 Subject: Pgp 2.6.2 official m.i.t. UpdReq Hi! Is "SLMR 2.1b" an update I don't know about? I have (as you can see) an unregistered 2.1a, and I thought the only update was the registered OLX. Cordially, James O'Meara DC> ___ __ chessler@trinitydc.edu DC> d_)--/d chessler@cap.gwu.edu DC> * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com --- SLMR 2.1a Frustrate the NSA, Use Pretty Good Privacy 201434369420143436942014343694201434369420143436942014343694718 From: Jim Cannell Area: Public Key Encryption To: Ian Hebert 15 Nov 94 20:10:18 Subject: PKZIP brute force cracker UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a msg on , Ian Hebert of 1:2401/114@fidonet.org writes: IH> If you can provide me with an Internet address, I can mail you an IH> PGP ascii-armoured file, or with Chris's permission, I can post IH> it here as a multi-part message. (It would take about 500 IH> lines of PGP armoured text, or about 5 messages for the IH> file.) Try the standard internet address for all fido nodes: Jim.Cannell@f21.n216.z1.fidonet.org uuencoded and ascii armored do make it through the gateway. I also won't complain if you post it here (as long as Chris doesn't either. Jim - International SecureMail Host (ISMH) PGP key 1024/B7822B3D fingerprint = 0F F4 79 06 3B 33 99 D1 07 36 66 66 80 85 76 B3 Protect your right to privacy. Say no to GAK. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLsmG2iWTIMO3gis9AQHNaAQAn0fM5NOmkcRICm5vM5l9YnGmtnK191y7 AV5WLw7gfn+Z3T8C1b9N0B6ZEdK7o6mZ9RTJESQ7Tq6wXMHwcwbdAukZO280GNjy 4pTjANKlWTK/6iOCW1+69Cbpj0zleT3Xyrw0JrVaML4OqXllm/1t+TfgiUMCPtCo 4lkWY0glVYo= =Swea -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: John Goerzen Area: Public Key Encryption To: MICHAEL JOHNSON 15 Nov 94 20:07:32 Subject: Internet sites. UpdReq M@> Can anyone tell me of a place on internet (FTP) where I can get the diffe M@> versions of PGP? Versions prior to 2.5 were possibly illegal anyway, so why offer them? And why do you need 2.5 if 2.6 or 2.6.1 will work? You can get 2.6.1 by first *TELNETTING* to net-dist.mit.edu. Login to the "getpgp" account. Answer the questions, and write down the directory. Close the telnet connection and FTP to net-dist.mit.edu. Change into the directory you noted above. PGP executables are there. M@> If possible I would like all versions commonly in use today, so I can try M@> all and offer them to be downloaded by users. 2.6 and 2.6.1 really are the only versions commonly in use today. Also, if you offer them for downloading, make sure that it is only offered to citizens of the US....you can be in heaps of legal trouble otherwise. -- John Goerzen * RM 1.3 02214 * Howdy Doody had 48 freckles. VQWK 6.20I 201434369420143436942014343694201434369420143436942014343694718 From: John Goerzen Area: Public Key Encryption To: ALL 15 Nov 94 20:07:34 Subject: Status of Clipper UpdReq Hi, Does anybody know the current status of the Clipper chip? The last I heard was that the Clinton administration supports it. Thanks! -- John Goerzen * RM 1.3 02214 * America, land of opportunity for Japanese businessmen. VQWK 6.20I 201434369420143436942014343694201434369420143436942014343694718 From: Clarence Hand Area: Public Key Encryption To: Ian Hebert 15 Nov 94 20:26:56 Subject: PKZIP brute force cracker UpdReq -----BEGIN PGP SIGNED MESSAGE----- Hi Ian I am very interested in getting a copy of that file, that Phil mentions have tried zipcrack and it's W a y too slooow. i have some other ones but they don't support 2.04g, so if you don't mind could you send me a copy. Krip1@aol.comor1:212/2001.4 * Take my advice, I don't use it anyway. - -- ShaNuf 1.3e -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB1AwUBLsmMeK+ybogtscX1AQFRoAMAm+pds8ucdmEdBPG6wXLW2r+7GEFYA9vd ABTmr8j2OpEdpwIOMcTqgy8mJhaXD3aTIbioAYtKo/bxreE3MmSYi9ET++AqWK72 lGomHaGTYQkvvlqQ77Sco7OiIL/X1Xnk =n4ID -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Hulett S. Durrough 15 Nov 94 21:01:06 Subject: PGP HELP-INFO UpdReq -----BEGIN PGP SIGNED MESSAGE----- Hulett S. Durrough wrote in a message to All: HSD> someone else( I have only tried the sysop of another BBS HSD> in Canada) he has to save the message to disk,and go out HSD> of Bluewave to command line to decrypt and read.ie PGP HSD> filename.He then has to encrypt reply and save as HSD> amessage for Bluewave. On the other hand,I can decrypt Is he running PGPBLUE? It seems to be the easiest way to interface BW and PGP. If he's a sysop, it may be easier to link his msgbase editor (GenMsg, timEd, GoldEd, etc) to PGP. There are periodic posts in here of .BATs or .CMD files for doing just that. HSD> a reply add to or not and encrypt again. I have also HSD> been able to pull the public keys from a message on two HSD> different occasions but was unable to on a third one. I The third key may have been grunged. Did you see an error msg? jason ... All I want is a warm bed, a kind word and unlimited power -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP_ECHO: CypherEcho to the gods... iQCVAwUBLsmSwUjhGzlN9lCZAQFcvwP+KQQztnpu+WhNt4fCLHJ/lnMNchtzjDCa fnRgO/15S5iMbvCObrAWRDwry9RL4FRFUEjDRXjwKm1lUFRrq5Fc2Y7k85KDwyXo qZrut19yOtT8s558JDkyc0nuZHJXKItJFwku5CHqT84hnPPpS0xGQMT+agG5Nvoz FNbp84rF4tc= =wUUn -----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: Ian Hebert 15 Nov 94 21:05:32 Subject: PKZIP brute force cracker UpdReq -----BEGIN PGP SIGNED MESSAGE----- Ian Hebert wrote in a message to Jim Cannell: IH> There is a program called zipcrack, which according the IH> Pascal source code, is a brute-force cracker for PKZIP Is it FREQable? jason ... Primordial soup for dinner again? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP_ECHO: CypherEcho to the gods... iQCVAwUBLsmTT0jhGzlN9lCZAQHIhAQAqy5CFmasxSURGMS1j21zVAwR7d8qz9Fy zwDYVPsRI0WQDfqmcgMtTnjMkp+zLt5hxNTxMTrBB68ZtrOCvcV0DPfJT6BgKb+T loP304rDaOFC7EZOIyMj8CwzGb3dlJNP/5X5FYIxDZpkSVc9ZSIDnUnElQ9QNxFF eEYMzV9UCkk= =9JsM -----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: David Chessler 15 Nov 94 21:09:10 Subject: Pkzip security UpdReq -----BEGIN PGP SIGNED MESSAGE----- David Chessler wrote in a message to Jim Cannell: JC>Does anyone know about a method for cracking PKZIP passwords? Is there >a program (or a least an algorithm) available for this? If so, where >can I get a copy. Thanks. DC> There are 3 or 4 such programs. Some work with DC> dictionaries, some by guessing arbitrary strings. Try the DC> cypherpunks directory at ftp.cusa.berkeley.edu I got most DC> of them there. Do you have any up for FREQ? jason ... I can count even higher if I take my shoes off. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP_ECHO: CypherEcho to the gods... iQCVAwUBLsmUKkjhGzlN9lCZAQFOpgP+IHGUzbRaAtNGjb1XnpyIBeHcP50/zjNM fW5g00aGY60U21bGF/y1XyDkJ8XpNnTdQ3gDcVO22OMD6FU60f3d47Ydnk8GYTFs M9Zo2/qBN9FJT8tw4oI/dH/BcZyZA7WPiEMx7tLwzYFMvMActAVhS03i8hYfTKJ7 C+dgIFjGY3M= =GLFy -----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: Glen Todd 15 Nov 94 21:12:38 Subject: Re: PGP and GoldEd UpdReq -----BEGIN PGP SIGNED MESSAGE----- Glen Todd wrote in a message to Wes Landaker: GT> tried various batch file configurations, but haven't been able to GT> figure out how to pass whitespace-containing user IDs in the GT> batch files. Any suggestions out there? Pass the key ID instead: 0x________, where the underscores are replaced by the Key Id characters. This method is also more likely to be unique. Or do you really need to use the User ID for some reason? jason ... I DON'T NEED NO STINKIN' TAGLINE -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP_ECHO: CypherEcho to the gods... iQCVAwUBLsmVeUjhGzlN9lCZAQE09wP9EbgkIDm9s3xpE7b4R2udpMZKbjtyDpno rTxhvi/WJyROgxJlpJ0kjDC3NVP8rpRm0mYOpW9bvk3o1JoMV5cNUqSp4lfQya1e Uxezs0rgedlAa7ayaso2nwHdgSLydNGzXH3W1PKi7h3X+/7Rf6HS5CLXmRjPivJa p4McqaigEJE= =5jVV -----END PGP SIGNATURE----- ... Key fingerprint = 60 97 B2 AE 7D 90 11 2F 05 1C 35 98 E9 B9 83 61 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: David Chessler 16 Nov 94 10:04:14 Subject: Pgp abroad UpdReq Despite the stern warnings of the tribal elders, David Chessler said this to Ian Lin: DC> commercial use (which is cheap enough). Moreover, there is no DC> prohibition on IMPORTING secure encryption, so have the foreign DC> party buy an extra copy of whatever is commerically available DC> (probably triple DES), and send you the floppy. Even better would be a foreign implementation of MDC/SHS. That'd REALLY make the government prohibitions look stupid. What'd I'd like is a really good implementation of MDC/SHS written by a Libyan, Iraqui, or Red Chinese author. 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Albert Tanone 16 Nov 94 10:07:36 Subject: PGP UpdReq Despite the stern warnings of the tribal elders, Albert Tanone said this to All: AT> I just saw a file floating around PGP 2.6 or such. Is this a true AT> release or is this a hack? Why not download it and check the signatures, Albert? There is a 2.6 floating around that is a true release, but there's no way any of us can know if the file *YOU* saw is for real. AT> And, if that bill the gov't.'s talking about passes, would it be AT> illegal to use PGP? Would you care to narrow that down to a specific bill, so your question can be answered? For that matter, would you care to narrow it down to a specific government? :-) 201434369420143436942014343694201434369420143436942014343694718 From: Peter Bradie Area: Public Key Encryption To: Shawn K. Quinn 14 Nov 94 07:50:06 Subject: Ecpa and sysop only echo UpdReq -=> Quoting Shawn K. Quinn to All <=- SKQ> Does the ECPA apply to sysop-only and other "non-public" echos (such SKQ> as DuckNet's CHO_MEMBER, reserved for CHO members only)? The language of the ECPA refers to electronic communications. The latest statutes, and modifications thereof, ensure that BBS's are not considered common carriers, but if they handle electronic communications that are not readily accessible to the general [modeming] public, the ECPA appears to apply. ... Lawyers never lose their appeal. ___ Blue Wave/QWK v2.10 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Nov 94 18:49:10 Subject: PUBLIC_KEYS Echo Guidelines - regular repostUpdReq -----BEGIN PGP SIGNED MESSAGE----- This is the PUBLIC_KEYS Echo. The purpose of the Echo is to provide a place to discuss public-keys for data privacy within FidoNet and elsewhere. We also consider electronic signature possibilities using public-keys and discuss data and software encryption and the various schemes and programs that produce them. This is a technical Echo with very few rules. Those very few rules are: 1. Stay on-topic. Topics of keys and encryption and related privacy and electronic signature issues are welcome. Others are not. 2. No politics [except as it relates to privacy issues] and no religion. 3. No personal attacks, slurs or innuendo. Stick to issues not personalities. 4. No Private flagged messages in Echomail! Encrypted traffic using public-keys is permitted for the exercise so long as it is on-topic. Don't send person-specific encrypted traffic. Such specific traffic belongs in direct Netmail. Encrypted traffic should be in the form of ASCII-armored or personal key encrypted messages that can be read by anyone with PGP 2.6+ and your public-key. Include your public-key in a separate message before sending such test messages in case the other end doesn't have it or make them aware of how to get it from your system. If you just want to post your public-key, use PKEY_DROP Echo. 5. Clear-signed messages are not encrypted and may be used freely in this Echo. 6. This Echo may be traveling around the world so try to be concise. Avoid excessive quoting for one-liner responses. 7. Be aware that Echomail is NOT secure. Don't take anything at face value. 8. The posts in this Echo are the sole responsiblity of the poster. If you need verification, use Netmail. 9. The Moderators will deal with off-topic traffic. Don't respond for them. Links to this Echo will only be curtailed when absolutely necessary so please don't make it necessary. [grin] The Moderators are Christopher Baker [KeyID: 1024/F89A24F9 1994/05/18] and GK Pace [KeyID: 1024/EE38FB41 1994/05/14] at 1:374/14 and 1:374/26, respectively. It is Gated into Zone 2 by Jens Mueller at 2:24/24 who sends it on to Harry Bush at 2:51/2. Consult Jens or Harry for Zone 2 feeds. The Echo is gated into Zone 3 by Jackson Harding at 3:800/857. [thanks, guys!] The other Zones are open [hint, hint]. It is recommended that individual, public-keys be made available via Netmail or by file-request with the magic filename: PGPKEY and that the public-key provided for that request by given a distinctive filename using part or all of each provider's name and address. For example, on my system, a file-request of PGPKEY will give BAK37414.ASC to the requesting system. A magic filename of KEYRING will yield extracts from my Public Keyring as BAKPUB14.ASC. This will avoid duplicate overwriting and make it easier to track the keys. Using standard magic filenames will make it easier to find keys and keyrings on different systems. The PGP and Privacy and encryption related files on each system should be maintained with a magic filename for file request. PGPFILES should be set on all participating systems to allow your current related files to be picked up at any time. It is suggested that the actual filename indicate the origin of the list to avoid confusion and overwriting. PGPFILES requested from this system gets the requestor a file called: PGP37414.LST. The contents of this Echo are archived on 1:374/14 as the area is purged. The current past traffic is in the file PUBKEY.ECO. Archives are no longer kept. This Echo is currently available on the Zone 1 Backbone. It has been EListed as of ELIST211. Please feel free to announce this Echo in all Nets and Networks. A companion Echo for the purpose of submitting public-keys only is now available as PKEY_DROP Echo. PKEY_DROP may be obtained via the same channels as PUBLIC_KEYS. NOTE: If you lose your secret-key password [or forget it] or your secret-key in a drive crash [because you failed to back it up on floppy], you cannot issue a revocation certificate. In that case, you should make a general announcement in all related Echos that your old key should be disabled using the PGP disable command [PGP -kd userid] for your userid. That keeps your useless key on their keyrings [so they won't be replaced from other lists who didn't get the word] and permits them to add a new key from you without one interfering with the other. Thanks. TTFN. Christopher Baker & GK Pace Moderators -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLslI+MsQPBL4miT5AQGFVwQArUoTIhkkZDAlqIpcV+ypCA1WBK/5A3CO qWJMK9nwIfw9kI9B0SaeBLcR4yvvWwsTSz7yOwSk3wn+747/xuaajMEpo1ZCToQe cnjUhmpYiBPeOGW0/xW/D2HS6a9mVJO1W10ox6yLs3c2/5cewR8u3h2/dhbMp9DA 6FM0DGty5ok= =Ne/0 -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Nov 94 18:50:32 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.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLslJS8sQPBL4miT5AQH1fAP9GaWaEmCPz2x3PKME+v79bsla3k5XjZGo 6v4PxoDqo2vkM6xK7wVO+HxxBWnzl2VJiigTyg1gaii1I8HKX2jJeagvXERyVNBR TI3EW2FADHZJjmkeUd4sbat7zCHG8Alo6GehgmnC4UdAWiPB2f0Fkz9WUiH8aiU4 c6eNA/8mTvo= =bTnX -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Nov 94 18:51:26 Subject: SecureMail Host 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.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLslJgcsQPBL4miT5AQFInAP/Ye1vF6w4E0QRoiaHm92pJqzHJKXz9nNs Yrp1xyiHBfl0Y9E9rOFvPZV3mydS8QjNO3l+m3mn7bselraWLFH2gJydTVSExdsC ClFazNva495MoaUE579MWTuq4TlGVtylOqU3nki6i/xAdufItGNiaHTTkG43joOP PD8gtRxz8a4= =mEPU -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 15 Nov 94 18:52:42 Subject: SecureMail Host Routing 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 Mike Burgett 1:215/705 | | |-- 215 Joe Pye 1:215/25 | | | |-- 202 Guy Martin 1:202/905 | |-- 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 | |-- 2215 Jim Bailey 1:2215/480 | |-- 2240 Ryan Anderson 1:120/379 | |-- 2410 Ryan Anderson 1:120/379 | | |--- 12 Jesse David Hollington 1:225/1 X | | | SMH |-- 167 Frederic Giroux 1:167/535 | |-- 221 Paul Henry 1:221/279 X | |-- 225 Brett Dubroy 1:225/100 X | |-- 252 *none at present* | | |--- 13 Marc Stuart 1:2624/402 X | | | |-- 107 *none at present* | |-- 267 Matthew Landry 1:267/109 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 X | | |--- 17 Ted Rolle 1:105/36 | | | SMH |-- 105 *none at present* | |-- 340 *none at present* | |-- 346 *none at present* | | | |--- 18 Christopher Baker 1:374/14 X | | [cbak.rights@opus.global.org] | | | |---- 3:800/857 Jackson Harding 3:800/857 X | | | |------- 285 Mike Riddle 1:285/27 X | | | SMH |-- 116 *none at present* | |-- 123 Scott Miller 1:123/416 X | |-- 135 Tom Cropper 1:135/327 [Down] | |-- 135* David Bobo 1:135/110 | |-- 151 James Barrett 1:151/132 X | |-- 360 Stephen Frazier 1:360/23 X | |-- 362 Jack Whaley 1:362/940 X | |-- 365 Chris Britton 1:365/200 X | |-- 366 Rob Buckman 1:366/844 X | |-- 369 *none at present* | |-- 374 GK Pace 1:374/26 X | |-- 375 Michael Hess 1:375/48 X | |-- 378 Sydney Marcus 1:378/10 X | |-- 379 *none at present* | |-- 3608 Michael Smeby 1:3608/3 X | |-- 3636 Chris Chastain 1:3636/16 X | |-- 3647 Gale D. Wilkerson 1:3647/1 X | |-- 3649 Chris Hunter 1:3649/17 X | | |--- 19 Mike Lenker 1:106/1776 X | | | SMH |-- 106 Mike Lenker 1:106/1776 X | |-- 124 Bob Ratliff 1:124/7020 | |-- 130 Dale Hopkins 1:130/908 X | |-- 147 Bill Teasley 1:147/3660 X | |-- 170* 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.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLslJzcsQPBL4miT5AQEMmAQAkU8AK4p5386RaQfqOx4tsGa/ffurEW6L 52+ImJx4qq2BXWCo1Yc4SUqBu+8sDaKy+mPVITG3WLPslBpcekbqeCN7M+UpmXcH qPXeDiuePvRlfpAtSWNZ03Od0EXa1iXgHSAI/DdYsI2EPZdJ7r9CsSmi8bc2yaFW s5BZWFNzZx0= =NQLv -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: Albert Tanone 16 Nov 94 19:24:52 Subject: Re: PGP UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 12 Nov 94, Albert Tanone was quoted as saying: AT> I just saw a file floating around PGP 2.6 or such. Is this a true AT> release or is this a hack? 2.6.2 is the current release. freq PGP for the archive. AT> And, if that bill the gov't.'s talking about passes, would it be AT> illegal to use PGP? I mean, I use it once in a while to communicate AT> with my friends up north regarding stuff that I wouldn't exactly say AT> in public (teen AT> matters). it would be more impossible to enforce than drug laws. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP 2.6.2 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLsqi2MsQPBL4miT5AQFyXQP+JQ1WEHjfJs5eICPhqtmWhiYyxkUrkgKC WI/QatFZRp/swNECmeHtYugI0vtISPNO8AZubKUiViTuvbiRnU4MTH+41AUGRwKa gUHVafXbv6vIzh3ALJuAy4oxBMC1zg8fVD22cbt2vWHwLSFN/QbCeLyz+ZfUAXQE vmX4sdyXddw= =Kukf -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:21:14 Subject: H.R. 5199 1/2 UpdReq Date: Fri, 28 Oct 94 10:43:57 EDT From: Carl Ellison Subject: HR5199 cover letter Thanks to John Young for scanning this in from a FAX copy. This is the cover letter on HR5199. It starts out in a different tone from the one in which it ends, so I would suggest reading it through before reacting (something I failed to do when I first read it). - Carl Scanning date: Thu, 27 Oct 1994 19:28:27 -0400 ------------------- "Encryption Standards and Procedures Act of 1994" HON. GEORGE E. BROWN, JR. of California In the House of Representatives Thursday, October 6, 1994 Mr. Speaker, today I am introducing H.R. 5199, the Encryption Standards and Procedures Act of 1994. The purpose of this legislation is to establish Federal policy governing the development and use of encryption technology for unclassified information that strikes the proper balance between the public's right to private and secure communications and the government's need to decipher information obtained through lawful surveillance. The legislation would authorize the National Institute of Standards and Technology (NIST) to develop and issue, by regulation, federal encryption standards for ensuring privacy, security, and authenticity of domestic and international electronic communications in a way that preserves privacy rights and maintains the government's authority and ability to conduct electronic surveillance. The development of such standards under a rulemaking process will ensure that all stakeholders have an opportunity to influence the final program. With respect to that policy, the bill would permit wider use of encryption technology while reasserting Fourth Amendment privacy rights and the government's authority to conduct lawful electronic surveillance. To ensure those rights are preserved, the bill would impose new legal requirements on escrow agents that may be part of an encryption standard established under the legislation. It would also establish a research and development program at NIST to develop next generation encryption technology, and would authorize the use of available appropriations to implement the legislation. Mr. Speaker, this administration has placed a high priority on promoting the National Information Infrastructure (NII) and in realizing fully the economic and social benefits of that infrastructure. To achieve these goals, which I strongly endorse, information communicated over the NII must be secure, private, and authentic. Otherwise, the public will not fully use the NII and we will not realize its vast potential benefits. Encryption technology provides this capability. During the Cold War, the Federal Government pursued a de facto policy of suppressing private sector development, use, and export of encryption technology for national security reasons. Recent advancements in encryption technology and its proliferation make enforcement of that policy increasingly difficult. Moreover, fulfilling the goals of the National Information Infrastructure requires private and secure communications that can only be achieved with encryption technology. The widespread use of that technology, however, threatens to impede the government's ability to conduct lawful electronic surveillance. In February, 1994, the Administration responded to this dilemma by formally adopting a voluntary federal Escrowed Encryption Standard (EES) for electronic voice communications known as "Clipper". The standard would be implemented in computer chips that use a classified mathematical formula to encrypt unclassified telephone conversations and computer data transmitted over public telephone networks. Authorized government agencies can decode those communications by presenting a legal request to two escrow agents, which would hold two halves of a mathematical key that can decipher the code. The purposes of Clipper are two fold -- first, to provide a means to safeguard public and private electronic voice communications and, second, 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:22:14 Subject: 02/H.R. 5199 1/2 UpdReq to enable government law enforcement authorities and intelligence gathering agencies to decipher such coummunications that have been lawfully intercepted. Similar voluntary standards for electronic data communications are under development by the government and may soon be issued. The Administration contends that it has authority under the Computer Security Act to issue such standards. Others, however, have raised concerns about the proper interpretation and application of the Act with respect to Clipper and similar standards. The Computer Secuirty Act, which the Committee on Science, Space, and Technology reported and the Congress enacted in 1987, authorized NIST, in consultation with other appropriate federal agencies, to develop and issue standards and guidelines for protecting "unclassified, sensitive information" in "federal computer systems". The Act did not explicitly contemplate the development or issuance of standards for safeguarding private communications and satisfying the information needs of law enforcement and the intelligence community. Such communications are considered private property subject to separate and distinct constitutional rights and legal protections. The Administration's interpretation of the Computer Security Act to cover such matters appears to go beyond the original intent of the Act and may be inconsistent with other law pertaining to individual privacy, protection of private property, and government authority to conduct lawful electronic surveillance. In testimony at hearings before our Committee, witnesses from industry and privacy groups objected to the secretive way Clipper was developed, and stated that the initiative does not go far enough to promote widespread use of encryption technology. They argued that the program will hamper business opportunities for United States firms, may infringe on individual privacy rights, and is prone to abuse. The Administration refutes these claims and intends to proceed with the initiative arguing that it is essential for public safety and national security. The issue currently is stalemated unless there is legislation or third party intervention. The Administration has publicly stated that it does not intend to seek legislation expressly authorizing Clipper or any other federal encryption standard because it wants flexibility to modify its encryption policy and program in response to changing circumstances. The Administration's desire for flexibility, however, contributes to the public's mistrust and opposition to Clipper. The proposal was developed under an administrative directive and, therefore, could just as easily be changed in a way that might be construed to diminish privacy rights without giving the public adequate opportunity to affect the program. For this reason alone, the public is unlikely to ever accept Clipper Chip in its present form. I, along with others, believe that a viable approach to gain public support for an initiative like Clipper is legislation to codify encryption policy and govern how that policy would be implemented. In so doing, all stakeholders would have an opportunity to influence policy. The final program would have been subjected to greater scrutiny and its implementation would be under the rule of law. It may well be that only under these circumstances would the public accept a federal encryption standard and the needs of law enforcement could be satisfied without compromising privacy rights. The Office of Technology Assessment (OTA) issued in September an extensive report entitled "Information Security and Privacy Network Environments" that is consistent with this view. The report concluded that "appropriate institutional and technical safeguards are required for a broad range of personal ... information, [o]therwise, concerns for the security and privacy of networked information may limit the usefulness and acceptance of the global information infrastructure." OTA also stated that such safeguards can only be developed successfully through an "open 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:23:14 Subject: 03/H.R. 5199 1/2 UpdReq process" and with congressional involvement so the views of all affected parties can be considered properly in arriving at a final outcome. Public trust in government and acceptance of federal encryption standards can only be achieved through such a process. This sentiment was shared by most respondents to a draft of the bill circulated earlier this Summer for comments. Mr. Speaker, the bill I have introduced today has been drafted, not as a perfect solution to the problem of privacy and security in the electronic information age, but as a means for getting the various factions to talk to each other in an open process to reach a sensible and effective resolution of this critical issue. I invite all interested parties to comment on the bill. My intention is to modify the bill to reflect comments made and to introduce it again early in the 104th Congress for consideration by this body. [End] 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:22:06 Subject: H.R. 5199 2/2 UpdReq 103d CONGRESS H. R. 5199 As Introduced in the House Note: This document is the unofficial version of a Bill or Resolution. The printed Bill and Resolution produced by the Government Printing Office is the only official version. VERSION As Introduced in the House CONGRESS 103d CONGRESS 2d Session BILL H. R. 5199 TITLE To amend the National Institute of Standards and Technology Act to provide for the establishment and management of voluntary encryption standards to protect the privacy and security of electronic information, and for other purposes. -------------------- IN THE HOUSE OF REPRESENTATIVES OCTOBER 6, 1994 Mr. Brown of California introduced the following bill; which was referred to the Committee on Science, Space, and Technology -------------------- TEXT A BILL To amend the National Institute of Standards and Technology Act to provide for the establishment and management of voluntary encryption standards to protect the privacy and security of electronic information, and for other purposes. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, SECTION 1. SHORT TITLE. This Act may be cited as the `Encryption Standards and Procedures Act of 1994`. SEC. 2. FINDINGS AND PURPOSES. (a) Findings . - The Congress finds the following: (1) Advancements in communications and information technology and the widespread use of that technology have enhanced the volume and value of domestic and international communication of electronic information as well as the ability to preserve the confidentiality, protect the privacy, and authenticate the origin, of that information. (2) The proliferation of communications and information technology has made it increasingly difficult for the government to obtain and decipher, in a timely manner and as provided by law, electronic information that is necessary to provide for public safety and national security. (3) The development of the Nation`s information infrastructure and the realization of the full benefits of that infrastructure require that electronic information resident in, or communicated over, that infrastructure is secure, confidential, and authentic. (4) Security, privacy, and authentication of electronic information resident in, or communicated over, the Nation`s information infrastructure are enhanced with the use of encryption technology. (5) The rights of individuals and other persons to security, privacy, and protection in their communications and in the dissemination and receipt of electronic information should be preserved and protected. (6) The authority and ability of the government to obtain and decipher, in a timely manner and as provided by law, electronic information necessary to provide for public safety and national security should also be preserved. (7) There is a national need to develop, adopt, and use encryption methods and procedures that advance the development of the Nation`s information infrastructure and that preserve the personal rights referred to in paragraph (5) and the governmental authority and ability referred to in paragraph (6), as provided by law. (b) Purposes . - It is the purpose of this Act - 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:23:06 Subject: 02/H.R. 5199 2/2 UpdReq (1) to promote the development of the Nation`s information infrastructure consistent with public welfare and safety, national security, and the privacy and protection of personal property; (2) to encourage and facilitate the development, adoption, and use of encryption standards and procedures that provide sufficient privacy, protection, and authentication of electronic information and that reasonably satisfy the needs of government to provide for public safety and national security; and (3) to establish Federal policy governing the development, adoption, and use of encryption standards and procedures and a Federal program to carry out that policy. SEC. 3. ENCRYPTION STANDARDS AND PROCEDURES. (a) Computer System Security and Privacy Advisory Board. - (1) Requirement of privacy expertise . - Section 21(a)(2) of the National Institute of Standards and Technology Act (15 U.S.C. 278g-4(a)(2)) is amended by inserting `(including computer systems privacy)` after `related disciplines`. (2) Expanded functions . - Section 21(b) of such Act (15 U.S.C. 278g-4(b)) is amended - (A) by striking `and` at the end of paragraph (2); (B) by striking the period at the end of paragraph (3) and inserting `; and`; and (C) by adding after paragraph (3) the following new paragraph: `(4) to advise the Institute and the Congress on privacy issues pertaining to electronic information and on encryption standards developed under section 31(b).`. (b) Standards and Procedures . - The National Institute of Standards and Technology Act is further amended - (1) by redesignating section 31 as section 32; and (2) by inserting after section 30 the following new section 31: `SEC. 31. ENCRYPTION STANDARDS AND PROCEDURES. `(a) Establishment and Authority . - The Secretary, acting through the Director, shall establish an Encryption Standards and Procedures Program to carry out this section. In carrying out this section, the Secretary, acting through the Director, may (in addition to the authority provided under section 2) conduct research and development on encryption standards and procedures, make grants, and enter into contracts, cooperative agreements, joint ventures, royalty arrangements, and licensing agreements on such terms and conditions the Secretary considers appropriate. `(b) Federal Encryption Standards . - `(1) In general . - The Secretary, acting through the Director and after providing notice to the public and an opportunity for comment, may by regulation develop encryption standards as part of the program established under subsection (a). `(2) Requirements . - Any encryption standard developed under paragraph (1) - `(A) shall, to the maximum extent practicable, provide for the confidentiality, integrity, or authenticity of electronic information; `(B) shall advance the development, and enhance the security, of the Nation`s information infrastructure; `(C) shall contribute to public safety and national security; `(D) shall not diminish existing privacy rights of individuals and other persons; . `(E) shall preserve the functional ability of the government to decipher, in a timely manner, electronic information that has been obtained pursuant to an 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:24:06 Subject: 03/H.R. 5199 2/2 UpdReq electronic surveillance permitted by law; `(F) may be implemented in software, firmware, hardware, or any combination thereof; and `(G) shall include a validation program to determine the extent to which such standards have been implemented in conformance with the requirements set forth in this paragraph. `(3) Consultation . - Standards developed under paragraph (1) shall be developed in consultation with the heads of other appropriate Federal agencies. `(c) Permitted Use of Standards . - The Federal Government shall make available for public use any standard established under subsection (b), except that nothing in this Act may be construed to require such use by any individual or other person. `(d) Escrow Agents . - `(1) Designation . - If a key escrow encryption standard is established under subsection (b), the President shall designate at least 2 Federal agencies that satisfy the qualifications referred to in paragraph (2) to act as key escrow agents for that standard. `(2) Qualifications . - A key escrow agent designated under paragraph (1) shall be a Federal agency that - `(A) possesses the capability, competency, and resources to administer the key escrow encryption standard, to safeguard sensitive information related to it, and to carry out the responsibilities set forth in paragraph (3) in a timely manner; and `(B) is not a Federal agency that is authorized by law to conduct electronic surveillance. `(3) Responsibilities . - A key escrow agent designated under paragraph (1) shall, by regulation and in consultation with the Secretary and any other key escrow agent designated under such paragraph, establish procedures and take other appropriate steps - `(A) to safeguard the confidentiality, integrity, and availability of keys or components thereof held by the agent pursuant to this subsection; `(B) to preserve the integrity of any key escrow encryption standard established under subsection (b) for which the agent holds the keys or components thereof; `(C) to hold and manage the keys or components thereof consistent with the requirements of this section and the encryption standard established under subsection (b); and `(D) to carry out the responsibilities set forth in this paragraph in the most effective and efficient manner practicable. `(4) Authority . - A key escrow agent designated under paragraph (1) may enter into contracts, cooperative agreements, and joint ventures and take other appropriate steps to carry out its responsibilities. `(e) Limitations on Access and Use . - `(1) Release of key to certain agencies . - A key escrow agent designated under subsection (d) may release a key or component thereof held by the agent pursuant to that subsection only to a Federal agency that is authorized by law to conduct electronic surveillance and that is authorized to obtain and use the key or component by court order or other provision of law. An entity to whom a key or component thereof has been released under this paragraph may use the key or component thereof only in the manner and for the purpose and duration that is expressly provided for in the court order or other provision of law authorizing such release and use. `(2) Limitation on use by private persons and foreign 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:25:06 Subject: 04/H.R. 5199 2/2 UpdReq citizens . - `(A) In general . - Except as provided in subparagraph (B), a person (including a person not a citizen or permanent resident of the United States) that is not an agency of the Federal Government or a State or local government shall not have access to or use keys associated with an encryption standard established under subsection (b). `(B) Exception . - A representative of a foreign government may have access to and use a key associated with an encryption standard established under subsection (b) only if the President determines that such access and use is in the national security and foreign policy interests of the United States. The President shall prescribe the manner and conditions of any such access and use. `(3) Limit on use by government agencies . - A government agency, instrumentality, or political subdivision thereof shall not have access to or use a key or component thereof associated with an encryption standard established under subsection (b) that is held by a key escrow agent under subsection (d) unless such access or use is authorized by this section, by court order, or by other law. `(f) Review and Report . - `(1) In general . - Within 2 years after the date of the enactment of this Act and at least once every 2 years thereafter, the Secretary shall conduct a hearing on the record in which all interested parties shall have an opportunity to comment on the extent to which encryption standards, procedures, and requirements established under this section have succeeded in fulfilling the purposes of this section and the manner and extent to which such standards, procedures, and requirements can be improved. `(2) Report . - Upon completion of a hearing conducted under paragraph (1), the Secretary shall submit to the Congress a report containing a statement of the Secretary`s findings pursuant to the hearing along with recommendations and a plan for correcting any deficiencies or abuses in achieving the purposes of this section that are identified as a result of the hearing. `(g) Regulations . - Within one year after the date of the enactment of this Act, the Secretary and each key escrow agent designated by the President under subsection (d) shall, after notice to the public and opportunity for comment, issue any regulations necessary to carry out this section. `(h) Liability . - The United States shall not be liable for any loss incurred by any individual or other person resulting from any compromise or security breach of any encryption standard established under subsection (b) or any violation of this section or any regulation or procedure established by or under this section by - `(1) any person who is not an official or employee of the United States; or `(2) any person who is an official or employee of the United States, unless such compromise, breach, or violation is willful. `(i) Severability . - If any provision of this section, or the application thereof, to any person or circumstance, is held invalid, the remainder of this section, and the application thereof, to other persons or circumstances shall not be affected thereby. `(j) Definitions . - For purposes of this section: `(1) The term `content`, when used with respect to electronic information, includes the substance, purport, or meaning of that information. `(2) The term `electronic communications system` has the 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:26:06 Subject: 05/H.R. 5199 2/2 UpdReq meaning given such term in section 2510(14) of title 18, United States Code. `(3) The term `encryption` means a method - `(A) to encipher and decipher the content of electronic information to protect the privacy and security of such information; or `(B) to verify the integrity, or authenticate the origin, of electronic information. `(4) The term `encryption standard` means a technical, management, physical, or administrative standard or associated guideline or procedure for conducting encryption, including key escrow encryption, to ensure or verify the integrity, authenticity, or confidentiality of electronic information that, regardless of application or purpose, is stored, processed, transmitted, or otherwise communicated domestically or internationally in any public or private electronic communications system. `(5) The term `key escrow encryption` means an encryption method that allows the government, pursuant to court order or other provision of law, to decipher electronic information that has been encrypted with that method by using a unique secret code or key that is, in whole or in part, held by and obtained from a key escrow agent. `(6) The term `key escrow agent` means an entity designated by the President under subsection (d) to hold and manage keys associated with an encryption standard established under subsection (b). `(7) The term `key` means a unique secret code or character string that enables a party other than the sender, holder, or intended recipient of electronic information to decipher such information that has been enciphered with a corresponding encryption standard established under subsection (b) only with such code or string. `(8) The term `electronic information` means the content, source, or destination of any information in any electronic form and in any medium which has not been specifically authorized by a Federal statute or an Executive Order to be kept secret in the interest of national defense or foreign policy and which is stored, processed, transmitted or otherwise communicated, domestically or internationally, in an electronic communications system, and `(A) electronic communication within the meaning of section 2510(12) of title 18, United States Code; or `(B) wire communication within the meaning of section 2510(1) of such title. `(9) The term `government` means the Federal Government, a State or political subdivision of a State, the District of Columbia, or a commonwealth, territory, or possession of the United States. `(k) Authorization of Appropriations . - `(1) In general . - From amounts otherwise authorized to be appropriated to the Secretary of Commerce for fiscal years 1995 through 1997 to carry out the programs of the Institute, the amount of $50,000,000 shall be available for such fiscal years to carry out this section. Such amount shall remain available until expended. Of such amount, $1,000,000 shall be available for the National Research Council study on national cryptography policy authorized under section 267 of the National Defense Authorization Act for Fiscal Year 1994 (10 U.S.C 421 note). `(2) Transfer authority . - The Secretary may transfer funds appropriated pursuant to paragraph (1) to a key escrow agent other 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:27:06 Subject: 06/H.R. 5199 2/2 UpdReq than the Secretary in amounts sufficient to cover the cost of carrying out the responsibilities of the agent under this section. Funds so transferred shall remain available until expended.`. 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:22:28 Subject: EFF Reaction to early draft UpdReq [mech@eff.org assures me that the EFF reaction to the discussion draft is still the EFF position] Subject: EFF Reactions to Encryption Standards & Procedures Act (Draft) ----------------------------------------------------------------------- The staff of the House Science, Space, and Technology Committee has just released a draft bill which would create a somewhat more public process for establishment of Clipper-like escrowed encryption systems. Entry of the Congress into this policy debate is a welcome change after 18 months of one-sided Executive Branch edicts. However, considerable changes would be required before the legislation would meet EFF's goals for a truly open federal encryption policy which preserves the right of private individuals to use any form of encryption, without restriction or penalty. Despite its promise of an open process, this bill is by no means a repudiation of the Clipper program, In fact, it enshrines in legislation several key aspects of the Clipper policy. However, inasmuch as the bill seeks to establish NIST authority to develop escrow encryption systems, it raises real questions about whether NIST or other agencies have any authority now to spend federal funds on escrow encryption systems. Overview of the bill: The bill directs the Department of Commerce, through the National Institute of Standards and Technology, to issue escrowed encryption standards. The standards issued would be subject to public comment and afford the opportunity for judicial review under the terms of the Administrative Procedures Act. Similar procedures created for the designation of government key escrow agents. Several aspects of the Clinton Administration's approach to cryptography policy are accepted by this bill: 1. Absolute preservation of law enforcement and national security access By this bill, any encryption standards adopted must "preserve the functional ability of the government to interpret, in a timely manner, electronic information that has been obtained pursuant to an electronic surveillance permitted by law." Sec 31(b)(2)(E). 2. Weak privacy protection The bill specifies that standards adopted should advance the development of the NII, but offers only qualified support for privacy. Standards should are only required to go so far as to not "diminish existing privacy rights...." Sec 31(b)(2)(D). 3. Increased role for National Security Agency in civilian privacy and security matters The bill establishes a permanent role for the National Security Agency in the creation of privacy and security standards for use by the private sector. Currently, under the Computer Security Act, NIST is encouraged to consult with the NSA on matters of federal systems security and to draw "computer system technical security guidelines developed by the National Security Agency to the extent that the National Bureau of Standards determines that such guidelines are consistent with the requirements for protecting sensitive information in Federal computer systems." This would explicitly extend the NSA role from federal systems to systems intended for public, civilian use. As such, this is a major change in the Computer Security Act. Issues to be addressed in draft: To create a truly open policy process, to protect privacy, and to ensure the development of the best privacy-protecting technology possible, the bill should be augmented with the following provisions: 1. Voluntary standards Any legislation on encryption standards must guarantee that no one will be required to use such standards, nor will use of other encryption standards be curtailed by law. Furthermore, federal encryption policy should guarantee that access to government programs, opportunities, or even the ability to communicate with the government, should never be conditioned on the use of any escrowed encryption standard. From the first announcement of the Clipper program, the Clinton Administration has assured the public that escrowed encryption would remain voluntary. This promise must be 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 31 Oct 94 19:23:28 Subject: 02/EFF Reaction to early draft UpdReq included in legislation. 2. Open design process The draft bill does call for an open process for formation of encryption standards. Legislation should make explicit that an open process means that no classified algorithms or technologies may be included. Though there was public comment on the Escrowed Encryption FIPS (the Clipper Federal Information Processing Standard), public process in that case was meaningless because the core technology remained behind a veil of secrecy. 3. Remedies for negligence or abuse by escrow agents As drafted, the proposal drastically limits the liability of federal escrow agents for all but "willful" abuse by federal employees. The escrow agents must also be responsible for unauthorized release of keys because of the actions of private individuals or because of negligent practices by government agents. 4. Exploration of voluntary, private sector escrow agents Finally, if the government is going to adopt a government-based escrow system, it should also be required to explore the possibility of private party escrow systems based on open standards. The full text of the draft bill is available from EFF's archives: ftp.eff.org, /pub/EFF/Policy/Crypto/encryp_stds_procedures_94_bill.draft gopher.eff.org, 1/EFF/Policy/Crypto/encryp_stds_procedures_94_bill.draft http://www.eff.org/pub/EFF/Policy/Crypto/encryp_stds_procedures_94_bill.draft 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: All 1 Nov 94 09:50:38 Subject: HPACK? UpdReq Does anyone have a sample entry for COMPRESS.CFG that uses HPACK in its public-key encrypt-all mode? (HPACK A -CPA ARCHIVE) Thanks Mike 201434369420143436942014343694201434369420143436942014343694718 From: Wes Perkhiser Area: Public Key Encryption To: Mike Riddle 1 Nov 94 23:11:28 Subject: HPACK? UpdReq In a message of , Mike Riddle (1:285/28@fidonet) writes: MR>Does anyone have a sample entry for COMPRESS.CFG that uses HPACK MR>in its public-key encrypt-all mode? (HPACK A -CPA MR>ARCHIVE) I haven't tried that specific setup, but I have found out the HPACK is whitespace sensitive in both the command line and in the configuration file (script file). For example: "HPACK v test" will work, but "HPACK v test " will attempt to list only the file(s) in TEST.HPK whose file name is a single character long, that character being ASCII 32. Likewise, in the configuration file: "set signerid = 0xFE0E156D" will work (for you) but "set signerid=0xFE0E156D" will exit with an unrecognized command error. Wes P.S. Just a hint: individually encrypting and signing files with a public key while compressing will take almost as long to complete as cracking the MDC cipher will. :( 201434369420143436942014343694201434369420143436942014343694718 From: Mike Riddle Area: Public Key Encryption To: Jim Bell 5 Nov 94 08:24:42 Subject: PGP 2.6.2 Official M.I.T. UpdReq In a message to MIKE RIDDLE on Nov 03 94 at 00:01, Jim Bell wrote: MR>> Notwithstanding the plain language of the ITAR about these MR>> matters, Da Guvmint (which always knows best) continues to MR>> insist that source code, at least in electronic form, is MR>> export-controlled. JB> Does that mean that PGP could be exported, in source code JB> form, if it was written on paper? Or, UUENCODE on paper. JB> Does that include 1 and 2-dimensional bar codes? JB> I realize that this may seem simply a make-work excercise, JB> but remember that this only has to be done ONCE for that JB> program to exist, legally, around the world. The only thing I saw that purported to be from State seemed to say that source code for cryptography required a licenes. Note that _Applied Cryptography_ went through the licensing process, or so I understand it. And remember that PGP seems to find its way overseas, quickly, after each new release. I believe that Phil and MIT are doing their best not to violate the law, but there apparently are folks out there who don't seem to mind too much. 201434369420143436942014343694201434369420143436942014343694718 From: Ian Lin Area: Public Key Encryption To: David Mcintyre 3 Nov 94 20:45:42 Subject: PGP versions UpdReq -----BEGIN PGP SIGNED MESSAGE----- DM> My feeling is that PGP distribution is fine the way the 2.6 was DM> distributed. That is, making sure that the primary distribution site And how do you feel about PGP 2.3a? That's what I use. I don't trust the 2.6+ versions but I do have 2.6ui to pretend it's any version. ... I didn't miss pell, he moved. ___--BEGIN PGP SIGNATURE----- Version: 2.3a iQBVAgUBLrmLVtHmcZx7ZqZtAQEFygH+OcX2HDrVh5hV3hC1Zd1ViHbqP9y2GFRV p9KN8QK7mC3L0B/gJqFTe3uqwoJmoGRE9jHPVvyaWBbHe4D91Ia6LQ== =R6dR ___--END PGP SIGNATURE----- ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Ian Lin Area: Public Key Encryption To: Jim Bell 3 Nov 94 20:45:44 Subject: export UpdReq -----BEGIN PGP SIGNED MESSAGE----- JB> Does that mean that PGP could be exported, in source code form, if it JB> was written on paper? Or, UUENCODE on paper. Does that include 1 and JB> 2-dimensional bar codes? I think it is OK to do that under your laws. You're in the U.S., right? JB> I realize that this may seem simply a make-work excercise, but JB> remember that this only has to be done ONCE for that program to exist, JB> legally, around the world. Even that's not necessary anymore. :) JB> True, recent versions of PGP are actually written outside the US and JB> brought in, but I think that we should test the principle in hopes of JB> sticking the government with an untenable position. It shouldn't be JB> necessary to do the export first: Merely ask what forms of export are JB> legal, and once told that a particular form is legal, do it. Tadum! You could even piggy back it out on the end of other data files like ARJ, ZIP, LHA or DAT (anything) or whatever. ... Insanity is hereditary; you get it from your children. ___--BEGIN PGP SIGNATURE----- Version: 2.3a iQBVAgUBLrmLSNHmcZx7ZqZtAQG7RQH/SFHQe8T6uQ8CrmYY5erWqQxtGo9T9Lw6 Emm/9TUrJQ4LvTDjZW6184aUIKIu4raDvBQPv7uAIK8CF7xDsfKCiw== =Rkah ___--END PGP SIGNATURE----- ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Ian Lin Area: Public Key Encryption To: Jim Bell 3 Nov 94 20:45:46 Subject: export UpdReq -----BEGIN PGP SIGNED MESSAGE----- JB> But there is at least a DEFINITION as to what's not allowed. On the JB> contrary, there is no specific statement in law or in regulation (as JB> far as I know) which states that certain types of encryption programs JB> are prohibited from export. What is allowed is DES. Maybe some others are allowed. It's been specified, as far as I know, that some are OK and all others are not. That includes PGP as illegal. ... Abort, Retry, Sucks, Cool huh huh huh huh ___--BEGIN PGP SIGNATURE----- Version: 2.3a iQBVAgUBLrmLOtHmcZx7ZqZtAQGFjQH7Bf8N5tS/PhIGBJHDNAVF+uDK57SCa3kE +ucG59qxk0yBqpsdF94+LESvk0ATzYGx29g7UmeB2LE7Iwp9Ty0Pnw== =qBqM ___--END PGP SIGNATURE----- ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Ian Lin Area: Public Key Encryption To: Marc Stuart 3 Nov 94 20:44:48 Subject: PGP embedded binaries UpdReq -----BEGIN PGP SIGNED MESSAGE----- MS> The version I found only handled TIFs, and I could plainly see the MS> change in the TIF file. I couldn't read the message, but I knew MS> something was there. That's quite a bit of trouble to go to. I found you can add extra info to ARJ files, and many other archivers, and never notice it during normal use of that archiver file with the program that uses it. If you make a program to extract the info, you're set. To add it to the end, you just use COPY /B IT.ARJ+IT.PGP IT2.ARJ. IT2.ARJ is a valid archive. Making a program to extract the info isn't too hard. I could do it in a second in TP. I know it's been done before to extract MOD music from a game called Star Control II. That program was GETFROM.EXE. ... Sex and coffee: a great combination, if you can find a big enough mug. ___--BEGIN PGP SIGNATURE----- Version: 2.3a iQBVAgUBLrmLJNHmcZx7ZqZtAQHdEgIAqCEuFjkPcObbjHOkoF+FMkfmz1loCVz+ kx0cl7rejTwsp3op0jHjMSljYxWd87TqVqh6G+EK48x9ueFsr8UoJQ== =Wgtw ___--END PGP SIGNATURE----- ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Ian Lin Area: Public Key Encryption To: Dan Mlodecki 3 Nov 94 20:14:50 Subject: Pgp signatures UpdReq -----BEGIN PGP SIGNED MESSAGE----- DM> Question: If no one here can certify that a user is actually that DM> user, then how can anyone trust anyone else at all? There has to be a DM> limit imposed on paranoia, for sanity reasons! Not so. You can sometimes be sure that person X who gave you a key is still person X signing for you to check with X's key. If you REALLY want trust, you meet people or otherwise verify who they are, FOR REAL. I do that. With those in positions of non-verifiability, I do not trust as much. I don't have to be over-trusting at all to retain sanity--I just halt certain communications. A PGP conversation with a complete stranger is just as dangerous as one in cleartext. ... Practice good mirth control. Use a conundrum. ___--BEGIN PGP SIGNATURE----- Version: 2.3a iQBVAgUBLrmLBdHmcZx7ZqZtAQFG2wH/e8BOZbiGHsFIpwvtVpUqGVTBW+QtmZxv igfCoAsRwCWBMP+b3MFivTpmHvY41eE1eNBwzyvRlWH+ZQeEvuCxig== =rVVq ___--END PGP SIGNATURE----- ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Ian Lin Area: Public Key Encryption To: David Mcintyre 3 Nov 94 20:44:52 Subject: PGP versions UpdReq DM> that comes through their systems, some are paranoid that encrypted DM> info _may_ have "illlegal" information, therefor they kill all messages DM> that are not readable by them (damned government). And damned sysops. I run a BBS whose specific purpose is to allow anyone using it to pass encrypte files and mail around. Some sysops around here don't allow it so if at least some do, that's a help. I don't claim to have any kind of a special BBS, just the right attitude. If the info is encrypted, it can't be proven that it's illegal so long as it's not cracked. As we aren't judges or juries, we can't legally assume or judge guilt. ... Knock soft yet firmly. Knockers should be soft and firm. ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Ian Lin Area: Public Key Encryption To: David Mcintyre 3 Nov 94 20:44:54 Subject: PGP versions UpdReq DM> yet, as I don't really have a way to send Netmail yet, and I haven't DM> gotten a version of PGP that I feel comfortable with yet. The 2.6 I DM> have now won't read all the keys that have come through the normal DM> distribution channels. I'll eventually find the 2.6ui that I'm looking DM> for, but I no longer have Internet access, and I'm not really into DM> calling LD. Oh, well. I'll be at a comfortable point eventually. Calling LD that once will not necessarily hurt. I recommend 2.3a above all others but to have 2.6ui at your side is also valuable since it can process 2.6 MIT and 2.6.1 files. I don't know what else it can handle, however. It can fake versions. PGP23A.ARJ and PGP26UIX.ZIP are online at Black IC in 613 547 6756 in Kingston, Ontario, Canada. PGP23A5E.LHA for the Amiga is also online. NO VALIDATION, NO RATIOS, NO REAL NAME REQUIRED. ... A penny saved is a Congressional oversight. ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Scott Miller Area: Public Key Encryption To: Jim Gorges 5 Nov 94 22:31:00 Subject: Embedding in Gifs UpdReq When I saw that message from John, I picked up a copy of S-Tools, it works great here, and I had no trouble hiding files in wav files. However, in order to effectively hide data in a GIF, the program reduces the colors, this does not affect the genuine appearance of the gif though. Overall its a great program. Runs in Windows BTW. ------------------------------------ Scott PGP v2.6 key available! FREQ PGPKEY ------------------------------------ KeyID: 4CA7DD5D 201434369420143436942014343694201434369420143436942014343694718 From: Jim Cannell Area: Public Key Encryption To: Shawn McMahon 16 Nov 94 18:47:12 Subject: PKZIP security UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a msg on , Shawn McMahon of 1:19/34 writes: SM> Despite the stern warnings of the tribal elders, Jim Cannell said SM> this to All: JC>> Does anyone know about a method for cracking PKZIP JC>> passwords? Is there a program (or a least an algorithm) JC>> available for this? If so, where can I get a copy. JC>> Thanks. SM> I've got one for hurling a dictionary at it quickly, but not one SM> that does actual cryptanalysis. SM> Want it? SM> You have to provide your own dictionary with it. I'll give it a try. Is it available for freq? What is the name? Jim - International SecureMail Host (ISMH) PGP key 1024/B7822B3D fingerprint = 0F F4 79 06 3B 33 99 D1 07 36 66 66 80 85 76 B3 Protect your right to privacy. Say no to GAK. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLsrHMiWTIMO3gis9AQGKaAP+Of8R5TED7FPEo/5jeaexslJ0r4M3f9IN EAIrWe3/x+svjpaW+a0tJ3e8v9+omDjlve6YnmeBLgUuHPJ45M1b/NFqfmqZ4WdS 6YPb1F6UWxt/ho58t8sWafv2eJlnZQHZ4zGFz+nSM3ConRmeIDSAeNqoMxPaZ8WW CU8MeKfyJNA= =yEvZ -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Jim Cannell Area: Public Key Encryption To: Zorch Frezberg 16 Nov 94 18:50:18 Subject: PKZIP security UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a msg on , Zorch Frezberg of 1:205/1701@fidonet.org writes: ZF> There is such a program. It was used by local police to access ZF> my PKZIPped log files in hopes of finding child pornography, ZF> credit card fraud and proof of my complicity in an international ZF> computer smuggling ring. If you find the name, it's probably available for download somewhere. ZF> Needless to say, I have not been charged with child pornography, ZF> credit card fraud nor complicity in an international computer ZF> smuggling ring. However, in the nearly 18 months that they have ZF> been holding my computer system and drives, I have been told that ZF> these will never be returned because the officers could _not_ ZF> find what they had wanted to prosecute me for. Gee, why don't I trust the government to protect me? ZF> If my sources of information are correct, the officers found one ZF> large file and tried to use the various decoders on it with no ZF> success...unfortunately, it was the STACKER.VOL file for the ZF> Stack'd hard drive. When they went to reload it, they discovered ZF> that the back-up would not operate because certain read-only ZF> files didn't copy. I do not know if this story is true, but ZF> considering the "Modem Virus" story one officer told me, I do not ZF> doubt that it could be true. ZF> The "Modem Virus" was a 'flash notice' from FBI, he said, about a ZF> virus which activated *during* modem transfers _inside_ the data ZF> stream. Another urban legend. NO way can a data stream or data file cause a problem. An infected file must be executed before it can cause damage. This situation sounds more like just plain incompetence on the part of the police. They managed to overwrite something, and were looking for an excuse to blame it on. ZF> PGP...best way to go. Agreed. Jim - International SecureMail Host (ISMH) PGP key 1024/B7822B3D fingerprint = 0F F4 79 06 3B 33 99 D1 07 36 66 66 80 85 76 B3 Protect your right to privacy. Say no to GAK. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLsrHWiWTIMO3gis9AQFjWAP/VcG+AGbf0Wzflv1wGQaAnSnvXWdpPcXm QUlhy00CU11xsu2raOzTzrtoBPomF8bYoA6pzWGF7G5RXv0VkVuL0ovebl2WGLDA S/4LYgK8ymjoHQ7OD9yOTziPLhKv3qwZ782EHlycwnbQm/tYa7QpJ0Bnn/AiKolw +sNHBpqMPLA= =I+ks -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Scott Mills Area: Public Key Encryption To: Jim Cannell 15 Nov 94 13:09:48 Subject: PKZIP security UpdReq -----BEGIN PGP SIGNED MESSAGE----- Saturday November 12 1994, Jim Cannell writes to All: JC> Does anyone know about a method for cracking PKZIP passwords? Is there JC> a program (or a least an algorithm) available for this? If so, where JC> can I get a copy. Thanks. PKZCRACK.ZIP contains to programs claiming to crack them. You can freq it from me or from 1:102/903, which is where I got it from. Scott And the conspiracy continues.... Scott Mills 1024/26CD5D03 For my PGP key freq PGPKEY sm@f119.n265.z1.fidonet.org -----BEGIN PGP SIGNATURE----- Version: 2.61 iQCVAwUBLsj55iP6qSQmzV0DAQEC3gQAscW3R3EmJL8zKCt2I8eQxNGXmNSQDeVE zdF8H8RqFTcGJvBXQETVYTJJrclcS7miPwszcUcv5+1VGpibysWCHp8Caec9Audb x2FHJ/y8gJQC9k2QBPvQPg22DHOq9wQYYVtQtpIKiJhPy7pLPHUBkX0S+SRHDVIW dpP1w3F7uyU= =RzDJ -----END PGP SIGNATURE----- --- 201434369420143436942014343694201434369420143436942014343694718 From: Scott Mills Area: Public Key Encryption To: Shawn McMahon 15 Nov 94 13:12:50 Subject: Hpack KEYCVT UpdReq -----BEGIN PGP SIGNED MESSAGE----- Friday November 11 1994, Shawn McMahon writes to jason carr: SM>>> Has anybody actually gotten KEYCVT to work on your 1024-bit SM>>> PGP keys? Worked fine for me on the 1k keys. It puked out on anything larger though. Scott SM> GP> WD> KF> JP> MM> BG> JH> MF> stop quoting this. Scott Mills 1024/26CD5D03 For my PGP key freq PGPKEY sm@f119.n265.z1.fidonet.org -----BEGIN PGP SIGNATURE----- Version: 2.61 iQCVAwUBLsj6VSP6qSQmzV0DAQE82AQAuLfOtCX25BL350ZFJ3wYHWZGJnaX7lZx Qs6LpZFJ75h/H7kKMt6vBQmGqG8aCS4oTnAQry+tt/43PjgCrc6TH+dU7zNfvqkw MVUoN0mr30EBimWikOw3OSjp6WwnBg9iRDvrnec5wMKfMGw+XJzVVFozpynCWpMh rNHE2kr9Hn0= =hshL -----END PGP SIGNATURE----- --- 201434369420143436942014343694201434369420143436942014343694718 From: Wes Landaker Area: Public Key Encryption To: Glen Todd 16 Nov 94 22:55:46 Subject: PGP and GoldEd UpdReq -----BEGIN PGP SIGNED MESSAGE----- Hello Glen! 14 Nov 94 08:46, Glen Todd wrote to Wes Landaker: GT> message containing a PGP signature but no message text. GT> I've tried various batch file configurations, but haven't GT> been able to figure out how to pass whitespace-containing GT> user IDs in the batch files. Any suggestions out there? WL> You have to output to a different file (pgp.tmp or something WL> arbitrary like that), then copy that file back to whatever WL> @file is. :) GT> That's about what I figured I needed -- I just haven't managed GT> to get a setup that will _do_ it yet. Why bother? Have Golded do the work for you! :) For example: in Golded.cfg: EXTERNUTIL 1 goldpgp.bat -seat @file "@dname" -u "@oname" and in goldpgp.bat: pgp %1 %2 %3 %4 %5 %6 %7 %8 %9 -o pgptmp.tmp copy pgptmp.tmp %2 No matter WHAT, %1 is -seat, and %2 is the filename. It doesn't matter what the rest of the parameters are, because they are passed to PGP verbatim. Assuming the names are two words long, you'll get: %3 = "MyFirst %4 = MyLast" %5 = -u %6 = "YourFirst %7 = YourLast" See? Just as long as you don't start adding TOO many things to the command line (over %9 things) you're fine. :) If you want to make different batch files for encryption, decryption, signing, etc, and @file is always the default of, golded.msg then you can hardcode those right in to the batch file. _DON'T_ try to hardcode the -u part. It _will not_ work. Because the program arguements change if the destination is one, two, or three words long, etc. =) - - - In other words: goldpgp.bat -seat golded.msg "Wes Landaker" -u "Glen Todd" will go to PGP as pgp -seat golded.msg "Wes Landaker" -u "Glen Todd" - - - and: goldpgp.bat -seat golded.msg "Wes J. Landaker" -u "Glen" will go as: pgp -seat golded.msg "Wes J. Landaker" -u "Glen" - - - as you can see, it makes NO difference. =) Give it a try, it worked for me when I was running under DOS! Right now, I've got an OS/2 REXX program doing most everything for me. wjl [Team OS/2] * 1:202/322@fidonet.org * wjl@dstorm.jd.com * * UUCP: nosc!jadpc!dstorm!wjl * PGP Key: C0E9A805 * FREQ: PGPKEY * -----BEGIN PGP SIGNATURE----- Version: 2.61 iQCVAwUBLssAzQUBVGzA6agFAQHRUgP+Mvy40blgMBqL5O7B2K+xEvHuy8GX7qBl wtetkoQj1poRq8xohNCQ987BiPSD0D3LUfGywi2v12/OMl9w/IwLYHsBXqMS1jJh zXoFe7jgdZagqXrkR9P3Q8rCuhHLlF2f8y6baB7QoVW4rkI2Prcu386O+jIsE6jY 0DX1qKiFk38= =v9nQ -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Glen Todd Area: Public Key Encryption To: jason carr 17 Nov 94 11:51:00 Subject: Re: PGP and GoldEd UpdReq * Reply to msg originally in Sysop personal mail jason carr mumbled indistinctly to Glen Todd something about PGP and GoldEd --- jc> * Forwarded from area 'PUBLIC_KEYS' jc> Pass the key ID instead: 0x________, where the underscores are jc> replaced by the Key Id characters. This method is also more likely to jc> be unique. jc> Or do you really need to use the User ID for some reason? Nope, but I'm _very_ new at this and still feeling my way around. // Glen jc> jason jc> ... I DON'T NEED NO STINKIN' TAGLINE jc> -----BEGIN PGP SIGNATURE----- jc> Version: 2.6.2 jc> Comment: PGP_ECHO: CypherEcho to the gods... jc> iQCVAwUBLsmVeUjhGzlN9lCZAQE09wP9EbgkIDm9s3xpE7b4R2udpMZKbjtyDpno jc> rTxhvi/WJyROgxJlpJ0kjDC3NVP8rpRm0mYOpW9bvk3o1JoMV5cNUqSp4lfQya1e jc> Uxezs0rgedlAa7ayaso2nwHdgSLydNGzXH3W1PKi7h3X+/7Rf6HS5CLXmRjPivJa jc> p4McqaigEJE= jc> =5jVV jc> -----END PGP SIGNATURE----- jc> ... Key fingerprint = 60 97 B2 AE 7D 90 11 2F 05 1C 35 98 E9 B9 83 jc> 61 jc> -!- CALLQ.BAT / PGP 2.6.2 / timEd 9 jc> ! Origin: FREQ JASONKEY.ASC 214.650.0382 (1:124/3208) ... Open mouth, insert foot, echo internationally. 201434369420143436942014343694201434369420143436942014343694718 From: Nolan Lee Area: Public Key Encryption To: Zorch Frezberg 17 Nov 94 07:28:34 Subject: PKZIP security UpdReq On Nov 13 17:50 94, Zorch Frezberg of 1:205/1701@fidonet.org wrote: ZF> The "Modem Virus" was a 'flash notice' from FBI, he said, ZF> about a virus which activated *during* modem transfers ZF> _inside_ the data stream. ZF> PGP...best way to go. Good software..... later, Nolan 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: Jim Bell 17 Nov 94 02:58:00 Subject: Pgp 2.6.2 official m.i.t. UpdReq On 11-13-94 (22:09), Jim Bell, in a message to David Chessler about "PGP 2.6.2 OFFICIAL M.I.T.", stated the following: JB> DC> No. There are no rules in writing. They make decisions on a case >by > DC> case basis. Since it's a national security issue they don't have >to. JB>Are you sure? Maybe it's true that they DO "make decisions on a >case-by-case basis, but I seriously doubt that there are NO regulations >concerning such things. No one has ever cited any rules. The rules are "nothing may be exported." But presumably allow exceptions "when justified", and that is judgement. JB>If there's an appeal, that appeal should be exercised, if necessary. There has been no appeal. It isn't worth the cost for a lousy disk on a book that will sell a few thousand copies. JB> DC> The ITAR people at state ruled individually on Schneider's book, >and > DC> did not give reasons for saying it could be exported. No precedent >was > DC> set. JB>Why should they have to give reasons for saying it "could be exported." Because they said it contains crypto, which they say is a munition, and because they disallowed the disk with the same substance. ___ __ chessler@trinitydc.edu d_)--/d chessler@cap.gwu.edu * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718