Subject: RISKS DIGEST 17.29

Subject: RISKS DIGEST 17.29
REPLY-TO: [email protected]

RISKS-LIST: Risks-Forum Digest Friday 25 August 1995 Volume 17 : Issue 29

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc. *****

Contents:
Australia and Encryption Policy (Dorothy Denning)
Cash Registers Crashed at Midnight (Jerome Whittle)
Like an executioner's axe, on the A8 autoroute (Pete Kaiser)
Australian "intelligent" road experiment (Harley Mackenzie)
Do I live in California or Israel? (Jonathan Kamens)
Newsletter recommendation: The Jarvis Report (Charles M. Preston)
Re: The traffic light does NOT think (John Carr)
Re: RZ1000 chip problem: where to find more info (Stan Brown)
Re: Nine-digit zip and personal privacy (John Levine)
FLUKE DMM Operational Safety Notice (D. Teninty)
Re: Netscape Security (Thomas Peters, Nathan Myers, Bill Sommerfeld,
Tye McQueen)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Wed, 23 Aug 95 15:13:05 EDT
From: [email protected] (Dorothy Denning)
Subject: Australia and Encryption Policy (Re: Anderson, RISKS-17.24)

Ross Anderson posted a message on the net recently stating that Australia
was proposing an encryption policy that would force residents to use weak
cryptography while banks would get key escrow. His source was a talk by
Steve Orlowski, who is Assistant Director, Security Management, in the
Australian Attorney-General's Department.

Attached is a copy of an open letter by Mr. Orlowski in response to
that post. He is not proposing that individuals be forced to use weak
encryption. Key escrow would be an option available to anyone wanting
a high level of encryption. Organizations and individuals could escrow
their own keys if desired.

This message and his letter may be forwarded.

Dorothy Denning

- - - - - - - - - - - -

Dear ,

Thank you for your comments on the subject of the use of encryption by
private individuals.

Firstly I would like to make the point that the debate has arisen from one
person's interpretation of a paper I gave at a conference on ``Cryptography
Policies and Algorithms.'' The full text of that paper is now available on
the net at

http://commerce.anu.edu.au/comm/staff/RogerC/RogersHome.html

The paper carries a disclaimer at the top that the views are mine and do not
necessarily represent the views of the Australian Government. The paper
sets out the Government's policy on telecommunications interception, which
includes the issue of the use of cryptography as: ``As a result of the
Report, Australia is, among other TI issues, monitoring the impact of
encryption in the telecommunications interception area and will re-examine
matters in 1997 following the opening of the telecommunications area to full
competition.'' Telecommunications covers both voice and data
communications.

The last paragraph of the paper says that there is a need to expand the
cryptography debate to cover the needs of individual users in the context of
the information superhighway rather than current Internet users. The paper
also points out that issues suh as cost, convenience and public confidence
in cryptography systems will be the main issues. Public confidence is
explained in terms that as long as it meets the general requirement for
privacy it will be acceptable. I still maintain that the general user of
the superhighway in the next century will be satisfied with a lower level of
encryption which will meet that and cost and user friendliness requirements.

On specific point made in the Internet message, the paper does not suggest,
either directly or by implication, that individuals should be banned from
using encryption.

Regarding the use of higher-level encryption, the paper supports the concept
of commercial key escrow where organisations hold their own keys but may be
required to provide them in response to a court order. The same would apply
to individuals who could either hold there own keys or store them with a
commercial body. Access to those keys would be by court order and in that
respect is no different to existing procedures for the interception or
seizure of telephone conversations or paper records. There is no suggestion
that these basic principles, and protection of individual's rights in
general, should be changed.

If individuals were to use lower level encryption there would be no need for
them to maintain copies of any keys for such systems. To my mind this is
preferable to a requirement for keys to be maintained for all encryption
systems, which could be the result if universal key escrow were introduced.

