From: Jim Bell Area: Public Key Encryption To: IAN LIN 4 Nov 94 00:01:00 Subject: PGP 2.6.2 Official M.I.T UpdReq -=> Quoting Ian Lin@1:249/146.0 to Jim Bell <=- JB> If the government said, "You can't export a program that can be JB> modified to do good encryption," then the proper answer is that ANY JB> program can be modified to do good encryption, with enough changes. IL> I bet anything we'd be told then that all encryption is now banned. :) IL> Ya, it's not what we want, but you know how government is. :) So do IL> you use PGP? I use PGP 2.3a (I refuse to use the MIT versions). I best IL> let my key off here so people can check my signatures in the future. I occasionally use PGP2.3a, but mostly experimentally. I have no active need for encryption, but I still keep up with it...just in case. ... Way Too Much is Not Nearly Enough. ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Jim Bell Area: Public Key Encryption To: All 4 Nov 94 00:01:00 Subject: Encryption Review Urged UpdReq Electronics Engineeering Times, October 3, 1994, page 22 [see my comments below; JB] "Encryption review urged" by George Leopold Washington-- Congress should consider postponing further deployment of the Clinton administration's proposed key-escrow encryption plan while reviewing U.S. cryptography policy, the congressional Office of Technology Assessment (OTA) has recommended in a new study. "An important outcome of a broad review of national cryptography policy would be the development of more-open processes to determine how cryptography will be deployed throughout society," concludes the study, "Information Security and Privacy in Network Environments." The option to delay implementation of the key-escrow plan, which focuses on the controversial Clipper chip, is one of a series contained in the OTA report. Others include congressional scrutiny of the relationship between the two prime movers behind Clipper, the national Security Agency and the National Institute of Standards and Technology.; the need for legislation to ensure openness in implementing encryption policy; and creation of a Federal Privacy Commission. Congress entered the fray over Clipper when it directed the National Research Council to conduct a broad study of U.S. cryptography policy. However, work on the study was delayed and, according to OTA officials, results won't be availalbe until 1996. As a result, the OTA study cautioned that "given the speed with which the Clinton administration is acting, information to support a congressional policy review of cryptography is out of phase with the government's implementation of key-escrow encryption." [Note 1] The Clipper initiative unveiled in February (see Feb 14, page 4) has drawn widespread criticism from industry and civil liberties groups who view it as a threat to computer privacy and U.S. economic competitiveness. [Note 2] Critics are also wary of the classified Skipjack algorithm at the heart of Clipper, maintaining that public-key encryption technology is sufficient to ensure network security. Administration officials counter that Clipper is the best technology available [Note 3] and that Clipper is a voluntary standard. [Note 4] Acknowledging industry's concerns, Vice President Al Gore in July pledged a new phase of cooperation on encryption policy among government, industry and privacy groups. The OTA study was requested in May 1993 by Sen. William Roth, R-Del, who is planning hearings on the Clipper controversy and to propose amendments to the Computer Security Act when it is reviewed next year. Roth said in a statement that the OTA report "underscores the fact that much more work must be done." Sen. John Glenn, D-Ohio, said, "we must recognize that new technologies, particularly the development of computer networks, are leapfrogging security and privacy controls designed for a simpler time." Glenn, who is chairman of the Senate Governmental Affairs Committee, said, "In the next Congress, this committee will continue its oversight of agency operations and will pursue legislation to ensure that government agencies handle data from citizens and businesses responsibly." ++++++++++++++ end of article +++++++++++++++++++++++ Note 1: In other words, the governmental decision to have a "Clipper-like" chip was itself highly premature, suggesting that the government simply wished too foist a bad idea on the public without any public consideration or challenge. Note 2: This vast opposition from all corners of the country was in stark contrast to the bootlicking obedience displayed by statist apologists like John Ginnane. Note 3: This is a extreme misrepresentation of the facts. The Clipper chip may be the best hardware implementation of encryption available at this instant, but that's only because the government secretly (and without Congressional authorization) spent money on the project. A substantially better chip could be quickly implemented with none of Clipper's negatives: No "key-escrow" system; Open architecture and algorithm; longer key-length; Data does not identify the source or destination of the conversation. Note 4: Calling Clipper "voluntary" is tantamount to the Newspeak in Orwell's book, "1984." By designing and developing the Clipper chip, the government was secretly using taxpayer funding to try to subsidize the development of a standard that is intended to exclude other products (and standards) from the market. It is trying to prevent the average citizen from being able to buy products using competing technology. The effect is like that of a furtive thumb placed on one pan of a balance, in order to make it swing the right direction. Had Clipper not met with massive, almost uniform opposition, it might have accomplished this goal. In my opinion, for a cryptography standard to be properly termed "voluntary," individual citizens must have the ability to select a non-key-escrowed system with no compatibility penalty. (In other words, a citizen should never be induced to buy a key-escrowed system because the non-key-escrowed systems can't talk securely to the majority standard.) Further, the government should not be able to determine, simply by monitoring the data, who is using key-escrowed encryption and who is using good encryption. Further, and ideally, even if they willingly buy encrypted telephones with key-escrow function, individual citizens should be able to switch off this "feature" instantly (undetectable by the government) should the political situation in the country change to warrant such a move. The real goal of Clipper's key-escrow system is a government "ace in the hole" with which they can, secretly and essentially overnight, begin to monitor citizens' activities, ostensibly in response to some sort of "crisis" situation. It is in the interest of the average freedom-loving citizen to ensure that the government's path to authoritarianism or totalitarianism is as long and difficult as possible. ... Just say no to Clipper/Capstone/NSA ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: John Stephenson Area: Public Key Encryption To: Jim Bell 3 Nov 94 22:12:56 Subject: PGP 2.6.2 Official M.I.T. UpdReq JS> It would probably work like guns in the states. JS> You can't buy a weapon JS> that can be more easily turned into a automatic JS> gun, than building one JS> yourself. Same with something like PGP. JB> First, I think you have misinterpreted the rules concerning guns. JB> Plenty of semi-auto guns can be modifed to full-auto. "Easily" is not JB> particularly definitive. Yes. It's defined. Easier than building one from scratch. Meaning, they make semi's impossible for most people to convert. Even people experienced will tell you it can't be done -- easily, as in "difficult". 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 far JB> as I know) which states that certain types of encryption programs are JB> prohibited from export. True.. I see.. I understand that view.. I don't agree with it. - John 201434369420143436942014343694201434369420143436942014343694718 From: Jim Grubs, W8GRT Area: Public Key Encryption To: Michael Bauser 4 Nov 94 11:34:00 Subject: PGP 2.6.2 Official M.I.T. UpdReq > Phil Zimmerman and MIT have acutally talked about > releasing a *book* > containing all the PGP source code, but no definite > plans have been > announced. If they do release such a book, they'll > probably wait until > after they've released PGP 3.0--Phil's working on > enough things already. Wonder what's packed between the underwear and the jammies on his trip to the UK? Sincerely, Jim Grubs, W8GRT 201434369420143436942014343694201434369420143436942014343694718 From: Scott Miller Area: Public Key Encryption To: Marc Stuart 4 Nov 94 15:52:00 Subject: My new improved key UpdReq I was told not to burst a blood vessel by Christopher baker, however the reason is that it is not necessary. It does nothing to verify that the key is from you, and it is a wasted step in decoding a key. Scott 201434369420143436942014343694201434369420143436942014343694718 From: John Mudge Area: Public Key Encryption To: All 3 Nov 94 02:46:02 Subject: A proposal... UpdReq Hello All! FSC-???? FILTERED MESSAGE IDENTIFICATION FOR FIDONET *DRAFT II* FIDONET TECHNICAL COMMENT Author : John Mudge Fido : 1:352/111 Date : 02NOV1994 ABSTRACT: The following document proposes a standard for filtered message identification for Fidonet and Fidonet-based electronic mail systems. The proposed standard will assist in filtered-message detection. The standard consists of mandatory provisions. STATUS OF THIS DOCUMENT: This FSC suggests a proposed protocol for the Fidonet(R) community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. Fido and Fidonet are registered marks of Tom Jennings and Fido Software. BACKGROUND: Currently, filtered messages are not uniquely identified. No schemes are in place to determine whether a message received by a Fidonet node has been filtered. Current Fido Policy (Policy4) prohibits modifying routed encrypted material except as required for technical purposes. This FSC proposes a method of identifying such traffic in order to allow downlinks to identify messages that have been tampered with. IFNA KLUDGE LINES: Fidonet supports a general method for sending additional information embedded in a message known as the "IFNA kludge line". This is a line of text beginning with the ASCII SOH character (^A). The characters following SOH are a word indicating the type of kludge line, and the remainder of the line contains information specific to that type. This standard introduces a new type of kludge line, the FILTER. FORMAT OF A MESSAGE ID - MANDATORY: The mandatory portion of the ^AFILTER line shall consist of the Ascii SOH character immediately followed by the uppercase characters FILTER and a colon and one space. It is further required that the unique part of all ^AFILTER lines consist of a unique product identifier following the same format as specified in FSC-0046 for ^APID kludge lines and identifying the program used for filtering. This product identifier is to be one word and is to be followed by a space and the 3D, 4D, or 5D node address belonging to the system doing the filtering. EXAMPLE: ^AFILTER: NOBOGUS134 1:352/111.0@fidonet.org with NOBOGUS134 to be replaced with a two digit hex identifier at such time as a central product registry exists. MANDATORY REVIEW OF FILTER CONFIGURATION: Since message filters that currently exist (GMD, NOBOGUS, and PKTIM come to mind) can easily be configured in such a manner as to violate Policy, this standard also requires that copies of the configuration portion of any message filtering programs currently in use or having been used by a system within the prior 30 days be made available for public scrutiny by use of the standardised MAGIC name FILTER The use of MAGIC names in File Requests within Fidonet and FTN compatible networks is documented in the .DOC files included with most FTN compatible mailers but has not yet been the subject of an FTSC proposal. IMPLEMENTATIONS: As of this writing, no products exist to implement this proposal. SUMMARY: As of this date, no public repository exists for encryption/decryption product registration, but the FTSC is suggested as is the application form presented in FSC-0022. I am publishing this information as a Fidonet technical comment in hopes that other Fidonet products will eventually incorporate all or part of this standard as well, and that it will eventually form part of a Fidonet Technical Standard. CREDITS: I would like to thank all of the pioneers of Fidonet for making all of this possible. The ^AFILTER proposal is the result of the collective efforts of many of the participants of Fido who jealously guard the spirit inherent in free and open communications on a global level. Much of the wording and structure for this document I stole from authors of previous FSC proposals. Special thanks go to the brave souls who have recently exposed the use of message text filtering within one of the largest mail movers in North America. A PLEA: I hope to see the Fidonet Technical Standards Committee adopt this proposal without delay and that the mandatory portions of this standard be immediately placed placed into effect and that the penalty for violation be immediate and permanent excommunication for any node caught modifying messages in any fashion other than those allowed within Policy and the FSC/FTSC standards and proposals. Recent events indicate that adoption of this proposal and immediate compliance must be handled on an emergency basis. John Mudge 201434369420143436942014343694201434369420143436942014343694718 From: John Mudge Area: Public Key Encryption To: Jim Cunningham 3 Nov 94 03:20:08 Subject: CRYPTOGRAMS UpdReq Hello Jim! Sunday October 30 1994, Jim Cunningham writes to Garet Jax: GJ>> I'd like to receive cryptograms (of the type found published in GJ>> newspapers and magazines) from anyone who may have old copies laying JC> These are from our local paper labeled CRYPTOQUOTE and they are JC> copyrighted by King Features Syndicate. I use program called CRPTGRAM JC> that does the global substitution for me. I hope these will help. Do you have a copy of CRPTGRAM available for FREQ? If so, what is the filename? Thanks! John Mudge 201434369420143436942014343694201434369420143436942014343694718 From: John Mudge Area: Public Key Encryption To: Charles Chapman 3 Nov 94 11:50:04 Subject: PGP embedded in .gif's ? UpdReq Hello Charles! Answering a msg of , from Charles Chapman to John Mudge: Thanks you very much for the great info! I have passed it on and will grab the files. John Mudge 201434369420143436942014343694201434369420143436942014343694718 From: Jim Gorges Area: Public Key Encryption To: John Schofield 4 Nov 94 08:45:12 Subject: Embedding in Gifs UpdReq John: Regarding the list of program on The Sprawl for embedding files in GIFs (which has already been purged from the message base...darn), have you used some of them? If so, are there some you would rate as superior to or more capable than others? Jim Internet: grizbud@sns.snsnet.com 201434369420143436942014343694201434369420143436942014343694718 From: Scott Mills Area: Public Key Encryption To: John Schofield 3 Nov 94 14:32:36 Subject: Nodelist problems UpdReq -----BEGIN PGP SIGNED MESSAGE----- Monday October 31 1994, John Schofield writes to Scott Mills: JS> I quoted the above message in its entirety. To use a technical computer JS> term, something appears to be screwed up. {grin} I wrote a message about JS> "nodelist problems" but it had nothing to do with Dr. Dobb's Journal or JS> REXX. More screwed up than you think. Not only is that message not from me but it's from the wrong address entirely. Someones mailer must be in it's death throws. Scott The Clinton Sex Scandal: Fornigate! Scott Mills 1024/26CD5D03 For my PGP key freq PGPKEY sm@f119.n265.z1.fidonet.org - --- -----BEGIN PGP SIGNATURE----- Version: 2.61 iQCVAwUBLrk7vyP6qSQmzV0DAQFQBAP/bHDzvLgsnYRBGezUi4lahgoEQClNTcGo f/JOOdWoSRWDeSNR3iKH2UYWsY5vZ8fmH0qEDNfIfSyk1GgfGjIBCE61dJWQmwHb pI09b8iJmLCGYsJ2UufxTx4dF/PrsFWxarmm9IQiCpatOHE2EdDF/S4XBByBvtGE e5ZJF6bXwdw= =zc+e -----END PGP SIGNATURE----- --- 201434369420143436942014343694201434369420143436942014343694718 From: Scott Mills Area: Public Key Encryption To: Jim Bell 3 Nov 94 14:45:56 Subject: PGP 2.6.2 Official M.I.T. UpdReq Wednesday November 02 1994, Jim Bell writes to JOHN STEPHENSON: JB> First, I think you have misinterpreted the rules concerning guns. JB> Plenty of semi-auto guns can be modifed to full-auto. "Easily" is not JB> particularly definitive. And since in the warrant for the Waco fiasco they considered easy conversion to be the possesion of a CAD program and access to machining equipment it is very dangerous to allow government agencies to interpret vague laws. Scott The quickest way to a lawyer's heart is with a broadsword. Scott Mills 1024/26CD5D03 For my PGP key freq PGPKEY sm@f119.n265.z1.fidonet.org --- 201434369420143436942014343694201434369420143436942014343694718 From: Brian Ehrler Area: Public Key Encryption To: All 4 Nov 94 18:08:00 Subject: PGP Load UpdReq I am having some problems with PGP load finding the pubring.pgp file. It doesn't happen on Get sig. Any Ideas Brian ... The best things in life are free - but kinky costs extra. 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Christopher Baker 6 Nov 94 12:30:26 Subject: Re: hpack UpdReq Despite the stern warnings of the tribal elders, Christopher Baker said this to Nolan Lee: CB> i got both from 1:396/1 and sent a note to the author to ask if CB> the source was also available as it was in 78. I didn't upload the source because nobody'd asked for it, and I presumed that people'd just get it from any of the FTP sites listed. In hindsight, perhaps I should have uploaded the whole mess to you in the first place. I'll fix that problem right now; immediately after I save this message, I'll F'ATTACH you the following: HPACK79M.CPT MacIntosh compile. HPACK79S.ZIP Source code, ZIPped. For those who, like me, think TAR is a tremendous PITA. I also have it GZIPped and TARed, but presumably anybody who needs that can FTP it anyway. HPACK79U.HPK Documentation in nice pretty PostScript form, for you laser-printer paper-wasters. That oughta make up for my oversight in not sending it to you in the first place. :-) 201434369420143436942014343694201434369420143436942014343694718