The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 1 Issue 39

Monday, 13 Jan 1986


oReal-time responsibility
Dave Wade
o Big Brother
Jim McGrath
Peter Neumann
o Men in the SDI loop
Herb Lin

Real-time responsibility

Dave Wade <djw%a@LANL.ARPA >
Fri, 10 Jan 86 14:38:54 mst
I am just a programmer; however, for three and a half years I worked
at CTR Division here at Los Alamos.  I augmented ( in a very minor way, )
and maintained the control system for a series of Magnetic Fusion Energy

The programs ran in "real time" and attempted to use magnets to "contain" and
shape a plasma.  The plasma is very like the ball of gas in your neon light
over your desk, but instead of neon, we used a vacuum and a tiny amount of
sulfur-hex... ( that same stuff that was in the tank in Oklahoma that the
workmen dropped because it was overfull ).  The plasma is started by
discharging a huge arc across a quartz bottle that contains the vacuum and
the sulphur-hex.  The computer controls the point at which huge capacitors
discharge through the quartz bottle.  There are many independent power
supplies that discharge through different portions of the quartz bottle.
The computer program controls "precisely" when each power supply or
capacitor bank discharges into the quartz tube.  These power supplies/
capacitor banks are placed by the physicists such that the ball of
lightning ( plasma ) formed inside the quartz tube is kept from touching
the inside of the tube.  The power supplies form a magnetic bottle inside
the quartz tube ( the quartz tube is about 14 inches across, ) and under
computer control have kept the plasma alive and away from the edge of the
14 inch wide tube for more that 3/100 ths of a second.  Now the tube has
been made about twenty feet long and the ball of plasma has been created,
stabilized, and then slowly ( different time frame ) moved to the other
end of the tube;  controlled by a Pr1me 300 ( I'd guess that is about the
same as any of the 68000-based micros ).  The Pr1me did all of this stuff
remotely over a fiber-optic CAMAC highway.

The point of this was that any failure of the control system was capable
of killing personnel.  The "man in the loop" who was running the control
system was not necessarily knowledgeable about what he was controlling
( sometimes this was me... ).  The software was much smarter than the
operator and certainly swifter.  There is no way that I could hit the
"kill" switch before the plasma got loose.  The "kill" switch was used
as a mechanical lockout ( in conjunction with the software lockout and
the "key switch" we had installed ) while we were testing the control

I sit here and am bored by endless arguments on Unix "news" that the
Strategic Defense Initiative contains portions which "can't be
programmed" because they have this or that seemingly insurmountable
characteristic.  I look at my friends MacIntosh and think fondly of the
days when I helped with the payroll and accounting for a 2000 person
company on an IBM 1411 which wasn't the machine that the Mac is...  What
may be "impossible" for me is resting forgotten in one of the software
libraries down the hall.

Big Brother

Jim McGrath <J.JPM@Epic>
Wed 8 Jan 86 19:53:41-PST
To: "risks@sri-csl"@Sushi

Has anyone noticed the proposals made in the article "Security Without
Identification: Transaction Systems to Make Big Brother Obsolete" by David
Chaum in the October issue of Communications of the ACM (vol 28, # 10,
10330-1044)?  If so, what is the response?  Basically, he asserts that it
would be in the interests of both individuals and organizations to adopt a
system whereby transactions would be essentially unforgeable and untraceable.


Re: Big Brother

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Thu 9 Jan 86 21:34:07-PST
To: mcgrath%mit-oz@MIT-MC.ARPA

What you suggest might indeed be an improvement.  However, remember that
nothing is guaranteed unforgeable.  You will always have some points of
vulnerability, and you have risks of spoofing, clever system programmers,
embedded Trojan horses in hardware and software, etc.

If you were to rely blindly on such a system, you would be making yourself
even more vulnerable!  You can indeed come closer to having an unforgeable
communication, but believing that you have it may actually increase the risk.


Men in the SDI loop

Sat, 11 Jan 86 17:54:43 EST
To: mooremj@EGLIN-VAX.ARPA

    > As has been pointed out by previous contributors, human
      intervention during
    > boost phase is out of the question, since it's all over in a
      minute or two. 

    From: mooremj@eglin-vax

    For SLBMs, or missiles aimed at Europe from the western Soviet Union, I'll 
    grant the point.  But for land-launched missiles aimed at the US, 
    I estimate
    at least a five-minute boost.  If this is wrong, someone please
    correct me! 

Currently, the SS-18 has boost phase of about 5 minutes = 300 sec.  MX
has a boost phase of 180 sec.  Probably 120 sec boost isn't impossible
if you really tried to do it (as the Sovs will undoubtedly do if we
ever deploy SDI).  Indeed, the US is studying fast burn boosters even
as I write this.

Please report problems with the web pages to the maintainer