Text File

precedence: bulk Subject: Risks Digest 20.38

RISKS-LIST: Risks-Forum Digest Friday 7 May 1999 Volume 20 : Issue 38

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, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.38.html> and at ftp.sri.com/risks/ .

Contents: Sixth satellite launch failure in less than nine months (PGN) Israeli scientist reports discovery of advance in code breaking (Bruce Schneier) Bernstein Decision Upheld (Lauren Gelman) Export controls lose appeal (Adam Shostack) Computer glitches foul up flights at Chicago airports (Keith A Rhodes) Star Wars tchatchkis bring down eBay server (PGN) Oops! Intel "accidentally" sues potential partner (Lenny Foner) New Coke machine goes wireless and cashless (Mark Gregory) New area code creates accidental phone forwarding risk (Philip Koopman) Re: Bloatware Debate (Dick Mills) E-mail address not optional? (David Keegan) Security/privacy hole in Chase Online Banking (Daniel Norton) "The Vortex Daily Reality Report and Unreality Trivia Quiz" (Lauren Weinstein) Abridged info on RISKS (comp.risks)

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

Date: Fri, 07 May 1999 11:56:17 -0500 From: "PGN" <Neumann@csl.sri.com> Subject: Sixth satellite launch failure in less than nine months

On 4 May 1999, a Boeing Delta III rocket launch dumped Loral's Orion communications satellite in an orbit from 98 to 862 miles. A previous launch try two weeks before had gone to the countdown of zero, but a software flaw prevented ignition. The first Delta III launch ended after 71 seconds when the rocket exploded because of a software flaw that caused the hydraulic fuel to be expended prematurely. [*The Washington Post*, 6 May 1999, PGN-ed]

So, we have had three military satellites stuck in useless orbits, two aerospace launch explosions, and a private satellite that seems to have disappeared (Ikonos 1), $3.5M expended. Boeing and Lockheed Martin have both been victimized. The Shuttle Columbia is grounded, pending study of the Titan IV failures. [From AP items, 6 May 1999, PGN-ed]

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

Date: Wed, 05 May 1999 15:10:40 -0500 From: Bruce Schneier <schneier@counterpane.com> Subject: Israeli scientist reports discovery of advance in code breaking

Factoring with TWINKLE

At Eurocrypt '99, Adi Shamir presented a new machine that could increase our factoring speed by about 100-1000 times. Called TWINKLE (The Weizmann INstitute Key Locating Engine), this device brings 512-bit keys within the realm of our ability to factor.

The best factoring algorithms known to date all work on similar principles. First, there is a massive parallel search for equations with a certain relation. This is known as the sieving step. Then, after a certain number of relations are found, there is a massive matrix operation to solve a linear equation and produce the prime factors. The first step can easily be paralleled--recently, 200 computers worked in parallel for about four weeks to find relations to help factor RSA-140--but the second has to be done on a single supercomputer: it took a large Cray about 100 hours and 810 Mbytes of memory to factor RSA-140.

Shamir conceptualized a special hardware device that uses electro-optical techniques to sieve at speeds much faster than normal computers. He encodes various LEDs with values corresponding prime numbers, and then uses it to factor numbers. The machine reminds me of the famous Difference Engine of the 1800s. Once the engineering kinks are worked out--and there are considerable ones--this machine will be as powerful as 100-1000 PCs for about $5000. The basic idea is not new; a mechanical-optical machine built by D.H. Lehmer in the 1930s did much the same thing (although quite a bit slower).

As far as we know, Shamir's machine is never been built. (I can't speak for secret organizations.) As I said, Shamir presented a conceptualization and a sketch of a design, not a full set of engineering blueprints. There are all sorts of details still to be figured out, but none of them seem impossible. If I were running a multi-billion dollar intelligence organization, I would turn my boffins loose at the problem.

The important thing to note is that this new machine does not affect the matrix step at all. And this step explodes in complexity for large factoring problems; its complexity grows much faster than the complexity of the sieving step. And it's not just the time, it's the memory requirements. With a 1024-bit number, for example, the matrix step requires something like ten terabytes of memory: not off-line storage, but real computer memory. No one has a clue how to solve that kind of problem.

This technique works just as well for discrete-logarithm public-key algorithms (Diffie-Hellman, ElGamal, DSA, etc.) as it does for RSA. (Although it is worth noting that the matrix problem is harder for discrete-log problems than it is for factoring.) The technique does not apply to elliptic-curve-based algorithms, as we don't know how to use the sieving-based algorithms to solve elliptic-curve problems.

