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

RISKS-LIST: RISKS-FORUM Digest  Tuesday 18 May 1993  Volume 14 : Issue 63

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

 Contents:
Read any good magazines lately? (Robert M. Slade [copyrighted article])
Re: Cut and Paste risks (Pete Mellor, Byron Rakitzis, Tim Cook,
   Christopher Lishka, Joseph Hall)
Re: CHI & the Color-blind? (Eric Haines, Tom Ohlendorf, David Tarabar)
Re: Denning on NIST/NSA Revelations (Dorothy Denning)
Re: NIST's reply to Bidzos (Jim Horning, Frederick Roeber, Jim Sims,
   Chris Phoenix, Carl Ellison)
Compromising the escrow agencies (Mickey McInnis)

RISKS Forum is a moderated digest discussing risks; comp.risks is its
Usenet counterpart.  Undigestifiers are available throughout the Internet,
but not from RISKS.  Contributions should be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious.  Diversity is
welcome.  CONTRIBUTIONS to [email protected], with appropriate, substantive
"Subject:" line.  Others may be ignored!  Contributions will not be ACKed.
The load is too great.  **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
especially .UUCP folks.  REQUESTS please to [email protected].

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 14, j always TWO digits).  Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential.  "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

For information regarding delivery of RISKS by FAX, phone 310-455-9300
(or send FAX to RISKS at 310-455-2364, or EMail to [email protected]).

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.

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

Date: Tue, 18 May 93 12:42:47 PDT
From: [email protected]
Subject: Read any good magazines lately?         [with permission, for RISKS]

   Memoirs of a (media star) virus researcher  [MEMOIR7.CVP   930515]

I have been known, from time to time, to make rather unkind statements about
the accuracy of virus reports in the mainstream media.  Some of my antipathy
arises simply from the fact that there is an awful lot of "mythology"
surrounding viral programs, and most of the pieces that appear in the media
simply perpetuate this.  Some of my experience, however, is first hand.

I like live radio best, and TV news the worst.  "Live" anything gives you a
bit of control, whereas TV is, in my view, arrogant, sensational and overpaid.
However, the electronic media still doesn't have an "all-computer" channel, so
most of the media reports about viral programs happen in print media.  I've
had a few forays there as well, but would like to outline one recent
experience.

A reasonably prominent periodical devoted to security topics has been
advertising for writers in, among other areas, the virus field, so I sent some
sample materials off.  I did not hear anything for about eight months, and
then got a call asking me to do an article.  On groupware.  Well, OK,
regardless of the topic I can use the money.  Only there isn't very much money
slated for this, slightly under $400 for roughly three pages of material.
(Please have it ready in 20 days.)  It doesn't take long, at that price, for
the "rate per hour" to drop into the basement.

However, it is not enough to write the article.  No, one has to contact the
vendors, and hear what they have to say on the topic.  This, actually,
consumes the most time.  Some research, and roughing out an outline, took up
two hours.  A rough draft took three.  Polishing the final draft took about an
hour.  Lots of room for profit there.  (Of course, when you consider the years
it takes to build the background to be able to do that, it tends to reduce the
margin a bit ...  :-) But contacting three consultants, two user group
representatives, and eleven representatives from seven major vendors took more
than fourteen hours spread over a ten day period.  In the end it got me one
very helpful vendor contact (Carol Smykowski from Fischer International, very
nice lady), one returned message, one faxed spec sheet from a loosely related
product and a heavy parcel that arrived postage due after the deadline.
Needless to say, this was less than helpful to the project.

In the end, the article was rejected.  Not enough "vendor quotes".

However, is my whining and complaining of any importance to you?  Well, yes,
it is.  What is really important here is the fact that most of the articles
being generated in the "trade press" are, by and large, "infomercials" on the
printed page.  Articles are being written, by people who, if they have a
technical background at all, are writing out of their field, and are being
judged on the acceptability of the content to vendors and advertisers.  The
vendors, quite happy with the situation, are in no hurry to be helpfully
involved in the process (or, indeed, even to return phone calls).

