Subject: RISKS DIGEST 16.34 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 24 August 1994 Volume 16 : Issue 34 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Bug in Microsoft Word (Chris Norloff) Report on the 1993 Gatwick near-miss (Peter Ladkin) The new Cray and Unix passwords... (Peter Wayner) Most home security alarms are false (Mich Kabay) Misconceptions about PGP 2.6 from MIT (Philip Zimmermann) "Secrets of a Super Hacker" by Fiery (Rob Slade) International Cryptography Institute (Dorothy Denning) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed Aug 24 14:55:07 1994 From: cnorloff@tecnet1.jcte.jcs.mil Subject: Bug in Microsoft Word There's a bug in Microsoft Word 6.0 and 6.0a: what you see is not what you get. I saw this in _Windows Magazine_, May 1994 (Fred Langa's column "Win.INI", pages 11 and 14). I checked the problem with a copy of Word 6.0a, and confirmed it exists. I'm surprised I haven't seen it in RISKS, and checked the archive, but could find no mention of it in volumes 15 or 16. THE BUG: Word has a summary info area, for each document, that cannot be turned off. If you do not enter information in the summary (which is the default setting) then Word will lift sentences out of the beginning of your document and place them in the summary, without telling you. Even if you then change the summary info, the lifted sentences may still remain hidden in the document, visible to any text editor (but not visible in Word). If all you use is printed copies, you're okay. However, if you give somebody the file on disk or send it by email, then there may be unintended information in the file -- not great for people working with sensitive, competition sensitive, or classified information. According to the _Windows Magazine_ article, Microsoft denies this is a problem. For the time being, you can: 1. Turn on the "Prompt for Summary Info" in the Tools/Options/Save menu (this requires you to enter summary information, or accept what you've already entered, each time you save the document. This way Word will not lift sentences out of the text.) -or- 2. Block copy all your text to another document before transferring the file. -and- 3. Notify Microsoft if you believe this is a problem, to encourage them to fix it. The RISKS? well ... 1. You start to write a flame-o-gram, but later tone it down. Those first sentences may still be buried in the document. 2. You're involved with sensitive information (competition sensitive, source selection sensitive), or classified information. You don't see anything sensitive or classified so the document goes out. But those first sentences may still be there. 3. A software company sets their product to do something without telling you, particularly something that uses information from you, in ways unintended by you, without your knowledge or permission. Chris Norloff ------------------------------ Date: Wed, 24 Aug 1994 20:42:35 +0200 From: Peter Ladkin Subject: Report on the 1993 Gatwick near-miss [NOTE: PGN introduced an error in the original copy of this, 1992 instead of 1993. That is corrected here. PGN] The accident report is now in on the February 1993 off-course Continental Airlines Boeing 747 with 233 people aboard that flew within 500 feet of the Gatwick passenger terminal during a landing attempt at Gatwick Airport. Apparently computer failure prevented the automatic pilot from locking on to the radio beams that would have guided the plane to the runway. A manual landing followed. The crew had expressed doubts as to the accuracy of the instruments. [Source: A Close Call for U.S. Jet at Gatwick, excerpted by PGN from The International Herald Tribune, 24 Aug 1994, p.2] It sounds as though there was a failure to capture the localiser. But that happens. And how on earth were they following it if they hadn't captured it? I'd also guess there was some discrepancy amongst the instruments that they were busy trying to troubleshoot. Maybe one of the UK people can grab the report? Peter Ladkin [Also noted by Olivier M.J. Crepin-Leblond . PGN] ------------------------------ Date: Fri, 19 Aug 1994 19:29:19 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: The new Cray and Unix passwords... There has been a bit of news in the business sections about the new NSA contract given to Cray to develop a hybrid machine that combined the best of the old Cray vector approach with the best of the old Thinking Machine CM-1/CM-2 architecture. It is somewhat ironic that this was released in the same time frame that Thinking Machines went into Chapter 11, but it may turn out that this marriage really brings out the best in both approaches. Some of the news stories concentrated on the quasi-Chrysler-like bailout of an important technological treasure, but that is a question for political scientists who cleave to moldy debates about the relationship between private enterprise and the state. The biggest question for citizens of the techno-tribe of cyberspace, though, is what does this mean for digital privacy. Will the NSA be able to crack passwords with abandon? Will they be able to cut through the protection of DES like it was butter? Any speculation is, of course, pure speculation. But it is possible to make some educated guesses about the machine. News reports and other research states that this machine will include 512,000 processors that contain 256 bits of memory apiece. Each processor contains an ALU and three one bit registers. It really isn't a processor as much as a programmable logic gate that will take three inputs and spit out one of the 8 possible outputs. The architecture is supposed to borrow heavily from a neat machine called the Processor-In-Memory (PIM aka TeraSys) developed by the Supercomputer Research Center, a semi-public branch of the NSA. I happened to play with a very similar architecture several years ago developed by a company called Coherent Research Inc in Syracuse, NY. It turns out that it does a pretty good job of breaking DES. One hypothetical machine with 1 billion processors should be able to test all 2^(55) possible keys for DES in 1 day. How long should it take the Cray/SRC? The Cray/SRC processors are supposed to run at 2.08 ns/cycle. The Coherent Chips ran at 50MHz or 20 ns/cycle. This means the Cray/SRC is about 10 times faster. This is a very rough estimate, though, because it is not clear how many cycles it takes the Cray to complete each operation. The Coherent Processor took 2-4 cycles per operation. This would imply that the Cray/SRC could knock off all 2^{55} possible keys in 100 days. Given that DES may still be used extensively in financial transactions that move billions of dollars, it becomes clear that it might be worth it to spend $10 or so million on a machine and let it crank for a bit. (That's my wild estimate on the price. I think it could be as low as $2-3 million). But even if most of us don't have $100 million to steal, we still have reason to wonder about the effects of this machine. UNIX security systems use DES to encrypt the passwords 25 times before comparing them to a encrypted version stored in the central password file. A popular attack on the systems is to grab this central file and encrypt all of the words in the dictionary looking for a match. This is easy to do with a garden variety RISC machine today which is why many decent system administrators require gibberish passwords with numbers. How long would it take to attack gibberish passwords with this new Cray/SRC? I extrapolated some earlier work of David Feldmeirer and Phil Karn to show that a 64k processor version could knock off all 6 character passwords in about half of a day. (6 characters drawn from the set A-Z,a-z,0-9) If the 512k processor Cray/SRC can really run 10 times faster, then it could knock off these 6 character passwords in less that 15 minutes. All seven character UNIX-style passwords would take less than 2 days and all eight could searched in less than four months. There is one interesting side-effect of this approach. It takes about the same amount of time to attack 1000 passwords as it does to attack 1. After the 512k processors complete their encryption, they check to see if they've got a match. The encryption process was about 10,000 times slower than the matching on my design. So if you could grab a password file for a computer with 1000 users it would still take you about 15 minutes to find the one sucker with a 6 digit password. This means that even the maximum-sized 8-character UNIX-style passwords are really on the edge of obsolesence. It is really time for a new system to be developed. 16 characters might be best. But who can remember that many? Sure some know millions of digits of pi, but a bunch of politicians tried to shorten it to plain 3. This means we need to rethink many of the modes of protecting machines. [I presume that when Peter wrote "a plain 3" he was implying just 3 digits, as opposed to the old mathematical physicists' joke about pi being equal to 3 for small values of pi and large values of 3. PGN] All of what I've written falls into the realm of informed speculation. You can read about my design in a paper which was presented at Crypto 92. Mail me if you want a TeX version of it. I suggest that you dig up conference proceedings about the PIM/Terasys machine to get a better estimate of the new Cray/SRC's machine's performance. ------------------------------ Date: 16 Aug 94 07:44:52 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Most home security alarms are false >From the Associated Press newswire (94.08.16 @ 00:00 EDST) via CompuServe's Executive News Service (GO ENS): "Home Security", By WILL LESTER, Associated Press Writer The author describes the current problems caused by home security systems. Key points: o Burglars can easily disable some home security system control panels. o Estimates of false alarms from these systems range from 70% to 90% and even higher. o `"The false alarms are astronomical," says Sgt. Steve Emmons, spokesman for the Tulsa, Okla., Police Department. "It ties up two officers every time we get one, and 98 percent of our alarms are false. It is causing our call load to grow to an extreme level."' o Dallas police field 140,000 alarms/year, "most of them false." o Los Angeles charges $80 per false alarm after the first four free false alarms per location. o Miami tolerates five false alarms but then charge increasing fines. o Portland, OR. impose escalating fines and provide training. o "Security specialists advise buying a more sophisticated system that can provide protection for windows, motion detectors and a control system not easily disabled. Sirens are useful to shorten the burglars' stay." M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn ------------------------------ Date: 18 Aug 94 From: Philip Zimmermann, creator of PGP Re: Misconceptions about PGP 2.6 from MIT [NOTE: PGN removed PZ's PGP signing, for brevity. Besides, I corrected a few typos, which would blow the integrity check. PGN] I'd like to clear up some widely held misconceptions about PGP version 2.6 from MIT. I get a lot of email and phone calls from people who report a lot of misinformation on many Internet newsgroups about this MIT version of PGP. (For those of you who need an introduction to Pretty Good Privacy (PGP), it is a free software package that encrypts email. PGP is the worldwide defacto standard for email encryption. It's available via FTP from net-dist.mit.edu, in the pub/PGP directory. But then, if you haven't heard of PGP, you don't need to read this letter.) Here is a list of misconceptions: Myth #1: PGP 2.6 is incompatible with previous versions. Myth #2: PGP 2.6 is weaker than previous versions, with a back door. Myth #3: PGP 2.6 was released without Zimmermann's cooperation. All of these misconceptions would be cleared up if you read the PGP User's Guide that comes with PGP 2.6, but a lot of people seem to be spreading and believing these myths without looking into the matter empirically and getting the new PGP and reading the manual. Let's go over these myths in detail. - --------------------------------------------------------- Myth #1: PGP 2.6 is incompatible with previous versions. - --------------------------------------------------------- This is untrue. PGP 2.6 will ALWAYS be able to read stuff from earlier versions. PGP version 2.6 can read anything produced by versions 2.3, 2.3a, 2.4, or 2.5. However, because of a negotiated agreement between MIT and RSA Data Security, PGP 2.6 will change its behavior slightly on 1 September 1994, triggered by a built-in software timer. On that date, version 2.6 will start producing a new and slightly different data format for messages, signatures and keys. PGP 2.6 will still be able to read and process messages, signatures, and keys produced under the old format, but it will generate the new format. This change is intended to discourage people from continuing to use the older (2.3a and earlier) versions of PGP, which Public Key Partners contends infringes its RSA patent (see the section on Legal Issues). PGP 2.4, distributed by Viacrypt (see the section Where to Get a Commercial Version of PGP) avoids infringement through Viacrypt's license arrangement with Public Key Partners. PGP 2.5 and 2.6 avoid infringement by using the RSAREF(TM) Cryptographic Toolkit, under license from RSA Data Security, Inc. According to ViaCrypt, which sells a commercial version of PGP, ViaCrypt PGP will evolve to maintain interoperability with new freeware versions of PGP, beginning with ViaCrypt PGP 2.7. It appears that PGP 2.6 has spread to Europe, despite the best efforts of MIT and myself to prevent its export. Since Europeans now seem to be using version 2.6 in Europe, they will have no problems maintaining compatibility with the Americans. Outside the United States, the RSA patent is not in force, so PGP users there are free to use implementations of PGP that do not rely on RSAREF and its restrictions. Canadians may use PGP without using RSAREF, and there are legal ways to export PGP to Canada. In environments where RSAREF is not required, it is possible to recompile the same PGP source code to perform the RSA calculations without using the RSAREF library, and re-release it under the identical licensing terms as the current standard freeware PGP release, but without the RSAREF-specific restrictions. The licensing restrictions imposed by my agreement with ViaCrypt apply only inside the USA and Canada. It seems likely that any versions of PGP prepared outside the US will follow the new format, whose detailed description is available from MIT. If everyone upgrades before September 1994, no one will experience any discontinuity in interoperability. Some people are attracted to PGP because it appeals to their rebellious nature, and this also makes them resent anything that smacks of "giving in" to authority. So they want to somehow circumvent this change in PGP. Even though the change doesn't hurt them at all. I'd like to urge them to think this one through, and see that there is absolutely no good reason to try to get around it. This new version is not "crippled" -- in fact, it is the old versions that are now crippled. I hope that PGP's "legalization" does not undermine its popularity. This format change beginning with 2.6 is similar to the process that naturally happens when new features are added, causing older versions of PGP to be unable to read stuff from the newer PGP, while the newer version can still read the old stuff. All software evolves this way. The only difference is that this is a "legal upgrade", instead of a technical one. It's a worthwhile change, if it can achieve peace in our time. Future versions of PGP now under development will have really cool new features, some of which can only be implemented if there are new data format changes to support them. Like 2.6, the newer versions will still read the older stuff, but will generate new stuff that the old versions can't read. Anyone who clings to the old versions, just to be rebellious, will miss out on these cool new features. There is a another change that effects interoperability with earlier versions of PGP. Unfortunately, due to data format limitations imposed by RSAREF, PGP 2.5 and 2.6 cannot interpret any messages or signatures made with PGP version 2.2 or earlier. Since we had no choice but to use the new data formats, because of the legal requirement to switch to RSAREF, we can't do anything about this problem for now. Not many people are still using version 2.2 or older, so it won't hurt much. Beginning with version 2.4 (which was ViaCrypt's first version) through at least 2.6, PGP does not allow you to generate RSA keys bigger than 1024 bits. The upper limit was always intended to be 1024 bits -- there had to be some kind of upper limit, for performance and interoperability reasons. But because of a bug in earlier versions of PGP, it was possible to generate keys larger than 1024 bits. These larger keys caused interoperability problems between different older versions of PGP that used different arithmetic algorithms with different native word sizes. On some platforms, PGP choked on the larger keys. In addition to these older key size problems, the 1024-bit limit is now enforced by RSAREF. A 1024-bit key is very likely to be well out of reach of attacks by major governments. In some future version, PGP will support bigger keys. This will require a carefully phased software release approach, with a new release that accepts larger keys, but still only generates 1024-bit keys, then a later release that generates larger keys. - --------------------------------------------------------------------- Myth #2: PGP 2.6 is weaker than previous versions, with a back door. - --------------------------------------------------------------------- This is not true. I would not allow MIT or anyone else to weaken PGP or put a back door in. Anyone who knows me will tell you that. This is not to say that PGP doesn't have any bugs. All versions have had bugs. But PGP 2.6 has no known bugs that have any net effect on security. And MIT should be releasing a bug-fixed version of PGP 2.6 Real Soon Now. - ---------------------------------------------------------------- Myth #3: PGP 2.6 was released without Zimmermann's cooperation. - ---------------------------------------------------------------- Well, that's not true, either. Or I wouldn't be telling you all this. MIT did not steal PGP from me. This was a joint venture by MIT and myself, to solve PGP's legal problems. It took a lot of maneuvering by me and my lawyers and by my friends at MIT and MIT's lawyers to pull this off. It worked. We should all be glad this came off the way it did. This is a major advance in our efforts to chip away at the formidable legal and political obstacles placed in front of PGP; we will continue to chip away at the remaining obstacles. I hope this clears up the myths about PGP 2.6. I urge all PGP users to upgrade to the new version before September. And I urge you all to use the official 2.6 release, not anyone else's incompatible bastardized mutant strain of PGP. Please pass the word around, and help dispel these misguided rumors. This letter may be (and should be) quickly reposted to BBS's and all appropriate newsgroups. --Philip Zimmermann ------------------------------ Date: Thu, 18 Aug 1994 14:25:22 -0600 (MDT) From: "Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067" Subject: "Secrets of a Super Hacker" by Fiery BKSCSUHK.RVW 940609 Loompanics Unlimited P.O. Box 1197 Port Townsend, WA 98368 206/385-5087 fax 206/385-7785 loompanx@pt.olympus.net "Secrets of a Super Hacker", Fiery, 1994, 1-55950-106-5, U$19.95 Despite Loompanics' reputation as a "dark side" publisher, this may be a very good book. It deals primarily with social engineering, despite the purported coverage of other topics. It would therefore be valuable reading material around corporate lunchrooms, since forewarned is just a little bit more paranoid and, therefore, forearmed. As those involved with data security in the real world well know, cracking is basically a con job. Thus, The Knightmare, if he really is "super", is a con artist par excellence--and is pulling off a really great con here! Revealing the secrets of social engineering poses very little threat to security. Con men already exist and will continue to exist. Cracker wannabes are unlikely to be able to carry off a successful con if they need to rely on canned advice like this. On the other hand, it is much more likely to shock naive and non-technical users into an awareness of the need for suspicion and proper procedures--albeit possibly only temporarily. Thus, this information is almost inherently of more use in data protection than in data penetration. As for technical help for the cracker; well, are you really expecting great technical revelations from someone who knows there is a difference between baud and bits per second--and gets it backwards? Or, who thinks 140 and 19,900 baud are standard modem speeds? Who thinks Robert Morris' worm found "original" bugs? (And who doesn't know the difference between "downgrade" and "denigrate"?) All the successful hacks in the book rely on social engineering rather than technology. Lots of jargon is thrown in along the lines of, "You need X," but without saying what X really is, where to get it, or how to use it. The official definition of a hacker in the book is of the "good side" seeker after knowledge. As it is stated early on, a hacker *could* do lots of mischief--but doesn't. In the course of the text, though, the image is much more convoluted. The book almost seems to be written by two people; one who is within the culture and has the standard confused cracker viewpoint, and another, sardonically aware of pulling the wool over all the wannabes' eyes. The chapter on contacting the *true* hacker community is EST-like in its refusal to define when you might have made it, or how. Like I said, buy it for the corporate or institutional lunchroom. Make sure that the non-techies get first crack at it. If you'll pardon the expression. copyright Robert M. Slade, 1994 BKSCSUHK.RVW 940609 ====================== DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 DECUS Symposium '95, Toronto, ON, February 13-17, 1995, contact: rulag@decus.ca ------------------------------ Date: Tue, 16 Aug 94 17:26:10 EDT From: denning@chair.cosc.georgetown.edu (Dorothy Denning) Subject: International Cryptography Institute International Cryptography Institute 1994: Global Challenges September 22-23, 1994 Ritz Carlton, Washington, DC Presented by The National Intellectual Property Law Institute The International Cryptography Institute will focus on problems and challenges associated with the use of cryptography within nations and for international communications. The Institute will address such questions as: What are the different national policies and regulations governing cryptography and how might these evolve? What cryptographic technologies are on the market in different countries, what is being used, and what is it being used for? What problems is cryptography causing law enforcement? What are the requirements of businesses and other organizations? What are the new trends in cryptography and what will be their impact on society? What efforts are leading toward an international cryptography framework? The Institute is for government officials, industry leaders, policy makers and analysts, researchers, and users of cryptographic technologies. Program September 22 8:45-9:00 Opening Remarks Dorothy E. Denning, Chair of Program James Chandler, President, National Intellectual Property Law Institute 9:00-9:30 The Challenges of International Crytography Edward J. O'Malley, The OSO Group 9:30-10:00 Cryptography in the European Community Christopher E. Sundt, ICL Secure Systems 10:00-10:30 Cryptography in the German Governmental Area Ansgar Heuser, BSI 10:30-10:45 Break 10:45-11:15 Cryptography in Belgium Els Lemmens, Belgian Office for Scientific, Technical and Cultural Affairs 11:15-11:45 The Use of Cryptography in Singapore Kwok-Yan Lam, National University of Singapore Seow-Hiong Goh, John Yong, National Computer Board 11:45-12:15 An Australian and South-East Asian View of Cryptography William J. Caelli, Queensland University of Technology 12:15-1:45 Lunch with Keynote TBA 1:45-2:15 GSM: Security for World-Wide Mobil Radio Charles B. Brookston, British Telecomm 2:15-2:45 International Exchange of Digital Signatures in a Diversified World Jean-Jacques Quisquater, University of Louvain 2:45-3:15 Creating Global Cryptographic Infrastructures Sead Muftic, Stockholm University 3:15-3:30 Break 3:30-4:00 An International Cryptography Framework Keith S. Klemba and Jim Schindler, Hewlett-Packard Co. 4:00-4:30 Experiments in International Cryptography and Software Key Escrow Stephen T. Walker, Trusted Information Systems, Inc. 4:30-5:00 International Escrowed Encryption Dorothy E. Denning, Georgetown University John Droge, Mykotronx, Inc. 5:00-6:00 Reception September 23 9:00-9:30 U.S. Government Cryptography Policy Michael R. Nelson, Office of Science and Technology Policy 9:30-10:00 Domestic Regulation of the Exportation of Cryptography James Chandler, National Intellectual Property Law Institute 10:00-10:30 Sue E. Eckert, U.S. Department of Commerce 10:30-10:45 Break 10:45-11:30 Rose Biancaniello, U.S. Department of State (invited) 11:30-12:00 World-Wide Availability of Cryptography Products David Balenson, Trusted Information Systems, Inc. 12:00-1:30 Lunch with Keynote Louis J. Freeh, Director, Federal Bureau of Investigation 1:30-2:45 International Regulation of Cryptography James Chandler, National Intellectual Property Law Institute Alexander Patijn, Ministry of Justice, The Netherlands William Wolfowicz, Fondazione Ugo Bordoni 2:45-3:00 Break 3:00-4:00 Cryptography in the Financial Industry Mr. Mitsuru Iwamura, The Bank of Japan Dr. Victor Panchenko, SignalRox, Russia (invited) others TBA [Hotel and Registration info deleted. Ritz Carlton has a SPECIAL CONF RATE of only $225 per night! Tuition is $595. E-mail Dorothy for details. PGN] ------------------------------ Date: 31 May 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.34 ************************