Finally on the question of interception, the general public expects a
reasonable level of law enforcement to ensure the protection of their person
and property. Governments are required to find a balance between this and
the rights of individuals to privacy. Part of this balance is to ensure
that law enforcement authorities convince a court that there is a need to
carry out an interception. There is no suggestion that this fundamental
approach should be changed. The paper certainly does not suggest tha the
Attorney-General's Department should become a centralised interception
authority. In fact such a role would not be consistent with its role as a
source of advice to Government.

I hope the above clarifies both the Government's policy and my personal
views on these matters.

I consider this to be an open letter and have no objection to it being
used as such.

Yours sincerely

Steve Orlowski

------------------------------

Date: Fri, 25 Aug 95 08:04:00 cst
From: "Whittle, Jerome SMSgt" <[email protected]>
Subject: Cash Registers Crashed at Midnight

According to the 25 August 1995 edition of the St. Louis (MO) Post-Dispatch,
a local CompUSA store took the unusual step of staying open late for the
release of Windows 95. Unfortunately, the cash registers crashed at
midnight, just as the first Windows 95 buyers were ready to check out. The
store worked half an hour to resolve its problem.

The article did not say what cause the cash registers to crash; however, I
am sure members of RISKS can speculate. My guess is that the cash register
system needs to be cycled off at the end of the day and on at the beginning
of the next. As they never before stayed open after midnight, they did not
know this (nor did they RTFM).

Even a reliable system will produce unusual results when used in an unusual
manner.

Jerry Whittle Belleville, Illinois [email protected]

------------------------------

Date: Wed, 16 Aug 95 09:21:02 +0200
From: [email protected]
Subject: Like an executioner's axe, on the A8 autoroute

In an August 13 article in "Nice-Matin" -- the daily newspaper of Nice
(France) -- Alain Ponzanelli is quoted as saying (my translation):

"I was caught like a fly in a spider's web, trapped by a barrier
that came down in front of my car like an executioner's axe. I was
badly frightened. And I had to back up on the turnpike, risking an
accident, to get out of the trap."

The A8 autoroute (turnpike) has toll plazas at intervals on the highway, and
the one in question, like some others, has a high-speed lane for cars
equipped for "telepayment" by a badge mounted on the lower left interior of
the windshield and validated by a sensor in the telepayment lane marked by
lights.

M. Ponzanelli drove into the telepayment lane of the Saint-Isidore toll
plaza prepared to slow down for the sensor, but to his surprise the
normally-open barrier before the sensor closed ahead of him. He was able to
veer off into the emergency turnoff lane to his right, where another
normally-open barrier closed ahead of him. At this point he was trapped,
not even yet at a place where he could pay by cash and proceed. (The
article includes a photograph of the lanes and their barriers.) He shouted
and sounded the horn, but no one came to help, and he had to back up on the
highway to where he could go forward again to a cash payment lane.

According to unnamed autoroute employees interviewed by Nice-Matin,
apparently the computer that controls the telepayment lanes "mixed up" what
it was supposed to do with its barriers. One of them said that "electronic
chips don't tolerate heat too well". Another said "These incidents happen
very seldom. It could be an equipment problem or a problem with badges."

There is no question that M. Ponzanelli holds a valid badge: he is
subscribed for at least the whole month. From the photograph it appears
that the first barrier that closed ahead of him is well before the sensor,
and is intended to close off the lane entirely when the telepayment system
isn't operating. Finally, although it's true that electronics may be
sensitive to excessive heat, heat is hardly a rare phenomenon in summer on
the Cote d'Azur, and it's difficult to believe that the deployment of the
electronics doesn't account for that.

Pete [email protected]

------------------------------

Date: Wed, 23 Aug 1995 11:09:15 +1000
From: [email protected]
Subject: Australian "intelligent" road experiment

The Stuttgart experience described in RISKS-17.27 reminds me of another
failed experiment with "intelligent" road systems. In the late eighties the
Victorian Road Traffic Authority (RTA) managed to get funding for an
elaborate trial system for "suggesting" drivers change speed to allow
uninterrupted travelling, justified on the basis of potential fuel savings.

