The RISKS Digest
Volume 12 Issue 33

Sunday, 15th September 1991

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


British Telecom computer failure cuts off 42000
Paul Leyland
Security Software Bug Locks Up System
Sanford Sherizen
Companies Steal Information
Sanford Sherizen
Industrial espionage
Jerry Leichter
Re: Junk Mail ... 737 crash
Steven Philipson
RSA vs. NIST (digital security standards)
Tom Slone
Re: Salomon Brothers — Database Design
Gary Beckmann
Secret Computations the basis for Corporate Decisions
Jeffrey Sorensen
Re: +&*#$
Bob Clements
H. Fuss
History of Internationalization of ASCII
Paul Green
Lars Henrik Mathiesen
Export controls on workstations, or, more mantras
Jerry Leichter
Info on RISKS (comp.risks)

British Telecom computer failure cuts off 42000

Paul Leyland <>
Fri, 13 Sep 91 13:15:30 +0100
A very brief report appears in the Friday 13th edition of _The Times_

  42,000 cut off

  Police sent out emergency patrols after a British Telecom computer breakdown
  cut off telephones in 42,000 homes and businesses in the West Midlands

Security Software Bug Locks Up System

Sanford Sherizen <>
Sun, 15 Sep 91 19:57 GMT
The 9Sep91 issue of Computerworld had an interesting twist on security and
reliability.  A faulty piece of code embedded in the Tandem Safeguard security
system interpreted 4:22 PM on 27 August as an impossible command.  Affected
systems tumbled into an endless loop that tied up all computer resources.  The
security package then locked up the system.  The only way to fix the problem,
once it began, was to take the affected computers off-line before restarting
them.  Starting in Asia and continuing on to Europe, the appointed hour of doom
arrived, precipitating system shutdowns.  Users in the U.S. were warned by
last-minute phone calls. (Luckily, there were no phone outages this time.)

In an understatement, the writer said that some sources expected Tandem to
announce a fix later this fall.

Security is becoming more system critical, sometimes in ways that are not
easily anticipated.  Unless non-security aspects of system are fully tested and
integrated, the need to have security controls shut down systems in the event
of a (perceived) attack may lead to inappropriate system lockdowns and other
large-scale problems for hospital and other critical applications.

Companies Steal Information

Sanford Sherizen <>
Sun, 15 Sep 91 19:56 GMT
The Boston Globe (13Sep91) had an article on the competition between traffic
spotting services that sell their information to the media and to commuters.  A
federal lawsuit alleges information piracy, theft and use of trade secrets,
which involved listening in over two-way radios.  Metro Traffic Control said
that it feared piracy of its information by a new competitor, SmartRoute
Systems, and created a disinformation program that passed made-up reports on
traffic troubles.  This was reported by company employees over the radios to the
Metro Traffic headquarters (but not passed on to the media customers).
SmartRoute is charged with getting that information and passing it on to their
radio customers, who broadcast it.  An example of planted information that the
lawsuit contends was stolen and broadcast include a report on a dog running
loose in the South Station tunnel.  (A personal note: I thought that I saw the
dog but it could have been a politician looking for votes.)

This example, as well as the Samurai Hacker article from Rolling Stone, are
just a few indications that information stealing and manipulation is no longer
a phone phreak/hacker issues.  There is a long history of businesses misusing
information and attempting to restrict information by others.  Increasingly,
these misuses have moved into learning from and using acts that these companies
and others have condemned as hacker terror.  It will not be long before we hear
about a company setting off a virus against its competitors in order to gain a
larger market share.  Competitive business intelligence has become an accepted
form of industrial espionage, with major corporations reporting a trend to
establish intelligence gathering units as a necessary part of marketing

There are some dangerous trends here that can erase the lines between
legitimate and illegitimate acts.  The computer crime of today may become the
business strategy of tomorrow.  It is getting tough to tell the good from the
bad, for the scorecards don't list all of the players, the rules, or even the


Industrial espionage

Jerry Leichter <>
Fri, 13 Sep 91 23:06:56 EDT
I heard on All Things Considered tonight that one of the TV news magazines is
reporting that the French have a large industrial espionage operation in
effect.  The data, gathered by the French intelligence services, are
distributed to French companies to help them in business.