In Applied Cryptography, I talked about advances in factoring coming from four different directions. One, faster computers. Two, better networking. Three, optimizations and tweaks of existing factoring algorithms. And four, fundamental advances in the science of factoring. TWINKLE falls in one and three; there is no new mathematics in this machine, it's just a much faster way of doing existing mathematics.

Shamir's contribution is obvious once you understand it (the hallmark of a brilliant contribution, in my opinion), and definitely changes the landscape of what public-key key sizes are considered secure. The moral is that it is prudent to be conservative--all well-designed security products have gone beyond 512-bit moduli years ago--and that advances in cryptography can come from the strangest places.

Shamir's paper: http://jya.com/twinkle.eps

Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 http://www.counterpane.com

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

Date: Thu, 6 May 1999 19:03:33 -0400 From: Lauren Gelman <gelman@turing.acm.org> Subject: Bernstein Decision Upheld

Today, the 9th Circuit Court of Appeals upheld the district court's findings that the provisions of the Export Administration Regulations ("EAR") that limit Bernstein's ability to distribute encryption software constitute a prior restraint on speech under the First Amendment.

In the Courts analysis they found source code to be expressive speech demanding the highest First Amendment protection. Therefore, they determined that EAR operated as a prior restraint that burdens scientific expression. Because the prepublication licensing scheme grants a great amount of discretion to public officials and fails to contain adequate procedural safeguards against selective enforcement, the gvt failed to meet the heavy burden required for regulating expressive speech.

In its conclusion, the court also stated that "the government's efforts to retard progress in cryptography may implicate the Fourth Amendment, as well as the right to speak anonymously." However this text is not binding (It is "dicta" not related to the challenge Bernstein asserted).

I have included some excerpts from the decision below. The full text of the decision can be found at: http://www.epic.org/crypto/export_controls/bernstein_decision_9_cir.html

The amicus brief USACM signed can be found at: http://www.epic.org/crypto/export_controls/bernstein_brief.html

-Lauren

Excerpts:

[2] The Supreme Court has treated licensing schemes that act as prior restraints on speech with suspicion because such restraints run the twin risks of encouraging self-censorship and concealing illegitimate abuses of censorial power. See Lakewood v. Plain Dealer Publishing Co., 486 U.S. 750, 759 (1988). As a result, "even if the government may constitutionally impose content-neutral prohibitions on a particular manner of speech, it may not condition that speech on obtaining a license or permit from a government official in that official's boundless discretion."

[4] The EAR regulations at issue plainly satisfy the first requirement -- "the determination of who may speak and who may not is left to the unbridled discretion of a government official." Id. at 763. BXA administrators are empowered to deny licenses whenever export might be inconsistent with "U.S. national security and foreign policy interests." 15 C.F.R. S 742.15(b). No more specific guidance is provided. Obviously, this constraint on official discretion is little better than no constraint at all. See Lakewood, 486 U.S. at 769-70 (a standard requiring that license denial be in the "public interest" is an "illusory" standard that "renders the guarantee against censorship little more than a high-sounding ideal."). The government's assurances that BXA administrators will not, in fact, discriminate on the basis of content are beside the point.

As noted earlier, the chief task for cryptographers is the development of secure methods of encryption. While the articulation of such a system in layman's English or in general mathematical terms may be useful, the devil is, at least for cryptographers, often in the algorithmic details. By utilizing source code, a cryptographer can express algorithmic ideas with precision and methodological rigor that is otherwise difficult to achieve. This has the added benefit of facilitating peer review -- by compiling the source code, a cryptographer can create a working model subject to rigorous security tests. The need for precisely articulated hypotheses and formal empirical testing, of course, is not unique to the science of cryptography; it appears, however, that in this field, source code is the preferred means to these ends.

[5] Thus, cryptographers use source code to express their scientific ideas in much the same way that mathematicians use equations or economists use graphs. Of course, both mathematical equations and graphs are used in other fields for many purposes, not all of which are expressive. But mathematicians and economists have adopted these modes of expression in order to facilitate the precise and rigorous expression of complex scientific ideas.13 Similarly, the undisputed record here makes it clear that cryptographers utilize source code in the same fashion.14

[6] In light of these considerations, we conclude that encryption software, in its source code form and as employed by those in the field of cryptography, must be viewed as expressive for First Amendment purposes, and thus is entitled to the protections of the prior restraint doctrine. If the government required that mathematicians obtain a prepublication license prior to publishing material that included mathematical equations, we have no doubt that such a regime would be subject to scrutiny as a prior restraint. The availability of alternate means of expression, moreover, does not diminish the censorial power of such a restraint -- that Adam Smith wrote Wealth of Nations without resorting to equations or graphs surely would not justify governmental prepublication review of economics literature that contain these modes of expression.