About 18 (I am not sure of the exact number) overhead signs were erected on
Canterbury Road, that is a main street leading from the eastern suburbs into
the city of Melbourne, that has many delays during the peak periods. The
signs were all connected via modem to the RTA's traffic management system,
and would advise motorists to travel at a suggested speed up to the speed
limit or be prepared to stop. The first morning lead inevitably to a number
of head to tail accidents, as I believe that the system did not account for
traffic conditions, merely the status of the traffic lights ahead so that if
you travelled at the recommended speed you could hit a stationary car in
front of you.

The system was also very useful for telling drivers when to exceed the speed
limit, as the sign would change from the 60 km/h speed limit to "prepare to
stop", and with only a little intelligence on the part of the driver, it was
soon obvious that if you went faster then 60 km/h you would make the lights.
In fact this was the only use for the system, as the delays still occurred and
the signs were soon ignored by drivers, except when in a hurry to race the
lights.

Needless to say, the trial system was abandoned and all of the signs removed.

Dr. Harley Mackenzie, Principal Operations Research Analyst, Yallourn Energy
114 William Street, Melbourne, Australia +61 3 9207 7719 [email protected]

------------------------------

Date: Fri, 25 Aug 1995 16:31:39 +0300
From: Jonathan Kamens <[email protected]>
Subject: Do I live in California or Israel?

Last week, my wife and I received two mailings on the same day from
AT&T Universal Card. One of them contained new cards for both of us,
and the other contained an updated cardmember agreement and a fluff
letter.

The last line of the address on the mailing containing the new cards
said "JERUSALEM 93393 ISRAEL". The last line of the address on the
other mailing said "Jerusalem, CA". Other than that, the two
addresses were identical (ignoring case).

Note that Israel uses five-digit postal codes similar to American ZIP
codes, and that the Israeli postal code 93393 looks a lot like an
American ZIP code for California. I don't actually know whether that
exact ZIP code exists in California.

It seems that there are at least two different programs involved in
addressing mailings from AT&T Universal Card. One of them was
programmed by someone who remembered to take into account the
possibility of international addresses, and the other wasn't. I just
hope that the program that addresses our statements is the one that
addressed the new cards, not the one that addressed the other mailing.

I'm going to write to the AT&T Universal Card people and ask them to
find out what the story is and fix it. If their response is of
interest to Risks, I'll forward it here.

Another interesting thing about this episode is that although the
second mailing said "Jerusalem, CA" and there was no mention of Israel
on it, and although AT&T probably only paid the domestic US postal
rate for it, it still got to us. Unfortunately, I can't figure out
how long it was delayed, because there's no date on the letter and
there was no cancellation on the envelope (since it was a mass
mailing).

Jonathan Kamens | OpenVision Technologies, Inc. | [email protected]

------------------------------

Date: Sun, 20 Aug 1995 11:49:40 -0800
From: [email protected] (Charles M. Preston)
Subject: Newsletter recommendation: The Jarvis Report

I would like to recommend a new publication called The Jarvis Report. It
is a quarterly newsletter about industrial espionage, and some technical
tricks of the trade. Ray Jarvis, who puts out the newsletter, has an
extensive government background in technical surveillance and he provides
classes for government and private security in countermeasures and
associated subjects. His stated aim is to collect and analyze verifiable
instances of the theft of proprietary information, and to provide an overall
look at trends and problems.
All 6 sections of the July issue were either useful or entertaining.
This edition includes an account of widespread electronic eavesdropping in
Israel, and suggestions on balanced line detection of series telephone line
transmitters.
A newsletter sample (article on Israel) can be found in the Info-Sec
Super Journal area at http://all.net
The Jarvis Report is published by Jarvis International Intelligence,
Inc., 11720 E. 21st Street, Tulsa, OK, 74129, 918-437-1100 Fax 918-437-1191

