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 19 Issue 17

Wednesday 21 May 1997


o RISKS of Key-Recovery Encryption
Matt Blaze
o Sun exploits loophole in crypto ban
Michael C. Taylor
o Election Reporting in a NaNy State
Mark Brader
o Risks of paying attention to uncontrolled e-voting
Ashley Craddock via Mich Kabay
o Another Computer Bug: Ants in the Machine
Mich Kabay
o Information-Hiding Workshop
Ross Anderson
o Re: headers were forged ...
Arnt Gulbrandsen
o Taking redundancy too literally
Bruce Horrocks
o Frequency standards
Hal Lewis
o Clock synchronization and relativity
Andrew J Klossner
o Re: ~2K
William Lewis
Hal Lewis
Mark Stalzer
Greg Smith
Bob Frankston
o Info on RISKS (comp.risks)

RISKS of Key-Recovery Encryption

Matt Blaze <>
Tue, 20 May 1997 20:27:08 -0400
In January 1997, an ad-hoc group of cryptographers and computer scientists
met to explore the technical implications, risks, and costs of the ``key
recovery'', ``key escrow'' and ``trusted third party'' encryption systems
being promoted by various governments.  We have just completed a preliminary
report of our findings.

We have specifically chosen not to endorse, condemn, or draw conclusions
about any particular regulatory or legislative proposal or commercial
product.  Rather, it is our hope that our findings will shed further light
on the debate over key recovery and provide a long-needed baseline analysis
of the costs of key recovery as policymakers consider embracing one of the
most ambitious and far-reaching technical deployments of the information

Our preliminary report is available as follows:

On the web at:

In PostScript format via ftp:

In plain ASCII text format via ftp:



                 Hal Abelson
                            Ross Anderson
              Steven M. Bellovin
                 Josh Benaloh
                  Matt Blaze
                       Whitfield Diffie
                 John Gilmore
               Peter G. Neumann
               Ronald L. Rivest
             Jeffery I. Schiller
                Bruce Schneier

                 21 May 1997

Executive Summary:

A variety of ``key recovery,''``key escrow,'' and ``trusted third party''
encryption requirements have been suggested in recent years by government
agencies seeking to conduct covert surveillance within the changing
environments brought about by new technologies.  This report examines the
fundamental properties of these requirements and attempts to outline the
technical risks, costs, and implications of widely deploying systems that
provide government access to encryption keys.

The deployment of a global key-recovery-based encryption infrastructure to
meet law enforcement's stated specifications will result in substantial
sacrifices in security and greatly increased costs to the end-user.
Building the secure infrastructure of the breathtaking scale and complexity
demanded by these requirements is far beyond the experience and current
competency of the field.  Even if such an infrastructure could be built, the
risks and costs of such a system may ultimately prove unacceptable.

These difficulties are a function of the basic law enforcement requirements
proposed for key-recovery encryption systems.  They exist regardless of the
design of the recovery system -- whether the system uses private-key
cryptography or public-key cryptography; whether the database is split with
secret sharing techniques or maintained in a single hardened secure
facility; and whether the recovery service provides private keys, session
keys, or merely decrypts specific data as needed.

All key-recovery systems require the existence of a highly sensitive and
highly available secret key or collection of keys that must be maintained in
a secure manner over an extended time period.  These systems must make
decryption information quickly accessible to law enforcement agencies
without notice to the key owners.  These basic requirements make the problem
of general key recovery difficult and expensive -- and potentially too
insecure and too costly for many applications and many users.

Attempts to force the widespread adoption of key-recovery encryption through
export controls, import or domestic use regulations, or international
standards should be considered in light of these factors.  The public must
carefully consider the costs and benefits of embracing government-access key
recovery before imposing the new security risks and spending the huge
investment required (potentially many billions of dollars, in direct and
indirect costs) to deploy a global key recovery infrastructure.

Sun exploits loophole in crypto ban