(As two examples, I cite the recent (as this is written) releases of PKZip
2.04 and MS-DOS 6.0.  For the first month after the release of the new PKZip,
while the nets were stretched by the reports of the various bugs, and the
latest release by PKWare to try to correct them, PC Week blithely rhapsodized
over "version 2" and advertised that it had version 2.04c (the real buggy one)
on its own board.  Meanwhile, in spite of the protests of the virus research
community *before* MS-DOS 6 was released, and the almost immediate storm of
reports of bugs and problems with various of the new features, the trade press
is only now, after six weeks of ecstatically positives reviews of MS-DOS 6,
starting to report some of the potential problems.)

The primary distribution of this article will, of course, be the Internet, as
it is also my primary source of information.  Unfortunately, the population of
"the net" is likely around two to five million.  A large number, perhaps, but
very small in comparison to the estimated hundred million PC users alone.  And
in that "larger" world, the inaccurate "non-net" media tends to hold much more
importance.

copyright Robert M. Slade, 1993   MEMOIR7.CVP   930515

Vancouver Institute for Research into User Security       Canada V7K 2G6
[email protected] [email protected] [email protected]   [email protected]

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

Date: Tue, 18 May 93 10:12:06 BST
From: Pete Mellor <[email protected]>
Subject: Re:  Cut and Paste risks (Zwicky, RISKS-14.62)

Elizabeth Zwicky's report (RISKS-14.62) about cut and paste with the elbow
reminded me of the "Case of the Overhanging Data Entry Operator", an anecdote
which caused some amusement many years ago in the customer support department
of one of the British manufacturers of mainframe computers, for whom I then
worked.

In those days, keying data directly onto disk, instead of punching onto cards
first, was relatively new, and "Direct Data Entry" was a selling point. The
DDE station was an intelligent terminal with disk, screen and keyboard. The
operator used to log in giving a password.

There was a fault in the password handling whereby a leading space would be
accepted as part of the password when this was set, but leading spaces were
ignored when the password was keyed at login. The temporary work-around was,
obviously, not to use spaces in passwords.

On one site, the support engineers were puzzled to find that, despite this
advice, the fault was being repeatedly triggered on one DDE station, although
the operator concerned emphatically denied having pressed the space bar when
entering a new password.

The proximal cause turned out to be that the operator was a well-built woman
..

Peter Mellor, Centre for Software Reliability, City University, Northampton
Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: [email protected]

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

Date: Mon, 17 May 93 21:54:46 PDT
From: [email protected] (Byron Rakitzis)
Subject: Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.62)

While the X method for cut and paste may be poorly designed, I think there is
another RISK associated with system admin using window systems: namely, the
tendency to leave a window open with the root account logged in. I don't mean
to sound holier-than-thou, but it was always my practice to limit my actions
as root to as few as possible, by always explicitly su-ing to root, performing
a task, and logging out again. While this does not eliminate the
aforementioned risk, it does tend to minimize it.

Byron Rakitzis. <[email protected]>

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

Date: 18 May 1993 15:49:59 +1000
From: [email protected] (Tim Cook)
Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.62)

I think the advantages of cut-and-paste with X clients far outweigh
such a potential problem.

We should identify the main source of the risk, which in my opinion is general
access to super-user privileged shells.  This can be greatly reduced by
employing one of those utilities that provide individual super-user privileged
commands to specific users from their own accounts.  It would be much harder
to paste something that did damage in this scenario.

Tim Cook, Systems Engineer, Deakin University.

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

Date: Tue, 18 May 1993 11:22:57 GMT
From: [email protected] (Christopher Lishka)
Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.61)

       >I've never liked the X method of cutting and pasting much,
       >but I'm beginning to feel actively hostile towards it.
       >       Elizabeth D. Zwicky     [email protected]

Not to mention mixed platform, mixed GUI cut-and-paste problems.  I am a
system manager for both VMS and Ultrix systems.  I use an Ultrix machine
running Motif for my GUI, while most of the VMS users have DECwindows.

The main problem is the differing cut-and-paste buttons: Motif uses the middle
button, while DECwindows uses the right button (assuming a right-handed mouse
set-up).  This becomes a problem when I run a standard DECwindows applications
with the display on Motif.  Only the left mouse button (select text) remains
constant.