According to this report, the seats on Air France flights have been bugged, and
some of the passengers are crew are actually intelligence agents.

Question: If these reports are confirmed (of even if they aren't but cannot be
fully refuted), would you ever consider buying a French computer, or even
French software?

Are other countries playing the same game?  Attempts by US government agencies
(especially the NSA) to play a role in specifying cryptographic techniques
raises huge suspicions.  Just who CAN you trust to sell you equipment you can
confidentially use to store important restricted data on?  Can you only safely
use such equipment if you can guarantee that it's not connected to the
networks, and that it's never touched by people you don't completely trust?
Consider how much interesting data a disk with an intelligent interface could
squirrel away on a board that then gets replaced....
                            — Jerry

Re: Junk Mail — In memoriam, Dave Sharp (Mellor, RISKS-12.31)

Steven Philipson <>
Thu, 12 Sep 91 18:17:21 -0700
>... collision between a 737 and a private aircraft

The collision was between two aircraft in commercial service, the smaller of
which was a Swearingen Metro turboprop, certified and operating as an airliner.
General Aviation frequently gets a bum rap.  No reason to blame that segment of
the community for something in which it wasn't involved.

RSA vs. NIST (digital security standards)

Tom Slone <>
Thu, 12 Sep 91 21:06:45 PDT
The National Institute of Standards (NIST) has proposed a standard for secure
encryption of messages for non-classified digital electronic transmissions.
The method relies on a method that lacks widespread familiarity among
cryptographers.  RSA is the name of the most widely known and used
cryptographic method; it is controlled by several patents.  The patenting of
RSA led NIST to seek a non-patented method that could be used as a standard.

The NIST proposal and RSA both use pairs of related cryptographic keys: one to
encode and one to decode the data.  The difference in the two methods lies in
how the keys are generated.  RSA relies on the difficulty of factoring large
prime numbers, and the NIST proposal relies on the difficulty of generating
something called "discrete logarithms", presumably these are logarithms that
have truncated to a finite but large length.

Jim Bidzos, president of RSA Data Security Inc. (owner of at least one of the
RSA patents), said, "If no one challenges what they've [NIST] done, we'll be
stuck with a weakened standard."  Obviously, Bidzos is biased, since his
company would potentially lose out should a non-RSA standard be adopted.  But
there is some merit in his statement since knowledge of prime-factoring has a
long mathematical history, and discrete logarithms is presumably a new
sub-field.  [Science News 140(10):148(1991)]

There would seem to be merit both in having a standard and in not having one.
The lack of a Federal standard has apparently hindered the commercial use of
encryptions schemes, so data transmission has been insecure.  The existence of
a single standard, however, would seem to be more vulnerable to cracking via
technological and/or mathematical advances.  Recall the recent advances in
factoring primes made possible by the combination of better algorithms and
inexpensive, fast computers.  These advances have forced made it necessary to
increase the length of encryption keys for the RSA method.