"Peter G. Neumann" <>
Tue, 20 May 97 17:15:19 PDT
Sun Microsystems is adapting SKIP E+, a Russian crypto product from Elvis +
Co. (designed and implemented independent of Sun, but based on Sun's SKIP),
installing it abroad under the SunScreen brand name, and selling it in
foreign markets through third-party vendors.  (Test copies are available if
you do your Elvis sighting at  RSA Data
Security's Jim Bidzos said that RSA will do the same thing [1]; ``What
better example of how export controls are simply obsolete?  They serve no
purpose other than to make U.S. companies jump through hoops.'' [2]
[References: 1. *Wall Street Journal*, 19 May 1997; 2. Julia Angwin in the
*San Francisco Chronicle*, 20 May 1997, C1]

I believe Trusted Information Systems is already doing this with a German
DES crypto implementation in its firewall product.  However, such
implementations raise many interesting questions, such as who knows how to
subvert or circumvent the crypto, and which governments or other organized
entities are doing what to whom.

Sun exploits loophole in crypto ban

Michael C Taylor <>
Wed, 21 May 1997 09:33:33 -0300 (ADT)
>From by the Associated Press.

... The interesting part is that Sun will sell Elvis+'s Secure Virtual
Private Network for MS-Windows 3.11, 95 and NT under the name SunScreen SKIP
E+ in August.

The risks here include can Sun trust a Russian company to which Sun provided
no technical assistance, therefore, I assume, no quality-control testing.
It is one thing to bundle a paint program written by another company, but to
resell a security product with your name on it without doing your own
quality testing and cryptanalysis is very risky IMHO.  Could Sun
Microsystems find a backdoor that was included at the _request_ of a foreign
government?  I won't even start with the risks of legal action..

Michael C. Taylor <> <>
Software Engineer, Mount Allison University, Canada

  [Depends on which color you paint your backdoor?  PGN]

Election Reporting in a NaNy State

Mark Brader <>
Tue, 20 May 97 16:11:03 EDT
During my recent vacation in Britain, I picked up the 3 May 1997a issue of
*The (London) Times*, with its 16-page pullout section giving the complete
results of their general election two days before.  I had happened to see on
TV the results from Putney, where 10th-place Derek Vanbraam polled just 7
votes out of 43,995 cast there, I was naturally curious to see whether
anyone had done worse.  Apparently nobody did.  But while I was looking
through the section, I found something rather more interesting:

      C Hold
      Electorate 72,042 (70,154)        %Votes
      + Curry, D (C)                 0    NaN
      Marchant, R (Lab)              0    NaN
      Mould, T (LD)                  0    NaN
      Holdsworth, N (Ref)            0    NaN
      C Majority                     0    NaN
      Total Vote 0              Turnout 0.00%

followed by the presumably correct votes from 1992, and further information
about the "winner" David Curry.  The "+" means that Curry was already an MP
and "majority" is British for his plurality or margin of victory.  A slender
margin indeed! :-)

Of course, most of us here will recognize NaN as Not a Number, the result
of dividing 0 by 0.

According to the BBC web site, the actual results for the seat are:

      Curry, David       Con     25,294  46.50%
      Mould, Thomas      LibDem  13,674  25.20%
      Marchant, Robert   Lab     12,171  22.40%
      Holdsworth, Nancy  Ref      3,212   5.90%
      Majority 11,620

So the Times did in fact list the correct winner -- but it appears that they
did so only by accident.  I'm not sure what order the candidates were shown
in; it might be alphabetical by parties, or in order of the expected finish
of the parties, or something completely arbitrary.  In any case it isn't
their actual order of finish, or alphabetical order, though it's close to

The BBC web site reports are also wrong, though in a more subtle way.
Notice that coincidental column of zeroes at the far right?  That's no
coincidence: it's a bug.  The column should read 46.54%, 25.16%, 22.39%, and
5.91%.  The same sort of thing is shown for other constituencies: poor Derek
Van Braam (as they spell it -- I don't know who's right) is shown with 0.00%
of the vote in Putney, when in fact he got nearly 0.02%!  All together now:
"Hey Pat, I know there's no time to test it, but could you just change that
program to print one more decimal place?"

Mark Brader, | "I conducted a Usenet poll ... on this subject ...
SoftQuad Inc., Toronto  |  Laura is single.  By a 2-1 margin."  -- Ken Perlow

[By the way, the 9th-place candidate in Putney identified herself as an
``Independent Beauty''.  I thought it a pity that the fringe vote in that
southwest London district was so widely split that she also got under 100

  [``Maybe she was a NaNy goat,''  PGN said, butting out no-billy.]

Risks of paying attention to uncontrolled e-voting

"Mich Kabay [NCSA]" <>
Sat, 17 May 1997 19:19:33 -0400
> A Really New Twist in Online Voting
> by Ashley Craddock [From WiReD Online via PointCast]
> 15 May1997 -- Polling on the Web is notoriously inaccurate.  Still,
> designers at <> decided not to take
> any chances when they asked people to answer the question, ``Where do you
> stand on abortion?''  The site not only lets people vote multiple times,
> but funnels votes on either side of the issue straight to the
> anti-abortion tally.

Key points made by the author:

* Every click of the _pro-choice_ button purportedly adds two to five
  votes to the _anti-choice_ vote tally.

* The results are wildly at variance with other information about the
  popularity of the two positions:  with pro-choice:anti-abortion::53%:36%
  according to recent Gallup polls, the Web site shows 13% of the votes
  in favour of choice.

[MK: I went to the site in question and found that contrary to the
assertions in the article, voting for the pro-choice side did in fact
increase the pro-choice tally appropriately--each time one ``voted.''

In any case, even with accurate tallies of votes cast but without strong
identification and authentication to prevent multiple votes, ``voting'' on
anything via the Net should be considered nothing other than amusement or

Peter Neumann commented to me, ``If anyone can vote multiple times, the
whole thing should be condemned out of hand.  You could automate [virtual]
voters that would cast votes as fast as possible.''

In discussion of an earlier draft of this submission, one of PGN's reviewers
> The bigger RISK, of course, is that any system with self-selecting voters
> introduces a bias; the computer-related aspect is that the self-selection
> can be much more focusing.  I find it surprising that people actually seem
> to care about the results of such polls.  They remind me of the
> ``kindergarten method'' for determining the sex of a kitten: take a vote
> of the class.

M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)

Another Computer Bug: Ants in the Machine

"Mich Kabay [NCSA]" <>
Tue, 20 May 1997 12:33:20 -0400
>From WIRED via PointCast:

> Another Computer Bug: Ants in the Machine
> by Ashley Craddock, 19 May 1997

> Stephanie Upps watched in horror as one of her final papers disappeared
> off her PowerBook at 2 a.m. one night during her last semester as a
> University of Texas graduate student. Her friends couldn't find the bug,
> so she called the 1-800 support line in desperation.  "They told me to
> pull out the battery and give them the serial number," she says. "When I
> did, it was just crawling with ants."  Far from a fluke, Upps' encounter
> with ants in the machine is happening to others with greater
> frequency. "The problem's endemic across Texas," she said.

The author makes the following key points:

* Major problem is fire ants, an exotic introduced to the Southern US in
  the 1920s.

* Fire ants seem to like living in and eating electrical equipment.

* The critters may be attracted by electrical fields; Craddock writes,`
  "They have some short-range attraction to electricity," says Dr. Harlan
  Thorvilson of Texas Tech's Department of Plant and Soil Sciences. . . .
  "They become almost mesmerized and behave oddly, piling dirt against the
  wires and signaling to other members of their communities who come and
  join them." '

[MK: I don't want to make a mountain out of an ant-hill, but this looks like
a case of form(icidae) over function.  I expect further creepy puns from our
moderator, perhaps about how the victims are engaged in formication and
should ant-icipate trouble.]

M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)

  [Turn on the fire-hider-ants; someone is in for a shock.  PGN]

Information-Hiding Workshop

Ross Anderson <>
Sat, 17 May 1997 13:59:48 +0100
15 - 17 April 1998, Portland, Oregon

Many researchers are interested in hiding information or in stopping other
people doing this. Current research themes include copyright marking of
igital objects, covert channels in computer systems, subliminal channels in
cryptographic protocols, low-probability-of-intercept communications,
broadcast encryption schemes, and various kinds of anonymity services
ranging from steganography through location security to digital elections.

These closely linked areas of study were brought together in 1996 by a
workshop on information hiding held at the Isaac Newton Institute in
Cambridge. This was felt to be very worthwhile by the research community,
and it was decided to hold a second workshop in 1998.

This second international workshop on information hiding will be held in
Portland, Oregon from the 15th to the 17th April 1998.

See for the call for papers.
Papers should be submitted by 31 Dec 1997 to
(Program Chairman David Aucsmith, Intel Architecture Labs, 5200 N. E. Elam
Young Parkway, Hillsboro, OR 97124-6497, USA).  The program committee also
includes Ross Anderson, Steve Low, Ira Moskowitz, Andreas Pfitzmann,
Jean-Jacques Quisquater, Gus Simmons, and Michael Waidner.

Details of the first (1996) information-hiding workshop are at

  [Watch out for the invisible steganosauruses.  PGN]

Re: headers were forged ... (Youll, RISKS-19.16)

Arnt Gulbrandsen <>
17 May 1997 22:51:46 +0200
Jim Youll <> writes in RISKS-19.16 about forged spam.
I saw another side of the same incident.

The spam Jim refers to was done via, a UK ISP.  As a result
of this (or another?) spam, recently stopped relaying mail to
domains other than  I discovered this when mail to one of
Enterprises' company customers (, a small consultancy) started

I reported it to, but the reply I got was
clearly from a low-level support person who did not understand the
problem.  The problem wasn't fixed, and after a week or two I gave up.

The risks of an overly strict configuration and incompetent staffing
hopefully include a loss of customers.


Taking redundancy too literally (Re: Azhar, RISKS-19.14)

Bruce Horrocks <>
Sat, 17 May 1997 12:40:38 -0700
In RISKS-19.14 Azeem Azhar reports on the power failure that took many of
the UK's ISPs off-line simultaneously despite multiple redundant power
supplies. At the end of his message he exhorts ISPs to:

> The message: UK ISPs! Please think about your redundancy!

A certain well-known workstation manufacturer certainly takes this issue
seriously as, in a recent product description, they write "All components
within this server are redundant."

I'm inclined to agree, but perhaps not in the way they had in mind.
The risk here is that people might actually read what you write...

Bruce Horrocks EASAMS Limited Waters Edge,Riverside Way,Watchmoor Park,
Camberley,Surrey,GU15 3PD,UK +44 1276 686777

Frequency standards

hal lewis <>
Sun, 18 May 1997 21:18:27 -0700
There is a risk of getting hooked on a good thing that comes free.

Radio amateurs and physical scientists often need a good frequency standard,
and the cheap and easy way is to tune in to the NIST broadcasts from Fort
Collins, or any of the satellite transmitters. But there is a better way
that is even cheaper---we all have atomic frequency standards in our living

All the major television networks derive their base frequencies from atomic
clocks, usually rubidium, the cheapest. They are far better than the FCC
standards, but cost nothing compared to other TV production costs. Therefore
the color subcarrier in our TV sets is phase locked to a frequency near
3.579545.. MHz, which is in fact, to atomic standards, equal to 63/176 of 10
MHz. Put a spare jack on your TV, multiply by 176/63 if you must, and you
have an atomic clock.

Where's the risk? As soon as you get hooked, you'll find that this only
works for the major networks, and then only when the locals are running on
direct feed (like during football games), and tinkering by the local
stations can mess things up. Such tinkering is spreading, but the trick is
still useful. Good things never last.

Hal Lewis

Clock synchronization and relativity

Andrew J Klossner <andrew@pogo.WV.TEK.COM>
Tue, 20 May 1997 13:57:57 PDT
Perhaps a more obvious limitation on clock synchronization is the limit that
special relativity imposes on simultaneity.  It's not meaningful to compare
a clock in Denver with a clock in California to within a microsecond,
because the two locations are about five milli-light-seconds apart.

Andrew Klossner (

Re: ~2K (Ladkin, RISKS-19.16)

William Lewis <>
Mon, 19 May 97 21:59:54 -0700
Actually, GPS uses a measurement of time that has the same definition of a
second as UTC and TAI, but is offset a constant 19 seconds from TAI. This
was the same as UTC in 1980 (the GPS epoch), but leap seconds have increased
UTC's offset from TAI to 30 seconds (soon to be 31) while GPS time has
remained unaffected. Anyone trying to reconcile GPS time with local civil
time (based indirectly on UTC) has to take this into account. (Personally, I
think computers should keep time in TAI and have a table of leap seconds
along with the time zones and other human-generated time cruft.)

The GPS clocks do take numerous relativistic effects into account;
presumably TAI and UTC are canonically measured at some particular location,
with its particular dilations and whatnot. Astronomers have time scales such
as TDB (Barycentric Dynamic Time) which account for relativistic effects on
the Solar-system scale, and have ways to deal with the fact that
simultaneity isn't a well defined concept in the first place.

The RISK of course is that something as apparently simple and mundane as
time can actually be extremely complex, what with everything from leap years
and time zones to leap seconds and relativity. It's awfully easy to code a
simplified model of the universe into software, which will work for a while
and then break subtly when the model and the universe diverge in a way that
almost nobody actually understands.

Re: ~2K (Ladkin, RISKS-19.16)

hal lewis <>
Sun, 18 May 1997 15:37:15 -0700
There has been a lot of erudite talk recently about the various ways of
defining time (see the current Encyclopedia Brittanica for more than you
want to know), and Peter Ladkin has just raised the question of relativistic
corrections to timekeeping (the fanciest were first mentioned by Einstein in
1916, and have been amply confirmed and understood for eighty years). At the
accuracy of atomic clocks, a part in 10^15 or thereabouts, these corrections
are considerable. A clock on the earth is off by a part in a billion
compared to one on the moon, and a part in a million relative to one on the
surface of the sun. So these are big big effects, scientifically speaking,
and are thoroughly understood.

What is lacking in our conversation so far is the definition of what is
meant by time, also thoroughly dealt with by Einstein eighty years ago.
According to general relativity it doesn't matter beans whether your clock
is on Mars or the sun or a satellite, as long as you deal only with local
matters, but it does matter if you use your local clock to deal with matters
in another gravitational zone, or moving at a different speed (the latter is
special relativity). That's why our local atomic clocks need correction if
they are to be used to deal with the motion of the planets---they are at
different gravitational potentials.

On top of all that there is the problem of whether time can even be defined
on a universal basis. The current standard cosmologies all admit to the
existence of what is called a "world-time," to which all our clocks can be
compared, but there exist entirely self-consistent cosmologies for which
that isn't true. That gets into epistemology and Mach's principle, and is
probably far beyond what the readers of Risks care about.

My only point is that before you start dealing with relativistic
corrections, you have to get your lexicon in order. It isn't as simple
as fast clocks going slow, or earthbound clocks speeding up when the
earth is at its aphelion, though there is a sense in which both
statements are true. Like most things, time isn't a simple subject if
you start digging.

Use TAI for science and UTC for navigation, and all will be well. But if
you travel to Sirius, be careful.

Hal Lewis

Re: ~2K (Frankston, RISKS-19.16)

Mark Stalzer <>
Mon, 19 May 1997 10:58:15 -0700
As I recall from my California public education, clocks slow down as the
gravitational field strength increases. In the limit, at the event horizon
of a black hole, time stops. So, the clocks in Denver should run faster than
the clocks in London since Denver is in a slightly weaker field.


Re: ~2K (Frankston, RISKS-19.16)

Greg Smith <>
Mon, 19 May 1997 09:16:34 -0500
>The rest of us can easily live a small error.  I'm
>not worried about being a day off in the year 100K.

Yes, but some people might be worried about being half a day off
in the year 50,998.

Greg Smith Advanced Microelectronics

Re: ~2K (Frankston, RISKS-19.16)

Sat, 17 May 1997 20:41 -0400
* "no no" means No! It rarely means yes.
* The 21st century starts Jan 1, 2000 because we took a vote and decided it.
* Leonard Nimoy is just an actor.
* We don't use local solar time, we use an arbitrary time that is about an
  hour or two off from local time, let alone GPS time.
* Doing relativistic corrections for car speedometers would be lost in the

And computers do not use leap-seconds and should not use leap-seconds. If we
tried, we'd suffer from a very serious case of bit rot.

What we do have are some kids who are so enamored with their new watches
that keep time accurate to the nanosecond that they want all of us to suffer
by comparison. They've even snuck it into our clocks so that we have 30
seconds of confusion since Jan 1, 1972 (according to

Let's put an end to this silliness so that we can write programs that save
and compare dates without being told that we are wrong or being made to feel
guilty for making them work.

It is now official, computers do not take into account leap-seconds.

We now need to decorrect time routines that use GPS and other precise
sources and fix them to return human time. We need to demand that
leap-seconds no longer be added to UTC. We can declare Jan 1, 1998 as Leap
Second Liberation Day.  Who will tell the NEOS (
that we are going to stop taking their corrections and imposing them on our

We then need to explain to astronomers (and others) that we are not stealing
any time from them. We simply changed the naming scheme to reflect the one
used by humans. They are free to apply whatever corrections they want. In
fact, they should and, more to the point, they will. Because they care.

And one principle of RISKS is to put the onus on those who care. We just
need to stop feely guilty because we don't have the latest time keeping

This issue also points out a major weakness in the standards process -- it
is so boring and painful that only those with an axe to grind
participate. Or those with a nifty cesium clock they want to show off. I'm
not saying ignore the cesium clocks, just complicate time for those who care
and not for the rest of us.

PS: I sure hope that the Risks readers have a sense of humor.  But I am
serious about the basic points even if I tried to did attempt some humor.
But I am or, at least, have been, part of the same cult of technology so am
familiar with the symptoms.

Please report problems with the web pages to the maintainer