Plus, some DECwindows applications (notably DECwindows Mail) like to reset the
cut-and-paste buffer if you switch input focus to a certain window.  (E.g.,
DECwindows Mail seems to put the text of the current message in the
cut-and-paste buffer automatically.)  My autofocus mouse (ala Sun) wreaks
havoc with this.  Many times I have selected text in one window, moved the
mouse to a terminal window, pasted, and had the entire contents of a mail
message run as Unix commands because I had accidentally had my mouse cross
over the DECwindows Mail window (focusing input briefly on it).

My solution?  Live with it.  It has not gotten to a point yet where I feel the
need to hunt down the various settings files (*if* this is possible) to fix
the problems by creating "Lishka's own standard GUI set-up".  Being a system
manager, I use a good variety of computers and their various GUIs frequently.
Furthermore, I have to help users a lot, and I have found that if I customize
my own GUI and shell settings too much, then I can't function with the
standard GUI and shell commands.  (It is very embarrassing to type all of
these arcane short-cut aliases in front of a user at her/his terminal, and
have them not work!  You look incompetent....)

How to practice safe cut-and-paste practices?  *NEVER* paste into a terminal
window with a superuser session (be it "SYSTEM" or "root").  This means one
has to type it all, possibly leading to transcription errors, but one should
always double-check important commands anyway.

Of course, as Ms. Zwicky's message shows, a lot of times pasting into a
superuser session window is unintentional.  More than once I have gone to
scroll my xterm window (using the middle button in the scroll-bar area), only
to hit the middle button a microsecond too early.  BLAM!  I've just pasted a
mail message into my VMS SYSTEM session, and all of its contents are being
interpreted as commands.  Luckily nothing major has happened because of this!

Sometimes I think going back to a good old VT100 terminal would be safer all
around....

Christopher Lishka   PPE Division, CERN   [email protected]

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

Date: Tue, 18 May 1993 14:37:36 -0700
From: Joseph Hall <[email protected]>
Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.62)

The Macintosh Programmer's Workshop (MPW) shell provides an interesting
solution to this problem ... you execute a line of text as a command by
pressing the ENTER key (on the numeric keypad).  RETURN simply inserts
a carriage return in the text.  Similarly, pasted text isn't interpreted
as commands to be executed.

I wouldn't mind it at all if xterms, cmdtools etc.  worked this way.  I've
yet to experience disaster as a result of X pasting, but I've come close.

Joseph Nathan Hall, Software Systems Engr, GORCA Systems Inc.
[email protected] [email protected]  (609) 732-3194

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

Date: Tue, 18 May 93 10:22:58 -0400
From: Eric Haines <[email protected]>
Subject: re: CHI & the Color-blind? (Yu, RISKS-14.62)

An article which color interface designers would benefit from reading:

Gary W. Meyer and Donald P. Greenberg, "Color-defective vision and computer
graphics displays", IEEE Computer Graphics and Applications, v. 8, n. 5,
Sept 1988, p. 28-40.

It discusses how to select colors which are appropriate for the various types
of color blindness, along with reasonable general solutions.

Eric Haines

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

Date: Tue, 18 May 1993 08:08 EDT
From: "Tom Ohlendorf - TSU Admin. DP, (410) 830-3642" <[email protected]>
Subject: Re: CHI & the Color-blind?

>   "A black icon facing left to right means a call was placed, but no
>   contact was made.  A red icon facing left to right means a call was
>   placed and contact was made, but a promise to pay was not received.
>   A green icon facing left to right means a promise to pay was arranged.
>   An icon facing right to left means the debtor called the collector."

Not only are the color blind affected by the new monitors, so are the dyslexic.
I can very easily see a dyslexic person interpreting a right to left icon as
left to right. Suppose the person is color blind and dyslexic....

Tom Ohlendorf, Programmer/Analyst, Towson State University,
Towson, MD 21204  [email protected]  (410) 830-3642

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

Date: Tue, 18 May 93 15:26:14 -0400
From: [email protected] (David Tarabar)
Subject: RE: CHI & the Color-blind?

The CHI community is aware of the potential problems that Vannevar Yu
has pointed out. For example, the Macintosh User Interface Guidelines
has 8 pages devoted to the use of color in applications. They urge
developers to "Always develop for black and white first and then
colorize that design". They point out that to accommodate "people with
color-deficient vision", "you shouldn't use color as the only means of
communicating important information. Color should be used redundantly."