Re: Salomon Brothers — Database Design (Drake, RISKS-12.29

Gary Beckmann <>
Fri, 13 Sep 91 09:47:55 EDT
I have a good friend who works for one of the large financial houses, and he
informs me that very often the programmer will be brought in for a few weeks to
implement a design that very likely has not been reviewed by anyone (especially
not the end user!!) except the manager who has ordered the design.  There is no
reason to assume that other companies work differently.  The pressure in the
field is simply too great for the people to "worry about such things".  Seems
to me that they are setting themselves up for more experiences like the Salomon
                    Gary Beckmann

Secret Computations the basis for Corporate Decisions

Jeffrey Sorensen <>
Fri, 13 Sep 91 10:40:01 EDT
On the topic of risk assessment, a particularly chilling episode is discussed
in _The Media Monopoly_ by Ben Bagdikian.  Some excerpts:

[Mark] Dowie is the investigative reporter who disclosed that the Ford Motor
Company and knowingly produced dangerous gas tanks in its Pinto cars, having
decided that it was cheaper to pay off heirs of the dead than to spend a few
dollars per car to make the tanks safer.

The book he was proposing in 1979 would examine the history of this kind of
corporate decision making.  ... [Beginning with] Cornelius Vanderbilt, who
rejected air brakes for his nineteenth-century trains.

[The editor Nan] Talese was excited.  One of the most respected editors in New
York, she had produced a series of successes for her employer, Simon &
Schuster.  ...Dowie, almost as an afterthought, said, "Do you think the title,
_Corporate Murder_, will be acceptable."

Talese then asked an odd question: "Is Gulf and Western one of the

When Dowie said the book did not mention Gulf + Western, Talese said, "Fine.  I
don't think we'll have any problem getting that title past our corporate

But she was mistaken.  Even though she and her staff unanimously supported the
book, neither the title nor the book itself was acceptable.  ...The president
of Simon & Schuster, Richard Snyder, was vehemently opposed to the manuscrip
because, among other reasons, he felt it made all corporations look bad.

If Simon & Schuster had been an independent book company, as it once was, [and,
not owned by Gulf + Western,] Tales would not have asked an author the question
she asked Dowie.  It is also possible that Dowie's manuscript would now be
available to the public, which, as of 1987, it was not.

  For more info see pp.27-31 in _The Media Monopoly_ 3rd edition, 1990 by
  Ben H. Bagdikian, ISBN 0-8090-6156-X published by Beacon Press.

The field of risk assessment involves numerous assumptions at every
calculation, and if these assumptions are wrong, the resulting decisions will
also be wrong.  The errors will continue to be wrong because these assumptions
are not effectively challenged by open and competitive ideas.  In an era of
almost complete control of the media by a handful of monopolies, the
assumptions involved in risk assessment are deliberately withheld from public
scrutiny to create the illusion that the trade-offs between safety and cost are
not being computed, when, clearly, they must be.

The result is, we are left with no information discussing the _philosophy_ of
risk assessment while on a daily basis risk assessment continues in the back
closets of our many institutions...

     Jeff Sorensen     (518) 276-8202

Re: +&*#$

Fri, 13 Sep 91 10:41:20 -0400
In RISKS-12.31, Dik T. Winter mentions that some Yugoslavian license plates are
distinguished only by a diacritical mark, and Mike Morris reports on trouble
with the encoding of Ham Radio callsign plates in California.

Here in Massachusetts, those two themes are combined.  Someone decided that our
Ham plates should have a jagged line (stylized lightning bolt) after the digit
in the callsign.  My plate reads "K1<lightning-bolt>BC".  This is actually
encoded in the RMV computer as "K1/BC".

In the continuing effort to raise money, the RMV started issuing some more
patterns of low-numbered (extra fee) plates a few years ago.  One of the
patterns is <LETTER><DIGIT>

re: ##$@*, !names, umlauts and other nonstandard print chars

"H.Fuss= F1Fuss@DBNGMD21.bitnet" <GSFP08@dbngmd21.bitnet>
Fri, 13 Sep 91 17:07
         and: mis-printed official documents

Besides those umlauts "a, "o, "u, "A, "O, "U (the dots are supposed to
sit _upon_ the characters) and the use of the dots as diaeresis, we in
Germany have one more special character, a special form of double-s.
Though pronounced `es-zet', it has nothing to do with `sz', but derives
from a ligature of two different s's:  a 'long-s' (which looked roughly
like an 'f' without the horizontal bar), used in the middle and
beginning of words and syllables, and a 'round-s', used at ends.

The nearest glyph to an `es-zet' is a greek 'beta'.  (For explanation, please
read 'long-s' instead of 'f' in the following 7 words: is, fend, eafy, mistake,
grafs, clafsroom, H.Fufs).  As 'round-s' appears at ends only, there is no
upper-case `es-zet'.