Charles Preston Information Integrity [email protected]

------------------------------

Date: Mon, 21 Aug 1995 19:47:48 EDT
From: John Carr <[email protected]>
Subject: Re: The traffic light does NOT think (Ihle, RISKS-17.27)

``The DM 14.000.000 equipment suggested a speed limit of 120 km/h - during
a traffic jam.''

There is a more fundamental problem than software bugs. As was hinted in
the original article, posting a speed limit, whether electronic or not, is
not necessarily an effective means of controlling traffic. American drivers
do not pay much attention to speed limits on major roads (the article was
about a German system so the following comments may not apply to it). When
I say ``do not pay much attention'', I mean actual speed is only weakly
correlated with posted speed. It is not a simple relation like 10 MPH over
posted speed limit, although that estimate is close to the average. This
behavior was documented in a government study within the past few years.

While I was driving on the New Jersey Turnpike a couple years ago an
electronic speed limit/traffic advisory sign told me the speed limit was
temporarily reduced to 45 MPH from the normal 55 MPH due to traffic ahead.
I and everybody else on the road ignored the sign. We could see well enough
to judge for ourselves whether and how much we needed to slow down.

The article about the German system cited a wet road warning. ``Wet road''
is not a useful message. I can see that for myself. If the sign could warn
that a sudden storm is coming (or a dust storm, or heavy fog, or invisible
icing) that could prevent accidents. Every year or two I read a news story
about a massive weather-related accident that might have been averted if
drivers had been warned and had slowed down. But the cost to build and run
a system which could give adequate warning would probably exceed the savings
from reduced accidents (taking a typical estimate that a life is worth on
the order of a million dollars).

What do I want from an electronic traffic system? Don't tell me anything
unless (1) I won't find out for myself until too late and (2) I can do
something in response to the warning. Otherwise the system is just wasting
my time and distracting me from driving.

My favorite adaptive road status indication is the hand drawn map I saw
getting on the New York State Thruway in Albany. It showed where along
the road it was snowing and raining. It was at a tollbooth so it didn't
take any of my time or distract me from driving and it told me everything
I needed to know (the road was open but conditions were bad) in time for
me to react (the worst weather was a hundred miles away).

------------------------------

Date: Thu, 24 Aug 1995 08:12:54 -0400 (EDT)
From: Stan Brown <[email protected]>
Subject: Re: RZ1000 chip problem: where to find more info (RISKS-17.27)

Various versions of the explanation of this bug have been floating
around. Perhaps it's best to get the information direct from Intel.
Web users can access it at
http://www.intel.com:80/procs/support/rz1000
There's an explanation of the bug, and also a downloadable program to
fix it (15 Kbytes).

(Thanks to [email protected] (Richard L. Wixom) who posted this to the
Usenet newsgroup alt.sys.pc-clone.gateway2000 among others.)

Stan Brown, Oak Road Systems Cleveland, Ohio USA [email protected]

------------------------------

Date: Tue, 22 Aug 1995 19:30:26 GMT
From: [email protected] (John Levine)
Subject: Re: Nine-digit zip and personal privacy (Fennessy, RISKS-17.28)

>Risks: If information needs to be split into private and public components
>then care needs to be taken for the job to be done correctly. 9-digit zip ...

No kidding. I have two post office boxes in different cities, each of which
has its own nine-digit zip code. And I've worked in offices in large
buildings where the office within the building has its own nine-digit zip.
These codes are hardly secret -- they're published in large books that you
can find at your post office.

The census bureau has been dealing with this particular issue for years.
Quite a while ago I did some work starting with 1970 data organized by the
first three digits of the zip code, and there were one or two entries
blanked out because even the three digit zip area in those cases made it too
easy to identify individuals.

Incidentally, ZIP codes are now 11 digits, although the last two
digits only appear on bar codes printed on mail by the largest of bulk
mailers. I think this gives every address in the U.S. its own zip.