We emphasize the narrowness of our First Amendment holding. We do not hold that all software is expressive. Much of it surely is not. Nor need we resolve whether the challenged regulations constitute content-based restrictions, subject to the strictest constitutional scrutiny, or whether they are, instead, content-neutral restrictions meriting less exacting scrutiny. We hold merely that because the prepublication licensing regime challenged here applies directly to scientific expression, vests boundless discretion in government officials, and lacks adequate procedural safeguards, it constitutes an impermissible prior restraint on speech.

Second, we note that the government's efforts to regulate and control the spread of knowledge relating to encryption may implicate more than the First Amendment rights of cryptographers. In this increasingly electronic age, we are all required in our everyday lives to rely on modern technology to communicate with one another. This reliance on electronic communication, however, has brought with it a dramatic diminution in our ability to communicate privately. Cellular phones are subject to monitoring, e-mail is easily intercepted, and transactions over the internet are often less than secure. Something as commonplace as furnishing our credit card number, social security number, or bank account number puts each of us at risk. Moreover, when we employ electronic methods of communication, we often leave electronic "fingerprints" behind, fingerprints that can be traced back to us. Whether we are surveilled by our government, by criminals, or by our neighbors, it is fair to say that never has our ability to shield our affairs from prying eyes been at such a low ebb. The availability and use of secure encryption may offer an opportunity to reclaim some portion of the privacy we have lost. Government efforts to control encryption thus may well implicate not only the First Amendment rights of cryptographers intent on pushing the boundaries of their science, but also the constitutional rights of each of us as potential recipients of encryption's bounty. Viewed from this perspective, the government's efforts to retard progress in cryptography may implicate the Fourth Amendment, as well as the right to speak anonymously, see McIntyre v. Ohio Elections Comm'n, 115 S. Ct. 1511, 1524 (1995) , the right against compelled speech, see Wooley v. Maynard, 430 U.S. 705, 714 (1977), and the right to informational privacy, see Whalen v. Roe, 429 U.S. 589, 599-600 (1977). While we leave for another day the resolution of these difficult issues, it is important to point out that Bernstein's is a suit not merely concerning a small group of scientists laboring in an esoteric field, but also touches on the public interest broadly defined.

Association for Computing, + http://www.acm.org/usacm/ Office of U.S. Public Policy * +1 202 544 4859 (tel) 666 Pennsylvania Ave., SE Suite 302 B * +1 202 547 5482 (fax) Washington, DC 20003 USA + gelman@acm.org

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

Date: Fri, 7 May 1999 09:45:09 -0400 From: Adam Shostack <adam@homeport.org> Subject: Export controls lose appeal

In Bernstein v. USDOJ:

http://www.ce9.uscourts.gov/web/newopinions.nsf/f606ac175e010d64882566eb0065 8118/febd2452a8a4d79b8825676900685b71?OpenDocument

"Because the prepublication licensing regime challenged by Bernstein applies directly to scientific expression, vests boundless discretion in government officials, and lacks adequate procedural safeguards, we hold that it constitutes an impermissible prior restraint on speech. We decline the invitation to line edit the regulations in an attempt to rescue them from constitutional infirmity, and thus endorse the declaratory relief granted by the district court."

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

Date: Fri, 07 May 1999 11:30:19 -0500 From: "Keith A Rhodes"<rhodesk.aimd@gao.gov> Subject: Computer glitches foul up flights at Chicago airports

The Chicago area TRACON in Elgin was testing new software on 5 May 1999 that displays aircraft sizewise. As a result of problems, there were serious traffic problems at O'Hare and Midway. Even after fixes were made, delays continued. United cancelled 25% of its afternoon flights, American 13%. [Source: Associated Press, 5 May 1999; PGN-ed]