However, computers and their chain printers had (numbers... and)...
uppercase letters only, so all the `special characters' had to be
replaced by something else, and the `Duden', the official spelling book
for schools etc. suggests a additional `e' for the umlauts (what is in
line with the history of handwriting since medieval times) i.e. `ae'
for `"a' etc., and `ss' for the missing `es-zet'.
  (Interesting aside: the case of a Herr `Sch"on', who refused to accept
  official letters addressed to `Herr Schoen', — which was decided
  against him,  and his second case, an application for an official
  change of his family name from `Sch"on' to `Schoen' ((in order to
  accept properly addressed letters now)) — which was also decided
  against him.)
According to this, my name was officially printed as `FUSS'.

However again, when printers were able to print lower case letters as well (and
available in state administration), very clever people decided --for easy
readability!-- to use the font `small capitals' a-n-d an additional 'beta'-like
glyph for the `es-zet'.

As 'small capitals' are nearly as tall as ordinary capital letters, and as a
misprinted 'beta' among all capitals looks more like a poorly printed 'B', my
passport carries at first sight the name 'FUB'.

My wish, to print my name according to `Duden' as `Fuss', because I might get
into troubles at foreign borders, whose policemen might not know `es-zet's and
might accuse me of using false documents (passport differs from visa and
customs documents) was turned down: not Duden, but _l_a_w_ decides how to write
names, and they had their rules!!

(Up to now, I did not yet have problems from wrong name-spelling in foreign
countries (borders), perhaps it could have been that messages for Mr.Fub did
not get to Mr.Fuss in his hotel, and vice versa).


Following is the sad story of my friend Cesar Fernandes L.

As everybody in the civilized world knows, everybody has one or more first
(`Christian', given) name(s) and a family name (inherited).  (In Germany, one
has 1-3 first names, but to have more is a little unusual, but nothing wrong
  As everybody knows, first-names come first, and family-name is last (only in
some official administrations the order is, for sorting and finding reasons,
reversed); this is important if somebody's family name should be a first name
(e.g. the ketchup producer Heinz), or if somebody has a first name which is
rare and therefore not recognized as a first name by everybody (e.g.
Orlambugo).  Some people carry their first name(s) as initials only; some
people have some abbreviations as an addition to their name, e.g. Dr., MdB
(=MP), etc.
     (omission of rules of how inheriting family manes... but...)
There are countries, where the equality of sexes is more advanced than
in our country, e.g. in Chile. There everybody has t-w-o family names,
one from his father, the second from his mother.
(In order not to exaggerate the equality of sex, the second family
name, which is the less important one, is very often abbreviated,
because it is only the resp. first of the two names which is
transferred to the children, and in this order:  father(1), mother(1).)
 The signature of my friend Cesar Juan Adolpho FERNANDEZ Lopes is:
                                         Cesar Fernandez L.
Everywhere in an index, he is listed under the letter F.

There are not 2 family names in Germany, so he got into troubles with his
official documents when he stayed here for several years; they offered him to
list his name as Cesar ... Fernandez-Lopes, (because family names are
positioned last — and not as last-but-one), but that steals him one name,
because it is quite possible to have a hyphenated (first) family name.

Finally, the case was decided that he has officially to be listed as Cesar Juan
Adolpho Lopez FERNANDEZ; according to the rule: family names are at the end
(e.g. in his international drivers license).

When he returned to Chile and once had to produce his drivers license, he was
detained into custody because of using false documents, here those of somebody
else, namely those of Senor (Mr.) Cesar Juan Adolpho LOPEZ Fernandez.

Risks of unflexible use of computerized prints.

Dr. H.Fuss, Inst. of Foundations, National Research Centre of Information
Technology, 5205 St.Augustin / Bonn, Germany

History of Internationalization of ASCII (RISKS 12.30-32)

Fri, 13 Sep 91 17:06 EDT
I think we may be getting off of the part of this debate central to RISKS, but
as someone who has some familiarity with this area, I can't help but correct
some of the earlier statements.  The real history of internationalization is
far more complex than the mail so far would suggest, and far less sinister.  I
believe that simple economics has dictated most of the decisions.

Hugh Davies notes (in RISKS 12.30) that "European consumers demand that their
consumer products 'talk' to them in their language." It isn't just the
Europeans; every prospective customer I've ever met wants this.  Those of us on
the vendor side have to balance what we can do with what people are willing to

