From: John Schofield Area: Public Key Encryption To: Shawn McMahon 29 Sep 94 08:02:38 Subject: New To Pgp UpdReq -----BEGIN PGP SIGNED MESSAGE----- --====-- SM> Despite the stern warnings of the tribal elders, John Schofield said SM> this to Gary Mirkin: JS> No current mail-reader that I know of supports a decrypt JS> function--there is no simple way to implement it. SM> Sure there is, John. It's got to be done by the reader author, if you SM> want no kludging involved at all, but I have it working with SQED/32 SM> with a little kludging. Just have to click on CHANGE, call up the SM> TOOLS menu, and click on the user-defined tool that calls my SM> decryption command file. The only reason I have to use a command file SM> at all is that I want a pause at the end, so I can see if signatures SM> verified. SM> It's as simple to implement as any other part of a reader. SM> In fact, doesn't GenMsg already support decryption? I should have been more clear in my statement. No current mail-reader that I know of supports the decrypt function, although it would be easy for the mail-reader author to implement. Thus, there is no simple way to implement a decrypt function. GenMSG is not an off-line mail-reader. It is a SysOp mail reader--users can't use it. I'm not familiar with SQED/32. Please tell me more about it. JMS -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLorVCWj9fvT+ukJdAQEXZgP/Y2gX4pOo4KCxktn41G813CZUBSHwc0lB Eu/+k/V9GRI4l95BqHNrXSWDg6a6d2Nv3Bf3c/Gjt6GYJZGcNJnt+DXCR5+07Q87 Ga4ARV6pfDUEk0sMjrplPjuSzXLEAbicovc6tHEAimK1kAVaVVVYYicTbRfIijjN BiFxFm+6TsM= =iryO -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... Privacy is a sacred right. 201434369420143436942014343694201434369420143436942014343694718 From: Walt Haefner Area: Public Key Encryption To: Jeff Hancock 29 Sep 94 22:22:38 Subject: There goes more freedom! UpdReq -----BEGIN PGP SIGNED MESSAGE----- -=> Jeff Hancock was saying something about There goes more freedom! JH> A reliable message poster left this on my system. Thought I would JH> share it with you. JH> ----------------------------------------------------------------------- JH> - (UPI) WASHINGTON, DC. The White House confirmed today that the FCC JH> will become the Federal agency to assume responsibility for regulating AP> =snip= Well, seeing as how the responder snipped the rest of this, and I didn't see the original (musta been one of my "no mail daze" ), could you repost the article, either here, or through Net-mail? ANYTHING the Gov't wants the FCC to regulate.... I want to know about! TIA! -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLoZtOHNdSyItpAJBAQH/EQP/X7vvtbSFRqaWTshh5Dkl7J6wex1+iEUK Tt8zVbkPaK5nWwUu8GagCC74tAT0cMfZ8yxOYfWf88B0sC8bDHUhsd+nvnXrf7Q5 giHNMh3v97CA2HJPltT6CqwWMArzfqLWOZ4vLH+fw3uGjpHyuMqlwTHfh3jZgNGX nYZOz+85XGk= =N1LX -----END PGP SIGNATURE----- ~~~ PGPBLUE 2.5 -={ WALT }=- PGP Key Fingerprint: 1C 8D EF 9B 5E 51 75 EE BA 69 F2 BE 05 A7 AF 49 --- PGP KEY AVAIL. ON REQUEST Censorship: The reaction of the ignorant to freedom. 201434369420143436942014343694201434369420143436942014343694718 From: Carl Hudkins Area: Public Key Encryption To: Christopher Baker 1 Oct 94 08:21:00 Subject: Oops! UpdReq 28 Sep 94 20:09, Christopher Baker wrote to Carl Hudkins: CB> just curious about your multiple Origin personality. are you CB> pointing out of two different Nets? summer and winter homes? TDY CB> bases? [grin] Actually, I only point from here. The long-distance calls to Texas are for stuff I can't get here -- RIME, Usenet, etc. and some Fido echos that aren't warranted by the small user base we have here in the Key West area. I include my Netmail address there for the sake of completeness. (Though my boss here has just picked up PKEY_DROP -- yay! Now I just have to figure out the PGP vs. GoldEd thing.) I suppose I should update my signature for use from my point... carl Boca Chica, Florida carl.hudkins@lunatic.com RIME ->1282 PGP: 2D1E1E39 Fido: 1:135/808.1 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Jim Grubs, W8GRT 2 Oct 94 09:58:20 Subject: UUE messages UpdReq Jim Grubs, W8GRT wrote in a message to jason carr: > Is there a security risk involved? Or a risk of > grunging the keyring or > what? JGW> Nothing sinister. It's just that PGP checks the ring from JGW> beginning to end, right? therefore, it comes first to the JGW> more recent one first. Ahh, ok. I went ahead and ran it, and liked the results. :\ jason ... Click mousie...Drag mousie...KILL. KILL. KILL. Muwwahahahah. 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: Shawn Mcmahon 30 Sep 94 19:29:00 Subject: Key revocation UpdReq On 09-25-94 (16:51), Shawn Mcmahon, in a message to Alan Pugh about "KEY REVOCATION", stated the following: SM>If you have a revocation certificate on a floppy, an attacker who gets >that floppy can just revoke your key. Just send that certificate out >far and wide, and generate his own phony replacement. And there's not a >lot you can do about it, because you "signed" that revocation when you >created the certificate. Encrypt your revocation using conventional encryption: pgp -c this protects against anything but a lost passphrase. You can encrypt a copy using every passphrase you ever use (at some loss in security). Then you can have copies of the encrypted revocation all over the place and no one can do anything with them so long as they don't have your passphrase. The weakness with multiple pass phrases is that one of them may be discovered. This is also a strength, since discovery of one pass phrase doesn't change the others. What you do if your key has been corrupted or lost is generate a new key with as many of the same signatures as possible. Thus, if someone is spoofing you, unless he can convince the same people to sign his key, yours will be the more credible. I understand that there are at least three keys purportedly from David Sternlight (a well-known flamer on sci.crypt, alt.privacy, etc.) on the servers. Also, there are a couple of false keys claiming to be from Philip R. Zimmermann. You have to check signatures. ___ __ chessler@trinitydc.edu d_)--/d chessler@cap.gwu.edu * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: Shawn Mcmahon 30 Sep 94 19:36:00 Subject: Need recommendations UpdReq On 09-26-94 (09:26), Shawn Mcmahon, in a message to Dan Wilson about "NEED RECOMMENDATIONS", stated the following: SM>However, it will take extraordinary measures. Since I used SFS instead >of SecureDevice, they'll have to use a special program to do it. >(Instead of just PKZIPping the darn thing onto multiple floppies, as you >could do if it was a SecureDevice file. That is, if I'm reading the >SecDev docs properly.) Check RAWDSK11.ZIP on ftp://ftp.uni-duisburg.de/pub/pc/misc/rawdsk11.zip I think I also saw it on ftp://sunsite.unc.ecu/pub.linux.system/install/ where I found fips111.zip, or ftp://garbo.uwasa.fi/pc/diskutil This will permit you to identify starting and ending cylinders, and treat the entire partition as a file. It's used for backing up linux partitions and other partitions from operating systems where there are no backup utilities, so you must use a streaming backup without reference to the content or structure of the partitions. ___ __ chessler@trinitydc.edu d_)--/d chessler@cap.gwu.edu * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: Scott Mills Area: Public Key Encryption To: John Schofield 1 Oct 94 14:16:30 Subject: Bug in PGP signatures UpdReq -----BEGIN PGP SIGNED MESSAGE----- Wednesday September 28 1994, John Schofield writes to All: JS> The mathematical methods PGP uses to check signatures (the MD5 algorithm) JS> are not affected by this bug, and are apparently still strong. I just tested that on the OS/2 version by the Rebellious Guerilla. Some problem on that as well. Scott He is dead, he is damned, he is WEDDED!! Scott Mills 1024/26CD5D03 For my PGP key just send NetMail with Return Receipt Request flag on. sm@f119.n265.z1.fidonet.org - --- -----BEGIN PGP SIGNATURE----- Version: 2.61 iQCVAwUBLo2oOiP6qSQmzV0DAQGuZAQAiIvv/UcNe+14NoQqBYXntf/OmJUGuovz CeM6sHTLx3V4+0pHVQPbIjYIIOuAyD6JdYdF5zLMNDVLk5DHoyWb+c7c75o2nUHW WAJLyhjqbBNXsReAv/fqWee0VAqhQ6QK00iHQveZnJNH+CBZ6HCVn4ROW02ZvQEP OcSoDz+Hu7o= =S/kQ -----END PGP SIGNATURE----- --- 201434369420143436942014343694201434369420143436942014343694718 From: Mike Deaton Area: Public Key Encryption To: All 1 Oct 94 13:13:34 Subject: The Public Key of: Mike Deaton UpdReq -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAi5vtwwAAAEEAKc11k/oKSYzTr2wAuYt8vCv4HIBl5eRavzY1ZQcQ7RNMFdN 3TVpOo7EVcZjJj5Trl78IB+g34AMBwFrPnJ6B42MS8oa2A2WWF6NDhvrn1S0COsb u4/oiEZcgWWcMkl4fkIvffR+6ksFzi4oJkZblf8HEwuu35JUdI6PhBEK8B6ZAAUR tBptaWtlIGRlYXRvbiA8NzA2LTI5NS03ODk2Pg== =b5yi -----END PGP PUBLIC KEY BLOCK----- ~~~ PGPBLUE 3.0 201434369420143436942014343694201434369420143436942014343694718 From: Rob Buckman Area: Public Key Encryption To: All 2 Oct 94 14:44:00 Subject: The National Research Council study of National...UpdReq * Originally By: CRYPTO * Originally To: All * Originally Re: The National Research Council study of National... * Original Area: ALT.SECURITY.PGP * Forwarded by : Blue Wave v2.12 From: crypto@nas.edu (CRYPTO) Subject: The National Research Council study of National... Organization: UTexas Mail-to-News Gateway Subject: The National Research Council study of National Cryptography Policy Please redistribute this note to any party that you think might be interested. thanks. A STUDY OF NATIONAL CRYPTOGRAPHY POLICY September 14, 1994 Cryptographic technologies are critical to a wide variety of important military and civilian applications involving sensitive or classified information that must be protected from unauthorized disclosure. In addition, cryptography is a key component of most authentication technologies, i.e., technologies to guarantee the identity of a message's sender. National cryptography policy has important implications for U.S. economic competitiveness, national security, law enforcement interests, and protection of the rights of private U.S. citizens. In an attempt to clarify some of the relevant policy issues, Public Law 103-160 (passed by the U.S. Congress in November 1993) called for a comprehensive study from the National Research Council on cryptographic technologies and national cryptography policy. The study will commence in the first week of October 1994. As this study proceeds, the committee will make all feasible attempts to solicit a wide range of input and commentary from interested parties. Input will be presented to the committee through a mix of briefings, presentations, consultations, invited and contributed papers, and testimony at regional public hearings. In addition, members of the interested public are invited to submit input to the committee as described below. The study plans to address the following issues: * the impact of current and possible future restrictions and standards regarding cryptographic technology on - the availability of such technology to foreign and domestic parties with interests hostile to or competitive with the national security, economic, commercial, and privacy interests of the U.S. government, U.S. industry, and private U.S. citizens; - the competitiveness of U.S. manufacturers of such technology in the international market; - the competitiveness and performance of commercial U.S. users of such technology; - U.S. national security and law enforcement interests; * the strength of various cryptographic technologies known and anticipated that are relevant for commercial and private purposes; * current and anticipated demand for information systems security based on cryptography; * the impact of foreign restrictions on the use of, importation of, and the market for cryptographic technology; * the extent to which current cryptography policy is adequate for protecting U.S. interests in privacy, public safety, national security, and economic competitiveness; * strengths and weaknesses of current key escrow implementation schemes; * how technology now and in the future can affect the feasible policy options for balancing the national security and law enforcement interests of government and the privacy and commercial interests of U.S. industry and private U.S. citizens; * recommendations for the process through which national security, law enforcement, commercial, and privacy interests are balanced in the formulation of national cryptography policy. The study will be conducted by a 17-member committee (listed at the end of this document) that collectively has expertise in computer and communications technology; cryptographic technologies and cryptanalysis; foreign, national security, and intelligence affairs; law enforcement; science policy; trade policy; commercial and business dimensions of computer technology (hardware and software vendors, users of cryptographic technologies); and interests in privacy and civil liberties. A subpanel of the full committee will be cleared at the SI level and have access to all relevant information to ensure that the findings, conclusions, and recommendations of the unclassified report are consistent with what is known in the classified world. The project plan calls for the study to be delivered approximately two years after full processing of all necessary security clearances. However, the NRC will make every attempt to deliver the study sooner, and it currently believes that the core work of the study will be completed about 18 to 20 months after funding for the study has been received. Additional time will be devoted to dissemination of the study report and follow-up activities. The final report of the study committee is subject to NRC review procedures that ensure the objectivity and integrity of all NRC reports. The main text of the report will be unclassified; classified annexes (if any) will be made available only to those with the appropriate security clearances. PROVIDING INPUT TO THE COMMITTEE The questions that the study is expected to examine are provided above. Members of the interested public are invited to submit their views on these questions and any other questions that you believe the committee should be addressing through either of the channels below. If desired, requests for personal presentations to the committee should be submitted through these channels as well; the committee will respond affirmatively to as many such requests as possible, but time and resource constraints will limit the number of such requests that can be honored. Internet: send comments and other correspondence to CRYPTO@NAS.EDU. U.S. Mail: Cryptography Project Computer Science and Telecommunications Board National Research Council Mail Stop HA-560 2101 Constitution Avenue, NW Washington, DC 20418 COMMITTEE TO STUDY NATIONAL CRYPTOGRAPHY POLICY Kenneth Dam, committee chair, was Deputy Secretary of State (1982- 1985) and is currently the Max Pam Professor of American and Foreign Law at the University of Chicago Law School. General W. Y. Smith, retired, committee vice-chair, is president emeritus of the Institute for Defense Analyses, and has also served in a number of military posts including that of deputy commander in chief of the U.S. European Command in Germany. Lee Bollinger, formerly dean of the University of Michigan Law School, is currently provost of Dartmouth College and a constitutional scholar. Ann Caracristi, retired, was Deputy Director of the National Security Agency (1980-1982). Benjamin Civiletti was U.S. Attorney General (1979-1981), and is currently in private practice with the law firm Venable, Baetjer, Howard and Civiletti. Colin Crook is senior technology officer for Citicorp. Samuel Fuller is vice president of corporate research at Digital Equipment Corporation. Leslie Gelb is president of the Council on Foreign Relations. He served as Assistant Secretary of State for Politico-Military Affairs (1977-1980). Ronald Graham is a director of information sciences at AT&T Bell Labs and a professor of mathematics at Rutgers University. Martin Hellman is professor of electrical engineering at Stanford University. Dr. Hellman was one of the inventors of public key encryption. Julius Katz is president of Hills & Company, and was deputy United States trade representative (1989-1993). Peter Neumann is principal scientist in the Computer Science Laboratory at SRI International. He is the chairman of the ACM committee on computers and public policy, and a member of the ACM study group on cryptography policy. Raymond Ozzie is president of Iris Associates, a wholly-owned subsidiary of the Lotus Development Corporation. Iris Associates is the developer of Lotus Notes. Kumar Patel is vice chancellor for research at UCLA. Edward Schmults was Deputy Attorney General of the United States (1981-1984) and is a former senior vice president for external relations and general counsel for the GTE Corporation. Elliot Stone is executive director of the Massachusetts Health Data Consortium, which is responsible for the collection and analysis of the state's large health care databases. Willis Ware, retired, is with the RAND Corporation as senior computer scientist emeritus. He chairs the Computer System Security and Privacy Advisory Board which was established by the Computer Security Act of 1987. STAFF AND ORGANIZATIONS Marjory Blumenthal is director of the Computer Science and Telecommunications Board (CSTB). Herbert Lin is study director and senior staff officer of the CSTB. Inquiries about this study should be directed to him at 202-334-3191 or via Internet at HLIN@NAS.EDU. The National Research Council (NRC) is the operating arm of the Academy complex, which includes the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine. The NRC provides impartial and independent advice to the federal government and other policy makers, by applying top scientific and technical talent to answer questions of national significance. In addition, the NRC often acts as a neutral party in convening meetings among multiple stakeholders on various controversial issues, thereby facilitating the generation of consensus. Within the NRC, the CSTB considers technical and policy issues pertaining to computer science, telecommunications, and associated technologies as critical resources and sources of national economic strength. A list of CSTB publications is available on request to CSTB@NAS.EDU or by calling 202-334-2605. 201434369420143436942014343694201434369420143436942014343694718 From: gk pace Area: Public Key Encryption To: Christopher Baker 2 Oct 94 14:50:36 Subject: Clear-Signed "Hole" UpdReq -----BEGIN PGP SIGNED MESSAGE----- This reported problem is expected to be fixed, with the release of 2.6.2, which is anticipated to be available within two weeks. There will be some additional enhancements as well. Look for the release sometime after this coming thursday. -gk -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: Fight to keep the Basic Human Right of Privacy! iQCVAwUBLo8A9Y9JNB7uOPtBAQH5iwP+PhMi+a7f9v5S0CMQWNwKruJuIfhJJv// hkfF2a4w4UwQu2at6dKlZgIFk3n2p/vosI+k+tABSITsJ0TNX9neaSjFhmCB0TK7 /8tO9DD2r7CtfJtKECYeEbrOZZ6nby4El1J9t20P2Rmazwe5UynwPdRksQ99WE+I jZNuLtAhlr8= =O31v -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: Gk Pace 2 Oct 94 17:36:14 Subject: Re: Clear-Signed "Hole" UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 02 Oct 94, Gk Pace was quoted as saying: GP> This reported problem is expected to be fixed, with the release GP> of 2.6.2, which is anticipated to be available within two weeks. it's not an actual problem after verification anyway. any extraneous stuff added before the blank line will simply disappear from the output when verfied, right? it just looks like a hole but is actually just burp? GP> There will be some additional enhancements as well. great. GP> Look for the release sometime after this coming thursday. this is an official release you're talking about, yes? thanks. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLo8n0MsQPBL4miT5AQEkTQP9F+4YXF1hM18bVGUzFuiXaUjfPjrZZ+k5 k0m1pBqzfEFPJID0ZzJhsE6ZT6/iEMoiK8auGElkJ0RVzk3z56Rk6Yn8AkGkMrAA adXItcyElma4JowHBC9LB/wLyTgRHqjQyl3pc/eqOe0YuXQFLTugxZq8CQr8gdUJ oISolxFpt8Y= =QBVO -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 2 Oct 94 17:41:36 Subject: PUBKEYS hatches UpdReq -----BEGIN PGP SIGNED MESSAGE----- the following have just been hatched into PUBKEYS file distribution: GMSG420.ZIP GenMsg for DOS. Reader/editor interface for PGP/SMH/uucp. Direct from the author. [GENMSG] [90K] GMSG2420.ZIP GenMsg for OS/2. PGPBLU30.ZIP PGP/BlueWave interface for PGP use inside BlueWave for DOS. Direct from the author. [PGPBLUE] [37K] PBLOS230.ZIP PGPBlue for OS/2. [40K] all PUBKEYS links please poll. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLo8pE8sQPBL4miT5AQGbKAQAlTc0THj4Qj/ql/Ng15Ok+eflvXT2vud6 cLYwakY4sxYDebuASsHU/HWOHd4uO36atK0eo9ZjuQ3Nu64HyYB6U/7SOTNxuGRy jsDohk5ZWIPHMd+pHRS3+CPGkYRAIkrdk/lMvXUsj4trHoKdqwhrdb1ebnaKFO+T mUWBd31RCOs= =BjDZ -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Jackson Harding Area: Public Key Encryption To: jason carr 2 Oct 94 20:16:00 Subject: PGP Signatures UpdReq Hello jason! Saturday September 24 1994, jason carr writes to all: >> I suggested to one PGP-booster that they should put the >> signature in kludge lines. If they did that, most readers >> would never see it and I would have no objection. However, >> it appears that PGP is pretty inflexible about the format of >> the signature, so this wasn't possible. jc> What do you guys think about this idea? The data is still there, they are still moving the same amount of information, more even by the time you add the kludges. The kludge lines also run the risk of stuffing up the signiture preventing correct validation. Bye for now, Jackson 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: John Nieder 3 Oct 94 16:43:04 Subject: Securemail UpdReq Despite the stern warnings of the tribal elders, John Nieder said this to mark lewis: JN> Sysop's response is that it's too much trouble to change the JN> outgoing netmail destination, even though it's a local call JN> to the SECUREMAIL hub. No further explanation seems to be JN> forthcoming. Then keep sending your mail through him. He's the one that'll get in trouble for it, so if he wants to stop getting in trouble he'll take the 30 seconds it takes to fix the problem. 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Tim Bradley 3 Oct 94 16:47:18 Subject: RC4 Revealed! UpdReq Despite the stern warnings of the tribal elders, Tim Bradley said this to Shawn McMahon: TB> You're welcome, as long as your point was that the original TB> article was unclear and only marginally significant in terms of TB> actual industry impact Actually, my original point was this: That the original article was unclear, and that the author's evident unfamiliarity with the subject matter was going to lead to lots and lots of posts from people who were confused by his poor choice of wording. I hadn't addressed the potential industry impact, but I agree with you that it's going to be marginal and further I postulate that it will consist almost entirely of short-term loss of sales for RSADI, and only small losses at that. Hell, anybody relying on RC4 to protect their data deserves what they get. :-) 201434369420143436942014343694201434369420143436942014343694718 From: Rick Pali Area: Public Key Encryption To: Carl Hudkins 2 Oct 94 22:55:28 Subject: PGP keyring sorting UpdReq *** Answering a msg posted in area PKEY_DROP (PKEY_DROP). CH> BTW, I see you use GoldEd. I've been playing with CH> version 2.41, and I fail to see how to get it to quit re-wrapping CH> stuff I compose in an external editor. Do you use PGP with Gold? CH> If so, how did you overcome that difficulty? To be honest, I use the internal editor and I don't send a lot of encrypted mail. I'm afraid I don't have an answer to your question. Have you tried the GOLDED echo? Rick. 201434369420143436942014343694201434369420143436942014343694718 From: Peter Bradie Area: Public Key Encryption To: Shawn Mcmahon 30 Sep 94 21:33:00 Subject: New indecency rules propo UpdReq -=> Quoting Shawn Mcmahon to Peter Bradie <=- SM> Even so simple an act as writing your Congresscritter a letter can SM> work wonders; they're very sensitive to complaint mail. I'm waiting for our Congresscritters to get on line for e-mail.:-) Obvious form letters don't have that much effect upon 'em, but a well thought-out letter can have a tremendous impact. They figure each letter represents a very large number of their constituents that feel the same way, vote, but don't bother to write. ... Nothing will preserve liberty but downright force.- Patrick Henry ... Blue Wave/QWK v2.10 201434369420143436942014343694201434369420143436942014343694718 From: Peter Bradie Area: Public Key Encryption To: Shawn Mcmahon 30 Sep 94 22:23:00 Subject: Need recommendations UpdReq -=> Quoting Shawn Mcmahon to Edwin Teh <=- SM> Direct physical access, probably over the weekend when nobody's there. SM> No threats likely, but then there's not a blessed thing I could do to SM> the data to secure it against that short of actual physical SM> destruction. :-) Perhaps I missed something a way back, but there are ways of encrypting files, or whole directories, for that matter. If encrypted, it may keep the malefactor rather busy over the weekend trying to crack it. ... It is dangerous to be right when the government is wrong. Voltaire ... Blue Wave/QWK v2.10 201434369420143436942014343694201434369420143436942014343694718 From: Glen Todd Area: Public Key Encryption To: Walt Haefner 3 Oct 94 14:44:00 Subject: There goes more freedom! UpdReq Green things and saladations, Walt! 29 Sep 94 22:22, Walt Haefner wrote to Jeff Hancock: JH>> - - (UPI) WASHINGTON, DC. The White House confirmed today that the JH>> FCC will become the Federal agency to assume responsibility for JH>> regulating AP>> =snip= WH> Well, seeing as how the responder snipped the rest of this, and I didn't WH> see the original (musta been one of my "no mail daze" ), could you WH> repost the article, either here, or through Net-mail? WH> ANYTHING the Gov't wants the FCC to regulate.... I want to know about! Anything that the government wants _anybody_ to regulate, I want to know about. Wind to thy wings, Glen 201434369420143436942014343694201434369420143436942014343694718 From: mark lewis Area: Public Key Encryption To: John Nieder 3 Oct 94 00:07:28 Subject: Securemail UpdReq ml> the solution you are looking for is the one that the SysOp has to ml> provide. ml> talk to your sysop... if you can persuade him to reconfigure then ml> you'll have the "problem" licked... JN> Sysop's response is that it's too much trouble to change the JN> outgoing netmail destination, even though it's a local call JN> to the SECUREMAIL hub. No further explanation seems to be JN> forthcoming. sounds to me like it is time to vote with your feet and get an account on the SECUREMAIL system if you can. might want to let others know but in a quiet, easy going manner... JN> Disgusting. i agree... BTW: it's not that hard for him to add or change one or two lines in his routing file... that's all it'd take... )\/(ark # Origin: (1:3634/12) * Origin: PODNet <-> FidoNet EchoGate! (93:9600/0.0) SEEN-BY: 107/946 147/1077 153/9125 259/212 382/7 640/217 3611/19 9600/0 SEEN-BY: 9608/0 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Jackson Harding 3 Oct 94 21:27:58 Subject: PGP Signatures UpdReq Jackson Harding wrote in a message to jason carr: JH> The data is still there, they are still moving the same JH> amount of information, more even by the time you add the JH> kludges. The kludge lines also run the risk of stuffing up JH> the signiture preventing correct validation. I don't know enough about it to say whether or not validation would be grunged, but I don't think many people read the mail with the kludge-viewer on. At any rate this was a moderator saying one way he would tolerate sigs. jason ... I got arrested in LA and boy am I beat. 201434369420143436942014343694201434369420143436942014343694718 From: Alan Pugh Area: Public Key Encryption To: Shawn McMahon 1 Oct 94 16:19:22 Subject: Key Revocation UpdReq -=> Shawn McMahon was saying something about Key Revocation SM> Despite the stern warnings of the tribal elders, Alan Pugh said this SM> to Tim Devore: AP> next time you create a key pair, copy your keyrings to alternate AP> files, then create a revocation certificate and copy the pgp AP> directory to a floppy and write protect it. (make two copies if AP> you believe in murphy as much as i do.) SM> SM> If you have you secret key on a floppy, an attacker who gets the SM> floppy has to either try brute-force search of the keyspace, or know a SM> way to crack MD5. (Which might be possible; one of it's design goals SM> was avoiding collisions, and it now appears that it has them. I don't SM> know of any proof yet that there is an easier way to crack it than SM> brute force, however.) SM> If you have a revocation certificate on a floppy, an attacker who gets SM> that floppy can just revoke your key. Just send that certificate out SM> far and wide, and generate his own phony replacement. And there's not SM> a lot you can do about it, because you "signed" that revocation when SM> you created the certificate. true, but a revoked key is a lot less dangerous than a lot of things. if someone took posession of a floppy with my keys, the _first_ thing i would do is revoke the key in any case. i have direct communication links with many of the people i send secure mail with anyway, so re-destributing a new key wouldn't be such a big deal. i have pass phrases worked out with a couple of those it would be _critical_ to make sure of authenticity of keys. the likelyhood of me forgetting a passphrase is pretty minimal in any case. i suggest creating revokation certificates for new users who might not be quite as immersed into the pgp thing as i am. good points though, amp <0003701548@mcimail.com> ... Copper wire came from two lawyers arguing over a penny. 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Jackson Harding 3 Oct 94 10:23:00 Subject: PGP Signatures UpdReq -----BEGIN PGP SIGNED MESSAGE----- Jackson Harding wrote in a message to Joe Noel: JH> I allow signatures, I don't see that encrypted echomail JH> serves any purpose, if you want to send encrypted mail why JH> not send it direct to the recipient via netmail? A particular msg can be encrypted with the keys of more than one recipient. JH> No, an encrypted message is an encrypted message, a JH> signature is a digital construct made from the text of the JH> message and the secret key of the person signing the JH> message. This uniqueness lets you confirm that the person - From the docs: (pt 1) ... used to detect changes in the message. Unlike a CRC, however, it is computationally infeasible for an attacker to devise a substitute message that would produce an identical message digest. The message ^^^^^^^^^^^ digest gets encrypted by the secret key to form a signature. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... JH> claiming authorship is the person who holds that secret key JH> and that the message has not been altered since signing. It JH> does not contain any hidden text or useful information and JH> is usually deleted by programs that verify sigs. All it adds It contains =very= useful info: an encrypted msg digest. JH> is extra bytes to the message. And since you can still read JH> the entire message, and nothing is hidden, how can the JH> message be said to be encrypted? Didn't say that. But it does include ciphertext. JN> Further, does anyone that uses PGP happen to know (or can test for me), if JN> a person already has the correct signature (possibly sent in another JN> message), could they actually put the message where the signature should JN> be and then the receiving person just edit the message stripping the old JN> PGP SIGNATURE lines add the correct signature back to the bottom? To me JN> it looks like it would be easy to do. JH> I'm sorry what exactly do you mean here? Each signature is JH> unique for each message and secret key. If I sign two JH> different messages the signatures will be different and if JH> two people sign the same message with their own secret keys JH> then those signatures would differ also. Someone could IOW, could you encrypt a short msg, and sub it for the sig block. The answer is yes, although the reciever would have to diddle with it to decode. It would not verifiy as a sig, and anyone with the author's pubkey could tell call him on the discrepancy. jason ... champagne corks are firing at the sun again -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP_ECHO: Encryption, sigs, and fun in D-FtW... iQCVAwUBLpA/lEjhGzlN9lCZAQEi5QP+MVMSkFFza3INIKOUXo6r+gyjCATYmluF WwcRF0IS7GE5zQqwWgs/wKP7IiCU/TIcB87shi80ykMfDTgtXuDBKS81jwBd4TBc jRLV1srsqU6neHvC2ABZmfk6ayfC9KXE0OsFTcSoNIMRqY9jClzLexgJo3QIzUti dgm+p5VAdQU= =Vgln -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: John Schofield 4 Oct 94 11:41:54 Subject: New To Pgp UpdReq Despite the stern warnings of the tribal elders, John Schofield said this to Shawn McMahon: JS> I should have been more clear in my statement. No current JS> mail-reader that I know of supports the decrypt function, JS> although it would be easy for the mail-reader author to JS> implement. Yes, but you're still wrong. You're still saying "mail-reader" when you mean "offline mail reader." JS> GenMSG is not an off-line mail-reader. True. I don't know of an offline mail reader that has PGP support built in. However, since most of them rely on an external editor anyway, putting the PGP support into the reader instead of in an external program would reduce flexibility at worst and needlessly complicate the author's job at best. Why do it? Leave it external, and you don't have the code for it taking up memory for people who don't need it. 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: David Chessler 4 Oct 94 11:37:50 Subject: Key revocation UpdReq Despite the stern warnings of the tribal elders, David Chessler said this to Shawn Mcmahon: DC> etc.) on the servers. Also, there are a couple of false keys DC> claiming to be from Philip R. Zimmermann. You have to check DC> signatures. Not to mention the ones for Clinton and Gore that are floating around. 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Peter Bradie 5 Oct 94 01:31:30 Subject: Need recommendations UpdReq Despite the stern warnings of the tribal elders, Peter Bradie said this to Shawn Mcmahon: PB> Perhaps I missed something a way back, but there are ways of PB> encrypting files, or whole directories, for that matter. Yep, ya missed something. :-) I have a partition on the client's drive encrypted with SFS. I've admonished him to put all his data files on that partition. Further, deponent saith not. 201434369420143436942014343694201434369420143436942014343694718