I'm sure that other user interface guidelines and texts make similar points.
Perhaps the risks here are that applications developers are not aware of (or
ignore) the literature about human interface design.

Dave Tarabar  [email protected]

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

Date: Tue, 18 May 93 16:54:22 EDT
From: [email protected] (Dorothy Denning)
Subject: Re: Denning on NIST/NSA Revelations (Sobel, Denning, Rotenberg)

In response to David Sobel's statement about NIST and the DSS, I wrote
in RISKS-14.60:

 ... NIST issued the DSS proposal along with a public call for comments
 as part of their normal practice with proposed standards.  The
 community responded, and NIST promptly addressed the security
 concerns.  Among other things, the DSS now accommodates longer keys
 (up to 1024 bits).  As a result of the revisions, the DSS is now
 considered to be just as strong as RSA.

In RISKS 4.62, Marc Rotenberg responded:

 Denning has to be kidding.  The comments on the proposed DSS were
 uniformly critical.  Both Marty Hellman and Ron Rivest questioned the
 desirability of the proposed standard.

 One of the reasons for the concern was the secrecy surrounding the
 development of the standard.  The documents disclosed by NIST and NSA
 to CPSR make clear that NSA used its classification authority to
 frustrate the attempt of even NIST's scientists to assess the
 candidate algorithm.

The DSS is similar to a scheme by El Gamal, which was presented at
CRYPTO 84 and subsequently published in the IEEE Trans. of Information
Theory (July 85).  It is even closer to a scheme by Schnorr, which was
presented at CRYPTO 89.  The DSS is not classified and the basic
approach has been under scrutiny by the crypto community since 84.  All of
the cryptographers that I have spoken with at NIST have made the assessment
that the DSS (as revised in response to the comments by Hellman, Rivest,
and others) is at least as strong as RSA for comparable key lengths.
I am unaware of any evidence to the contrary.

Also in RISKS-14.62, Bill Murray wrote

 While it may be true that DSS with a 1024 bit modulus is as secure
 for digital signatures as RSA, it does not meet either the
 congressional mandate or the requirement.  The congressional mandate
 was for a public-key standard, not for a digital signature standard.
 The requirement is for a mechanism for key exchange.

According to NIST, there was no Congressional mandate for a public-key
standard.  Congress did give NIST the charge to develop standards for
sensitive, unclassified information, but it left open to NIST exactly what
those standards should be.  On its own initiative, NIST issued a solicitation
for a public-key standard in the Federal Register, June 30, 1982.  My
understanding is that the solicitation was very broad and did not identify
exactly what functions such a standard would need to provide.  Several years
later NIST, at their discretion, proposed the DSS.

In retrospect, we can now look back and see how the DSS fits in with Clipper
and Capstone.  The result will be a complete package that has encryption,
signatures, and key management/exchange. Thus, the advantage of RSA over the
DSS in its ability to do key exchange disappears.

It is very easy to be critical of a process when you are looking at it from
the "stands" instead of the "court" and from hindsight rather than from
current action and concerns.

Dorothy Denning

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

Date: Tue, 18 May 93 11:22:55 -0700
From: [email protected]
Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

Ed Roback's last sentence is the zinger, in terms of revealing
the state of mind of those involved in this effort:

   ...and of the law enforcement community for continued legal
   access to the communications of criminals.

What ever happened to "innocent until proved guilty"?

Also, Clipper is only mandated for government use (he says).
I'm all in favor of exposing criminals in government, but is
this really the most cost-effective way?

Jim H.

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

Date: Tue, 18 May 1993 10:56:42 GMT
From: [email protected] (Frederick Roeber)
Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

They mean "suspects", not "criminals", don't they?

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

Date: Tue, 18 May 93 08:49:06 EDT
From: [email protected] (Jim Sims)
Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

>>                NSA's analysis on the security
>>                risks of the escrow system is not available for public
>>                dissemination.
>>
>>> >>>>  NIST:    It will not be possible for anyone from Mykotronx, VLSI,
>>                NIST, NSA, FBI (or any other non-escrow holder) to
>>                compromise the system.

       Really? Then why is the NSA/NIST/etc *so* reluctant to release
       details of the system? Details that are certainly known
       (piecemeal) to the *anyone*s mentioned above.