Those replacements of square brackets, etc., that he complains about were an
official part of the original ASCII standard.  The designers recognized that
ASCII would be inadequate to meet the needs of everyone and so wisely defined
ten "national use" positions that could be changed in each country.  There are
many so-called national versions of ASCII that exist, typically one for each
country.  This was the state-of-the-art in the 60's and 70's; when a US vendor
exported their product to a "foreign" (non-US) country, vendor personnel in
that country translated the messages, screens, and, yes, manuals, into the
native language of the country.

In fact, ASCII is officially just another national version of ISO-646, the
so-called International Reference Version.  In practice this is irrelevant.

Eventually, vendors discovered they were spending vast sums to translate the
software and manuals, were delaying the shipment of new products by months, and
were greatly complicating support efforts.

In the 1980's vendors turned their efforts to creating software products that
would have the same binary image in each country, but would support multiple
code pages at a time, and dynamically switch between them.  All they would have
to translate would be the manuals and error messages.  The emergence of
computer networking was also a major influence here.  ISO 2022 describes a
technique for handling multiple code pages for the ASCII class of standards;
there is a similar standard for EBCDIC.  Anyone who has used MS-DOS since about
version 3.0 has seen the extensions that were made to it to support multiple
code pages; they are fairly typical.

The next effort was to reduce the number of code pages down to a manageable
number.  ISO has registered 155 code pages as of July 1990!  There is
considerable complexity just from the sheer number of them.  ISO 8859 is a
series of 8-bit code pages that have ASCII (real, true, American ASCII without
substitutions) in the lower 128 positions and room for 32 new control
characters and 96 graphic characters in the upper 128 positions.  There are 9
variations of 8859 that I am aware of; the best known is 8859/1, also known as
Latin Alphabet No.  1, which covers most of Western Europe.  All together the 9
versions of 8859 cover some 40 languages.

Asian ideographic languages (Japanese, Korean, Chinese, etc.) have so many
symbols that 2 bytes are needed to encode a useful subset of characters.  The
Taiwanese ISO-compliant standard for Chinese requires two double-byte code
pages.  Even at 17,672 (2*94**2) positions, this is still a subset of written
Chinese, which has over 80,000 characters!  Japanese requires both a
single-byte code page (Katakana) and a double-byte code page (Kanji).

Handling this requires two sizes of characters and shift characters to switch
code pages.  This has meant a new level of complexity in programming languages,
operating systems, and applications.  Further, I've only described the
ISO-compliant schemes.  There are a variety of non-ISO schemes; for Japanese,
Chinese, etc.

The Stratus VOS operating system presently supports 9 ISO-compliant code pages
that cover 17 languages.  This covers the primary language of 65 countries that
account for half the world's population.  Same binary OS image, no confusion of
codes, worldwide ability to use any supported character without confusing it
with any other supported character.  Oh yes, we can translate these code pages
to and from EBCDIC.

I'm proud of what we did, but I'll be happy if something like Unicode can take
its place.  It would be nice to go back to simple, fixed-width characters
again, without shift bytes.  I don't expect it anytime soon, however.

Paul Green <>, Director, System Availability
(ex-National Language Project Mgr) Stratus Computer Marlboro, Mass., USA

Re: Multinational Character sets (Davies, RISKS-12.30)

Lars Henrik Mathiesen <>
Sat, 14 Sep 91 16:40:14 GMT
I just wanted to point out that these extensions are not the manufacturers',
but rather nationally standardized (and internationally registered) variants of
the ISO 646 set, which explicitly sets code values aside for such variant uses.
Formally, ASCII is just the USA version of this, but of course ASCII was the
base for 646, and the ``reference'' version of 646 is almost identical to
ASCII. The point is, ASCII is _supposed_to_ contain only the characters that
are useful in the USA.

Of course, ISO 646 doesn't in itself have any facilities for handling more than
one language at a time. Later ISO standards do define ways of changing between
variants, but none were widely implemented, I think.

Lars Mathiesen, DIKU, U of Copenhagen, Denmark       [uunet!]mcsun!diku!thorinn

Export controls on workstations, or, more mantras