John R. Levine, Trumansburg NY Primary perpetrator of ``The Internet
for Dummies'' and Information Superhighwayman wanna-be

------------------------------

Date: Tue, 22 Aug 1995 09:56:54 DST
From: "D. Teninty" <[email protected]>
Subject: FLUKE DMM Operational Safety Notice (RISKS-17.24,25)

Here is the official FLUKE notice, dated 18 August, 1995

Subject: FLUKE SERIES II, MODEL 21, 23, KIT-23, 70, 73, 75 AND 77
OPERATIONAL SAFETY NOTICE

Dear FLUKE DMM Customer:

We have become aware of a product malfunction in certain Fluke digital
multimeters (DMM). This problem is the result of a manufacturing change
implemented in July, 1994. Only seven models are affected: the Fluke Series
II Model 21, 23, KIT 23, 70, 73,75, and 77 meters imprinted on the case
bottom with serial numbers between 60990000 and 63752000. No other Fluke
instruments are affected. If the S/N of your DMM is preceded by a "9" or
followed by an "R", this notice does not apply.

The malfunction may occur when a voltage input greater than 400 Vdc is
applied in either voltage functions, AC or DC. The meter may go into a
lock-up state and will indicate a reading of (or near) zero volts. WHEN THE
MALFUNCTION OCCURS, THE METER MAY NOT INDICATE THAT HIGH VOLTAGE IS PRESENT,
PLACING THE USER IN A POTENTIALLY HAZARDOUS SITUATION. The failure mode
commonly occurs when the positive lead (red) is connected first to a high
voltage supply and then the common (black) lead is connected.

To correct this problem Fluke will modify your meter without charge. Even
if you normally do not use your meter in the voltage range mentioned, it is
recommended that you return your meter for modification.

If you are not the primary user of the affected Fluke DMM, please make every
effort to pass this notice to the appropriate people within your
organization.

Please send your meter to your Fluke Service Center to have this
modification completed. Your unit will be modified and on its way to you
within a few days.

NO TELEPHONE CALL OR RETURN MATERIAL AUTHORIZATION (RMA) IS NECESSARY.

In the US the place to send your meter is:

Fluke Technical Service
1150 W. Euclid Avenue, MS 70S
Palatine, IL
60067-7397
Telephone: 1-800-323-5700

For the rest of the world contact your nearest Service Center.

At Fluke Corporation, we are continuing to work toward the highest possible
level of product safety, reliability and customer satisfaction. We want you
to be thoroughly satisfied with your Fluke product. We apologize for any
inconvenience caused by this safety notice, but we urge you to have the
modification made as soon as possible.

If you have additional questions, please call our Technical Support Group at
1-800-447-7940 toll free.

Sincerely,

Richard W. Van Saun Senior Vice President Service Tools Division General Mgr

The information to include when you return your DMM is as follows:

Name, Company Name, Street Address, Mail Stop, City, State and Zip Code,
Telephone Number, Model Number, Serial Number

Dan Teninty P.E., Senior Design Engineer, Product Safety, FLUKE Corporation
Everett, Washington [email protected] (206) 356-6035 (206) 356-6490 fax

------------------------------

Date: Tue, 22 Aug 95 12:56:36 EDT
From: Thomas Peters <[email protected]>
Subject: Re: Netscape Security (What is a Credit Card Number Really Worth?)

[We received another huge collection of messages on the Netscape RC-4
40-bit cracking case. I have selected just a few for RISKS. PGN]

This discussion illustrates another common RISK: computerphiles losing
touch with low-tech approaches.

It is easy to get credit card numbers through dumpster diving, shoulder
surfing, dishonest retail employees, and telephone scams. All of these
methods are much easier and simpler than cracking Netscape encryption
with currently available technology.