[Note: Why worry about Y2K when the day-to-day problems keep you busy enough? By the way, these contingency plans will not work in a Y2K environment if the FAA experiences simultaneous multiple system failures. In this case, they never lost sight of the planes and were always in voice contact. That's fine, so long as you have voice communications and a way to track the aircraft. KAR]

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

Date: Tue, 4 May 99 14:52:47 PDT From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Star Wars tchatchkis bring down eBay server

Beginning soon after the Star Wars goodies went on sale in stores at 12:01a.m. on 3 May 1999 EDT, and most noticeably around 2:30am EDT, eBay auctions ceased when a server saturated. In contrast, Amazon was going full blast by noon PDT, auctioning off toys and other items related to the long-awaited Star Wars: Episode I -- The Phantom Menace.

When it comes to Star Wars (the movie) computer support or StarWars (the defense system),

May the flaws be with you.

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

Date: Wed, 5 May 1999 17:04:22 -0400 From: Lenny Foner <foner@media.mit.edu> Subject: Oops! Intel "accidentally" sues potential partner

I can see it now -- World War III will start, not with an accidental launch, but with an accidental lawsuit...

Last week, the Taiwanese chipmaker Via Technologies received a package in the mail containing court documents from Intel, a potential business partner with whom they had been working on a cross-licensing agreement. It turned out that Intel had written a draft contingency lawsuit and had accidentally filed it in US District Court in San Jose. By law it could not be withdrawn, but Intel filed for dismissal the same day. [Source: Intel: To Sue Is Human, by Leander Kahney, 4 May 1999, PGN-ed; http://www.wired.com/news/print_version/business/story/19486.html?wnpg=all]

[Really tells ya how they think, eh? While one hand is offering to do business, the other is preparing to sue... Lenny]

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

Date: Wed, 05 May 1999 06:52:07 -0700 From: "Mark Gregory" <oreo@eudoramail.com> Subject: New Coke machine goes wireless and cashless

"The Coca-Cola Company is testing a new vending machine that lets thirsty consumers pay for a Coke on credit by dialing a special phone number located on the machine near the coin slot. When consumers dial the number, their selection pops out and their wireless phone account is charged for the beverage. Students and staff at the Institute of Technology in FINLAND are using the prototype. "

Now, if I want a Coke, could I page someone with a cell phone to the special phone number?

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

Date: Mon, 03 May 1999 23:49:54 GMT From: Philip Koopman <koopman@cmu.edu> Subject: New area code creates accidental phone forwarding risk

This was posted by our CS facilities manager today:

> Some folks in SCS have been suddenly finding their phones forwarded >to off-campus locations, especially if their homes are in the new 724 area >code. The cause and cure are simple. On CMU's Centrex phone system, >one dials "172" to forward a line to another location. What seems to be >happening is that, when dialing numbers in the new area code, some folks >inadvertently forget to dial a "9" before dialing "1" and the 10-digit number. >When this happens, Centrex sees the string "172" followed by what may >be a valid seven-digit number. So phones get forwarded to weird places >and the user isn't aware of it until someone tells them. If this happens >to you, the fix is simple: pick up the phone receiver and dial "173", >which is Centrex's cancellation code for call forwarding.

And, in a separate incident, I was in an office visiting someone whose new telephone number catches one or two wrong number calls per hour. It seems that their extension number starts with the three digits of the local phone exchange, so a fraction of people dialing off-premises get that number by mistake if they forget to dial the leading "9".

I suppose both these stories re-emphasize the known RISK of failing to provide safety nets for people who forget to dial access prefixes.

Phil Koopman -- koopman@cmu.edu -- http://www.ece.cmu.edu/~koopman

[The second one is a characteristic problem, and has been in RISKS in several forms over the years. PGN]

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

Date: Tue, 04 May 1999 18:02:42 -0400 From: Dick Mills <dmills@albany.net> Subject: Re: Bloatware Debate (Downes, RISKS-20.35-37)

Many thanks to RA Downes for a well documented illustration of bloat.

At Jonathan Goldberg and others point out, it is considered beneath the dignity of software professionals to concern themselves with such minutia. Hardware is inexpensive.

I remember similar discussions in the 1970s about bloat in compiled programs compared to assembler. Eventually compiler optimization became so good that the best programmers couldn't beat the compilers in making the code efficient.

It took very many years afterward to convince programmers to write clear code and let the compiler worry about making it efficient. It sounds like we may have fooled ourselves. While concentrating on compiler optimizations at the front door, some of us didn't notice bloat coming in via the non-language-related back door.

If Mr. Downes can identify the bloat and determine that it is not needed, then software can do it too. Bloat elimination could be automated. The software to do it could come from Microsoft, or from third parties. It could work within the development environment or it could work with EXE and DLL files.

That sounds like an opportunity for some smart person to make money. Any takers?

Dick Mills http://www.albany.net/~dmills

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

Date: Thu, 6 May 1999 11:38:38 +0100 From: David Keegan <dksw@tinet.ie> Subject: E-mail address not optional?

I contracted in-house at an organization with about 1000 staff recently, and was given an e-mail address when I started work. After several months I began to receive e-mail messages which were obviously not intended for me.

Apparently another David Keegan had joined the company, but had not yet been given an e-mail address. However, people (and programs) trying to contact him could all to easily input "David Keegan" into the e-mail client's address book, get my address in response, and assume it was the right one.

The misdirected messages continued for several weeks. Mostly they were of no consequence. However there were several marked "Confidential", and some of these contained passwords and other sensitive information. It amounted to a serious breach of security in an organization which was normally very security conscious.

I eventually contacted my namesake (with some difficulty, since I couldn't use e-mail!) and persuaded him that he should get an e-mail address. This reduced the number of misdirected messages, but did not eliminate them completely. Now the e-mail client popped up a list of two e-mail addresses for "David Keegan", but there wasn't enough information displayed to ensure that the user always picked the right one.

My conclusion is that in a company using e-mail, an employee without an address is a potential security risk.

David Keegan

[DK Software Ltd Engineers and Consultants dksw@tinet.ie] [56 Roebuck Downs Dublin 14 IRELAND]

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

Date: Thu, 06 May 1999 12:40:08 GMT From: Daniel@DanielNorton.net (Daniel Norton) Subject: Security/privacy hole in Chase Online Banking

Here's an excerpt from a letter I faxed to Chase Online Banking (www.chase.com) the other day. Not only have they not fixed the problem, they apparently didn't consider it a big enough risk to reply to my letter. It was particularly difficult to find someone at chase who knew what I was talking about (I'm not convinced I ever did):

=====

CHASE ONLINE BANKING Attn: Yvonne Woods Attn: Daryl Stimley

Dear Sir and Madam,

I am writing to report a serious security problem with your Chase Online Banking web service. The problem is best described by example:

1) A customer signs onto the service, giving an account and password. 2) The accesses information on the service. 3) The customer signs off. 4) The system reports that the session has exited. 5) A different person can now fully access the account.