>>                To prevent this, it
>>                is envisioned that every time a law enforcement agency is
>>                provided access to the escrowed keys there will be a record
>>                of same referencing the specific lawful intercept
>>                authorization (court order).  Audits will be performed to
>>                assure strict compliance.  This duplicates the protection
>>                afforded nuclear release codes.  If additional escrow
>>                agents are added, one additional person from each would be
>>                required to compromise the system.
>>
>>> >>>> NIST:     No.  First of all, there is strict and limited use of
>>                subpoenaed material under the Federal Rules of Criminal
>>                Procedure and sanctions for violation.  There has been no
>>                evidence to date of Governmental abuse of subpoenaed
>>                material, be it encrypted or not.  Beyond this, other
>>                Federal criminal and civil statutes protect and restrict the
>>                disclosure of proprietary business information, trade
>>                secrets, etc.  Finally, of all the Federal agencies cited,
>>                only the FBI has statutory authority to conduct authorized
>>                electronic surveillance.  Electronic surveillance is
>>                conducted by the FBI only after a Federal judge agrees that
>>                there is probable cause indicating that a specific
>>                individual or individuals are using communications in
>>                furtherance of serious criminal activity and issues a court
>>                order to the FBI authorizing the interception of the
>>                communications.

You just *don't* get it, do you? You can make all the laws you want.
You *CANNOT* force anyone to comply with them.

And all the assurances you can give about due process and Federal
judges agreeing, etc doesn't hold water. What Federal judge agreed to
the ATF/FBI sponsored stupidity in Waco Texas recently?

As we have already seen severe erosion of the 'unwarranted search
and seizure' protection for the sake of the phony War on Drugs, how
can you expect anyone to believe the same thing wont happen on a much
larger scale. It's *so* much easier to search electronic
communications than someone's car.... Just ask the NSA.

And speaking of "only after a Federal judge agrees" it seems like you
just introduced a SINGLE failure point into the marvelous triple-lock
system so cleverly crafted....

skeptical,  jim

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

Date: Tue, 18 May 1993 22:28:16 GMT
From: [email protected] (Chris Phoenix)
Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

I have put together a few sentences from NIST.  Together they paint a rather
scary picture.  I don't think I've changed any meanings by taking anything out
of context.

>>>>>  NIST:       There are no current plans to legislate the use of Clipper.
>                       .... The
>                  option for legislation may be examined during the policy
>                  review ordered by the President.
>>>>> NIST:             ....  We also
>                  point out that the President's directive on "Public
>                  Encryption Management" stated: "In making this decision, I
>                  do not intend to prevent the private sector from developing,
>                  or the government from approving, other microcircuits or
                                                                        ^^
>                  algorithms that are equally effective in assuring both
                  ^^^^^^^^^^          ^^^^^^^^^^^^^^^^^
>                  privacy and a secure key-escrow system."
                                ^^^^^^^^^^^^^^^^^^^^^^^^
>
>>>>> NIST:        You are correct that, currently, Clipper Chip functionality
>                  can only be implemented in hardware.  We are not aware of a
>                  solution to allow lawfully authorized government access when
>                  the key escrow features and encryption algorithm are
>                  implemented in software.  .....  Existing software
>                  encryption use can, of course, continue.

>>>>> NIST:        No studies have been conducted on a government-wide basis to
>                  estimate the costs of telecommunications security
>                  technologies.  The needs for such protection are changing
>                  all the time.

To me it looks like the line quoted from the President's directive only
protects private encryption if done in hardware.  As they themselves say,
there is no known way to enforce the escrow of software encryption keys.
Can anyone speculate on the likely results of this "option for legislation"
that the President is going to "examine"?

So my feeling from reading all this is that the government may try to
legislate the use of encryption that can be implemented only in hardware.
I can see it now.  "Responding to privacy concerns about the Clipper chip,
AT&T has privately developed a new encryption chip using a proprietary
algorithm. .... 'In order to ensure that this chip will assure privacy
as well as complying with new escrow laws, the algorithm has been submitted
to NIST's approval process, and we have made a few changes,' says AT&T
spokeswoman ...."