Measured against this standard, Netscape encryption is clearly adequate
for credit card numbers until the cracking technology improves a lot. It
is an old principle: the lock on the door only needs to be good enough to
persuade the burglar to try the window.

------------------------------

Date: Tue, 22 Aug 1995 17:03:38 -0700
From: [email protected] (Nathan Myers)
Subject: Re: Netscape security (Shank, RISKS-17.27)

Shank has made another logical error: he assumes the machines used to crack
the cipher have been paid for by the person using them. Given the lax
security at many sites, a workstation farm could be used by anyone
persistent enough to break in, or by any insider who knows when they are
idle.

40 bits don't buy much security, no matter how you count them. But then,
giving your Visa number to random clerks has got to be pretty risky, too.
I'd rather have Chaum-bucks, myself.

Nathan Myers [email protected]

[You can celebrate with Chaum-payin' and Chaum-pignon.
There is always mush room for improvement. PGN]

------------------------------

Date: Wed, 23 Aug 1995 12:52:48 -0400
From: Bill Sommerfeld <[email protected]>
Subject: Re: Netscape security (Koopman, RISKS-17.28)

The "$10,000" estimate is almost certainly too high, by one to three orders
of magnitude. Several estimates I've seen (posted on the cypherpunks list)
suggest that RC4-40 can be broken, today, in bulk, using commodity hardware,
for between $500 and $1500 per broken key.

If you were to use custom or semi-custom hardware (FPGAs of various sorts),
the cost reportedly drops to around $10.00 to $20.00 per broken key.

Here's my estimate for using commodity hardware to attack RC4-40:

A "P100" 100MHz pentium can try on the order of 20000
RC4 keys per second. (I think this may be conservative).

P100 motherboards currently sell for about $600.00, including
the processor.

If you add power supply, minimal memory, and a network card,
your system cost goes up to around $1000.00 per CPU.

We'll assume the system has a useful life of 3 years.

In those three years, it can try 1.89 trillion keys.
2**40 is roughly 1 trillion.

Therefore, the cost per break clearly under $1000.00

To look at it another way:

If I buy 200 P100's, for a total cost of roughly $200,000, I can break
an RC4-40 key every 77 hours.

If I can make $2000 per broken key, I can make my $200,000 back in
just under a year.

------------------------------

Date: 23 Aug 1995 10:28:37 -0500
From: [email protected] (Tye McQueen)
Subject: Re: Netscape security (Rosenthal, RISKS-17.28)

) The last thing I want to do is ship it over a medium which goes
) through an unknown number of other people's systems on the way.

Which indicates that the "Netscape risk" may not be much or any higher than
using your credit card in many other situations. You may have higher risk
of the card being abused after it arrives, especially since the recipient
can claim that the fraud was the results of evil hackers and not one of
their untrustworthy employees.

I applaud the highlighting of this risk to help people make informed choices
about it. It sounds like more of this information should be available to
those likely to consider using Netscape's method of sending credit card
information.

I wonder which immovable object will give way first:
* The US denial that they are actually keeping strong encryption
from any enemies rather than just hurting business and others
* The credit card industry inertia about incorporating encryption
into the credit purchase authorization process
* Credit consumer ignorance about risks

All three contribute to the problem Netscape is trying to solve.

Tye McQueen [email protected] || [email protected]

------------------------------

Date: 9 August 1995 (LAST-MODIFIED)
From: [email protected]
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 <[email protected]>
(Dennis Rears <[email protected]>). UK subscribers please contact
<[email protected]>. 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
the newly automated <[email protected]>, with first text line
SUBSCRIBE or UNSUBSCRIBE
[with option of E-mail address if not the same as FROM: on the same line].
HELP
gives instructions on using the Majordomo listserver in other ways.

CONTRIBUTIONS: to [email protected], 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.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html
(Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 17 is in that directory: "get risks-17.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password. Also ftp [email protected]. WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen. Use wisely.

------------------------------

End of RISKS-FORUM Digest 17.29
************************