Jerry Leichter <>
Fri, 13 Sep 91 22:58:34 EDT
(For the sake of simplicity, assume it's two years ago, before all the recent
changes in South Africa.)  Should US companies sell computers (guns, tear gas
-- take your pick) to the South African security agencies?  After all, if the
US doesn't, that just opens the market for the Japanese, the Taiwanese, the
Koreans, or whoever.

Once again, the issue of control of exports of high-powered computers has been
raised: As reported in a recent RISKS, the US DoD has proposed new regulations
on the sale of high-end workstations.  The ritual responses have shown up in
this forum: Why bother, they'll just buy from the Japanese, or the Taiwanese,
or whoever.

These ritual responses display, to me, a certain unwillingness to really think
about the issue.  "Someone else will do it anyway" is an excuse.  It's not at
all clear that someone else will; and it's a morally bankrupt argument in any

There are two distinct, though related, issues that need to be resolved before
deciding whether export controls on high-powered workstations should be

  a)  Is it RIGHT that such machines should be kept out of certain
      foreign hands?

  b)  Is there a PRACTICAL way to implement such controls, should the
      answer to (a) be yes?

I'll contend that hardly anyone will disagree with (a), posed in isolation,
though there will certainly be disagreements about exactly which foreign
hands should be allowed access.

So let's examine (b).  First of all, on a moral basis, controls may be
justifiable EVEN IF IT'S PRETTY CERTAIN THEY WON'T WORK.  Sure, others may do
the dirty deed, but that doesn't mean WE should; while we may not be able to
stop some evil, at least we should being involved.  Should we sell arms to
terrorist organizations because, after all, they can always buy them from
someone else?  Should we sell nuclear materials and technology because, after
all, the Chinese seem to be willing to?  Every effective embargo has to start
with individual decisions that "No, I'm not getting involved in THAT."

Is (b) really out of the question?  At the moment, the CPU's for high-end
workstations are made predominantly by a small number of US companies.  An
increasing number are made by Japanese chip houses, but under license from US
companies.  With the exception of the Transputer, all CPU's in wide use today
are controlled by US companies.  The US could probably require US companies to
place appropriate restrictions in their licensing agreements.  Should the US
move in this direction, the British would probably go along and similarly
restrict Transputers.  It would take years for another architecture, developed
and controlled entirely by non-US interests, to become a significant market
force - and, frankly, I don't see that happening as a response to US attempts
to control exports.  It's just too expensive an undertaking, and the potential
market is too limited.

By the way, just about all these systems run Unix - also under US control.

Those outside of the US may not like it, but as a practical matter the US has
a solid lock on leading-edge CPU hardware technology at the present time.
That's not likely to change in the next couple of years.  What the US chooses
to DO with that lock is, of course, another issue.

So:  The legal and practical bases for controls exist.  What kind of controls
might be practically applied?  Historically, the controls have mainly been of
a go/no go sort:  Anything above some speed limit could not be exported.  The
DoD is taking a much more sophisticated approach to things this time around.
Among the suggestions mentioned in the newspaper article are software limits
on what kind of programs could be run (no details, but it might be things like
maximum memory size allowed, I suppose), and verifiable logging of information
describing the workload to a WORM device, whose media would have to be
returned for inspection on a regular basis.  As I recall, conditions of this
sort were enforced on CDC machines sold to the Soviets for weather forecasting
many years ago.  How effective they can be is an open question - but it's one
that can only be answered by experimentation.

Sure, any controls can be gotten around.  Terrorists do manage to get arms.
Iraq came quite close to building a nuclear bomb, despite all the controls on
nuclear materials.  Then again, people get away with robbing banks.  Does that
mean we should legalize bank robbery?

As Shaw put it, we already know what you are, we're just haggling over price.
If you agree that, as a matter of morality, computers should not have been sold
to South African security forces maintaining apartheid, then the only arguments
you can have with the current proposals are (a) that they aim at the wrong
people; or (b) that they are too easy to get around.  If your real problem is
with (b), the right response is to try to find better implementations, not
whine about what the Taiwanese may do.
                        — Jerry

Please report problems with the web pages to the maintainer