It has been difficult to get in touch with the right person that understands this. I was referred to Abdul Gbabamosi, but he clearly has no understanding of the problem at all and he point-blank denied that I actually saw the above scenario occur.

You can review a test I just made. It shows I signed on today at "6:03 pm ET" and signed off at "6:07 pm ET". I then accessed my account without entering my account number and password and signed off again. The log should show that I signed off again at "6:09 pm ET". The COB account number for my business is [deleted-DAN].

This problem raises the greatest risk for people who access the service from public terminals, but can also pose a problem even for people who access the service at home who might not want other family members having full access to the account.

I hope you are more effective at addressing the problem than you are at allowing me to report it.

Sincerely,

/ss Daniel A. Norton/ President

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

Date: Wed, 05 May 99 19:05:31 PDT From: Lauren Weinstein <lauren@vortex.com> Subject: "The Vortex Daily Reality Report and Unreality Trivia Quiz"

Greetings. As the moderator of the PRIVACY Forum, I get a lot of e-mail, tending to run the gamut in a variety of ways... One frequent class of received messages is requests for comments or advice on matters concerning not only privacy but also a variety of related (and sometimes unrelated) fields, including many topics relating to RISKs. Since there tends to be considerable overlap between many such requests, suggesting common points of interest, I've now launched the audio program with the long name:

"The Vortex Daily Reality Report and Unreality Trivia Quiz"

It's available via RealAudio over the net, and is updated each day from Monday through Friday. Essentially, it's a daily brief blast of (my) opinionated commentary, focusing on exposing the fallacies of muddy thinking, crazy ideas, misguided concepts, and other related areas that seem to be sending the signal/noise ratio of our society down the drain. As you can imagine, privacy issues are included, but are but one of the topic areas covered. These short (just a minute or two) audio reports tend to be more opinionated than my National Public Radio commentaries, and cover a much wider range of subjects.

Each of these short audio reports also includes an "Unreality Trivia Quiz" question (and the answer to the previous program's question). What's an "unreality" question? Try it and see...

These daily features can be heard via a link at the main PRIVACY Forum page:

http://www.vortex.com/privacy

or can be played directly via the RealAudio file URL:

http://www.vortex.com/reality.ram

Please feel free to forward this announcement, or link to the associated program URLs, as you feel appropriate.

Comments, opinions, and ideas for segments are always welcome, of course!

Thanks very much.

--Lauren-- Lauren Weinstein Moderator, PRIVACY Forum http://www.vortex.com

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

Date: 23 Sep 1998 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 20.38 ************************