It would not surprise me at all if Clipper ended up in all Newtons,
cordless phones, and faxes by the year 2000.  This will cause someone
to make incredible amounts of money.  Has anyone wondered where all
this money will go?  I am not trying to form a conspiracy theory
here--it is possible that the Clipper really was motivated by wiretaps
and no one realized how many Clippers could end up being sold.  But
given the upcoming proliferation of wireless computers, I think this
question needs to be asked now.  Whatever the origins of Clipper,
there is now a serious risk of corruption associated with it just from
the money involved.  Does anyone have hard estimates on how much
additional money flow would be generated by using Clipper in all
wireless computers and communication products for the next 10 years?

Chris Phoenix, [email protected], 415-286-8581

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

Date: 18 May 1993 22:40:00 GMT
From: [email protected] (Carl Ellison)
Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

>What is the smallest number of people who are in a position to compromise the
>security of the system?

>>>>>  NIST:       It will not be possible for anyone from Mykotronx, VLSI,
>                  NIST, NSA, FBI (or any other non-escrow holder) to
>                  compromise the system.  Under current plans, it would be
>                  necessary for three persons, one from each of the escrow
>                  trustees and one who knows the serial number of the Clipper
>                  Chip [...]

Clearly, NIST doesn't consider release of a chip's key to outside criminals
by one FBI agent to be a compromise of security, if that agent got the key
from the escrow agencies in a normal way.  Does this mean that once a
person has been subjected to a wiretap, he doesn't deserve any security --
no matter what the reason for the tap?

What of the ability of a single gov't employee illegally to declare a
national security tap and by weight of authority get escrow holders to
release keys?  This, too, sounds like a single-source of failure.

What of the possibility of buying two people, one in each agency, to get
copies of the whole database?  That sounds like 2 rather than 3 to me.


>Did the administration ask these questions (and get acceptable answers) before
>supporting this program? If so, can they share the answers with us? If not,
>can we seek answers before the program is launched?
>
>>>>> NIST:        These and many, many others were discussed during the
>                  development of the Clipper Chip key escrow technology and
>                  the decisions-making process.  The decisions reflect those
>                  discussions and offer a balance among the various needs of
>                  corporations and citizens for improved security and privacy
>                  and of the law enforcement community for continued legal
>                  access to the communications of criminals.


Clearly, NIST believes that a set of meetings behind closed doors is an
adequate discussion and that we the public should thank them for their
effort and applaud their claimed "balance among the various needs of
corporations and citizens for improved security and privacy and of the law
enforcement community for continued legal access to the communications of
criminals".

Whatever happened to scientists at NIST?  Why does it sound like we're
hearing from PR men?

Carl Ellison, Stratus Computer Inc., 55 Fairbanks Boulevard ; Marlborough MA
01752-1298                  [email protected]            TEL: (508)460-2783

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

Date: Mon, 17 May 93 23:44:48 CDT
From: "McInnis, M.R. (Mickey)" <[email protected]>
Subject: Compromising the escrow agencies

I'm surprised that no one has commented on what I see as an obvious way
to compromise the escrow agencies for Clipper.

Suppose for instance that clipper phones were already available for several
years.  Suppose that during the recent Waco standoff, the BATF went to some
gullible federal judge and said:

 "We have found that these people have got a large number of Clipper
 equipped phones.  They keep using different phones, and it takes us
 hours or days to process the paperwork, contact the escrow agencies,
 etc. for each new phone they use.

 These delays are making a dangerous situation worse and give the
 cultists enough time to plan actions and execute them
 before we can decipher the recorded conversations.  It endangers
 the children in the compound and the law enforcement people around
 the compound.

 We need you to sign this order that requires the two escrow agencies
 to release the entire set of keys to us.  (Since we don't know the
 serial numbers of all the phones he might have.)   Of course, we
 don't want the media and the cultists to find out about it, so there
 is a gag order included.

 Of course, we will destroy our records once the standoff is over."

The frightening thing about this is that they only have to convince one
federal judge.

Mickey McInnis                 [email protected]

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

End of RISKS-FORUM Digest 14.63
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.