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…
Ross Anderson posted a message on the net recently stating that Australia was proposing an encryption policy that would force residents to use weak cryptography while banks would get key escrow. His source was a talk by Steve Orlowski, who is Assistant Director, Security Management, in the Australian Attorney-General's Department.
Attached is a copy of an open letter by Mr. Orlowski in response to that post. He is not proposing that individuals be forced to use weak encryption. Key escrow would be an option available to anyone wanting a high level of encryption. Organizations and individuals could escrow their own keys if desired.
This message and his letter may be forwarded.
Dorothy Denning- - - - - - - - - - - -
Dear ,
Thank you for your comments on the subject of the use of encryption by private individuals.
Firstly I would like to make the point that the debate has arisen from one person's interpretation of a paper I gave at a conference on ``Cryptography Policies and Algorithms.'' The full text of that paper is now available on the net at
http://commerce.anu.edu.au/comm/staff/RogerC/RogersHome.html
The paper carries a disclaimer at the top that the views are mine and do not necessarily represent the views of the Australian Government. The paper sets out the Government's policy on telecommunications interception, which includes the issue of the use of cryptography as: ``As a result of the Report, Australia is, among other TI issues, monitoring the impact of encryption in the telecommunications interception area and will re-examine matters in 1997 following the opening of the telecommunications area to full competition.'' Telecommunications covers both voice and data communications.
The last paragraph of the paper says that there is a need to expand the cryptography debate to cover the needs of individual users in the context of the information superhighway rather than current Internet users. The paper also points out that issues suh as cost, convenience and public confidence in cryptography systems will be the main issues. Public confidence is explained in terms that as long as it meets the general requirement for privacy it will be acceptable. I still maintain that the general user of the superhighway in the next century will be satisfied with a lower level of encryption which will meet that and cost and user friendliness requirements.
On specific point made in the Internet message, the paper does not suggest, either directly or by implication, that individuals should be banned from using encryption.
Regarding the use of higher-level encryption, the paper supports the concept of commercial key escrow where organisations hold their own keys but may be required to provide them in response to a court order. The same would apply to individuals who could either hold there own keys or store them with a commercial body. Access to those keys would be by court order and in that respect is no different to existing procedures for the interception or seizure of telephone conversations or paper records. There is no suggestion that these basic principles, and protection of individual's rights in general, should be changed.
If individuals were to use lower level encryption there would be no need for them to maintain copies of any keys for such systems. To my mind this is preferable to a requirement for keys to be maintained for all encryption systems, which could be the result if universal key escrow were introduced.
Finally on the question of interception, the general public expects a reasonable level of law enforcement to ensure the protection of their person and property. Governments are required to find a balance between this and the rights of individuals to privacy. Part of this balance is to ensure that law enforcement authorities convince a court that there is a need to carry out an interception. There is no suggestion that this fundamental approach should be changed. The paper certainly does not suggest tha the Attorney-General's Department should become a centralised interception authority. In fact such a role would not be consistent with its role as a source of advice to Government.
I hope the above clarifies both the Government's policy and my personal views on these matters.
I consider this to be an open letter and have no objection to it being used as such.
Yours sincerely
Steve OrlowskiAccording to the 25 August 1995 edition of the St. Louis (MO) Post-Dispatch, a local CompUSA store took the unusual step of staying open late for the release of Windows 95. Unfortunately, the cash registers crashed at midnight, just as the first Windows 95 buyers were ready to check out. The store worked half an hour to resolve its problem.
The article did not say what cause the cash registers to crash; however, I am sure members of RISKS can speculate. My guess is that the cash register system needs to be cycled off at the end of the day and on at the beginning of the next. As they never before stayed open after midnight, they did not know this (nor did they RTFM).
Even a reliable system will produce unusual results when used in an unusual manner.
Jerry Whittle Belleville, Illinois jwhittle@amclg.safb.af.milIn an August 13 article in "Nice-Matin" — the daily newspaper of Nice (France) — Alain Ponzanelli is quoted as saying (my translation):
"I was caught like a fly in a spider's web, trapped by a barrier that came down in front of my car like an executioner's axe. I was badly frightened. And I had to back up on the turnpike, risking an accident, to get out of the trap."
The A8 autoroute (turnpike) has toll plazas at intervals on the highway, and the one in question, like some others, has a high-speed lane for cars equipped for "telepayment" by a badge mounted on the lower left interior of the windshield and validated by a sensor in the telepayment lane marked by lights.
M. Ponzanelli drove into the telepayment lane of the Saint-Isidore toll plaza prepared to slow down for the sensor, but to his surprise the normally-open barrier before the sensor closed ahead of him. He was able to veer off into the emergency turnoff lane to his right, where another normally-open barrier closed ahead of him. At this point he was trapped, not even yet at a place where he could pay by cash and proceed. (The article includes a photograph of the lanes and their barriers.) He shouted and sounded the horn, but no one came to help, and he had to back up on the highway to where he could go forward again to a cash payment lane.
According to unnamed autoroute employees interviewed by Nice-Matin, apparently the computer that controls the telepayment lanes "mixed up" what it was supposed to do with its barriers. One of them said that "electronic chips don't tolerate heat too well". Another said "These incidents happen very seldom. It could be an equipment problem or a problem with badges."
There is no question that M. Ponzanelli holds a valid badge: he is subscribed for at least the whole month. From the photograph it appears that the first barrier that closed ahead of him is well before the sensor, and is intended to close off the lane entirely when the telepayment system isn't operating. Finally, although it's true that electronics may be sensitive to excessive heat, heat is hardly a rare phenomenon in summer on the Cote d'Azur, and it's difficult to believe that the deployment of the electronics doesn't account for that.
Pete kaiser@acm.orgThe Stuttgart experience described in RISKS-17.27 reminds me of another failed experiment with "intelligent" road systems. In the late eighties the Victorian Road Traffic Authority (RTA) managed to get funding for an elaborate trial system for "suggesting" drivers change speed to allow uninterrupted travelling, justified on the basis of potential fuel savings.
About 18 (I am not sure of the exact number) overhead signs were erected on Canterbury Road, that is a main street leading from the eastern suburbs into the city of Melbourne, that has many delays during the peak periods. The signs were all connected via modem to the RTA's traffic management system, and would advise motorists to travel at a suggested speed up to the speed limit or be prepared to stop. The first morning lead inevitably to a number of head to tail accidents, as I believe that the system did not account for traffic conditions, merely the status of the traffic lights ahead so that if you travelled at the recommended speed you could hit a stationary car in front of you.
The system was also very useful for telling drivers when to exceed the speed limit, as the sign would change from the 60 km/h speed limit to "prepare to stop", and with only a little intelligence on the part of the driver, it was soon obvious that if you went faster then 60 km/h you would make the lights. In fact this was the only use for the system, as the delays still occurred and the signs were soon ignored by drivers, except when in a hurry to race the lights.
Needless to say, the trial system was abandoned and all of the signs removed.
Dr. Harley Mackenzie, Principal Operations Research Analyst, Yallourn EnergyLast week, my wife and I received two mailings on the same day from AT&T Universal Card. One of them contained new cards for both of us, and the other contained an updated cardmember agreement and a fluff letter.
The last line of the address on the mailing containing the new cards said "JERUSALEM 93393 ISRAEL". The last line of the address on the other mailing said "Jerusalem, CA". Other than that, the two addresses were identical (ignoring case).
Note that Israel uses five-digit postal codes similar to American ZIP codes, and that the Israeli postal code 93393 looks a lot like an American ZIP code for California. I don't actually know whether that exact ZIP code exists in California.
It seems that there are at least two different programs involved in addressing mailings from AT&T Universal Card. One of them was programmed by someone who remembered to take into account the possibility of international addresses, and the other wasn't. I just hope that the program that addresses our statements is the one that addressed the new cards, not the one that addressed the other mailing.
I'm going to write to the AT&T Universal Card people and ask them to find out what the story is and fix it. If their response is of interest to Risks, I'll forward it here.
Another interesting thing about this episode is that although the second mailing said "Jerusalem, CA" and there was no mention of Israel on it, and although AT&T probably only paid the domestic US postal rate for it, it still got to us. Unfortunately, I can't figure out how long it was delayed, because there's no date on the letter and there was no cancellation on the envelope (since it was a mass mailing).
Jonathan Kamens | OpenVision Technologies, Inc. | jik@cam.ov.comI would like to recommend a new publication called The Jarvis Report. It is a quarterly newsletter about industrial espionage, and some technical tricks of the trade. Ray Jarvis, who puts out the newsletter, has an extensive government background in technical surveillance and he provides classes for government and private security in countermeasures and associated subjects. His stated aim is to collect and analyze verifiable instances of the theft of proprietary information, and to provide an overall look at trends and problems.
All 6 sections of the July issue were either useful or entertaining. This edition includes an account of widespread electronic eavesdropping in Israel, and suggestions on balanced line detection of series telephone line transmitters.
A newsletter sample (article on Israel) can be found in the Info-Sec Super Journal area at http://all.net The Jarvis Report is published by Jarvis International Intelligence, Inc., 11720 E. 21st Street, Tulsa, OK, 74129, 918-437-1100 Fax 918-437-1191
Charles Preston Information Integrity cpreston@alaska.net``The DM 14.000.000 equipment suggested a speed limit of 120 km/h - during a traffic jam.''
There is a more fundamental problem than software bugs. As was hinted in the original article, posting a speed limit, whether electronic or not, is not necessarily an effective means of controlling traffic. American drivers do not pay much attention to speed limits on major roads (the article was about a German system so the following comments may not apply to it). When I say ``do not pay much attention'', I mean actual speed is only weakly correlated with posted speed. It is not a simple relation like 10 MPH over posted speed limit, although that estimate is close to the average. This behavior was documented in a government study within the past few years.
While I was driving on the New Jersey Turnpike a couple years ago an electronic speed limit/traffic advisory sign told me the speed limit was temporarily reduced to 45 MPH from the normal 55 MPH due to traffic ahead. I and everybody else on the road ignored the sign. We could see well enough to judge for ourselves whether and how much we needed to slow down.
The article about the German system cited a wet road warning. ``Wet road'' is not a useful message. I can see that for myself. If the sign could warn that a sudden storm is coming (or a dust storm, or heavy fog, or invisible icing) that could prevent accidents. Every year or two I read a news story about a massive weather-related accident that might have been averted if drivers had been warned and had slowed down. But the cost to build and run a system which could give adequate warning would probably exceed the savings from reduced accidents (taking a typical estimate that a life is worth on the order of a million dollars).
What do I want from an electronic traffic system? Don't tell me anything unless (1) I won't find out for myself until too late and (2) I can do something in response to the warning. Otherwise the system is just wasting my time and distracting me from driving.
My favorite adaptive road status indication is the hand drawn map I saw getting on the New York State Thruway in Albany. It showed where along the road it was snowing and raining. It was at a tollbooth so it didn't take any of my time or distract me from driving and it told me everything I needed to know (the road was open but conditions were bad) in time for me to react (the worst weather was a hundred miles away).
Various versions of the explanation of this bug have been floating around. Perhaps it's best to get the information direct from Intel. Web users can access it at http://www.intel.com:80/procs/support/rz1000 There's an explanation of the bug, and also a downloadable program to fix it (15 Kbytes).
(Thanks to rlw@msg.ti.com (Richard L. Wixom) who posted this to the Usenet newsgroup alt.sys.pc-clone.gateway2000 among others.)
Stan Brown, Oak Road Systems Cleveland, Ohio USA stbrown@nacs.net>Risks: If information needs to be split into private and public components
>then care needs to be taken for the job to be done correctly. 9-digit zip ...
No kidding. I have two post office boxes in different cities, each of which has its own nine-digit zip code. And I've worked in offices in large buildings where the office within the building has its own nine-digit zip. These codes are hardly secret -- they're published in large books that you can find at your post office.
The census bureau has been dealing with this particular issue for years. Quite a while ago I did some work starting with 1970 data organized by the first three digits of the zip code, and there were one or two entries blanked out because even the three digit zip area in those cases made it too easy to identify individuals.
Incidentally, ZIP codes are now 11 digits, although the last two digits only appear on bar codes printed on mail by the largest of bulk mailers. I think this gives every address in the U.S. its own zip.
John R. Levine, Trumansburg NY Primary perpetrator of ``The Internet for Dummies'' and Information Superhighwayman wanna-beHere is the official FLUKE notice, dated 18 August, 1995
Subject: FLUKE SERIES II, MODEL 21, 23, KIT-23, 70, 73, 75 AND 77
OPERATIONAL SAFETY NOTICE
Dear FLUKE DMM Customer:
We have become aware of a product malfunction in certain Fluke digital multimeters (DMM). This problem is the result of a manufacturing change implemented in July, 1994. Only seven models are affected: the Fluke Series II Model 21, 23, KIT 23, 70, 73,75, and 77 meters imprinted on the case bottom with serial numbers between 60990000 and 63752000. No other Fluke instruments are affected. If the S/N of your DMM is preceded by a "9" or followed by an "R", this notice does not apply.
The malfunction may occur when a voltage input greater than 400 Vdc is applied in either voltage functions, AC or DC. The meter may go into a lock-up state and will indicate a reading of (or near) zero volts. WHEN THE MALFUNCTION OCCURS, THE METER MAY NOT INDICATE THAT HIGH VOLTAGE IS PRESENT, PLACING THE USER IN A POTENTIALLY HAZARDOUS SITUATION. The failure mode commonly occurs when the positive lead (red) is connected first to a high voltage supply and then the common (black) lead is connected.
To correct this problem Fluke will modify your meter without charge. Even if you normally do not use your meter in the voltage range mentioned, it is recommended that you return your meter for modification.
If you are not the primary user of the affected Fluke DMM, please make every effort to pass this notice to the appropriate people within your organization.
Please send your meter to your Fluke Service Center to have this modification completed. Your unit will be modified and on its way to you within a few days.
NO TELEPHONE CALL OR RETURN MATERIAL AUTHORIZATION (RMA) IS NECESSARY.
In the US the place to send your meter is:
Fluke Technical Service
1150 W. Euclid Avenue, MS 70S
Palatine, IL
60067-7397
Telephone: 1-800-323-5700
For the rest of the world contact your nearest Service Center.
At Fluke Corporation, we are continuing to work toward the highest possible level of product safety, reliability and customer satisfaction. We want you to be thoroughly satisfied with your Fluke product. We apologize for any inconvenience caused by this safety notice, but we urge you to have the modification made as soon as possible.
If you have additional questions, please call our Technical Support Group at 1-800-447-7940 toll free.
Sincerely,
Richard W. Van Saun Senior Vice President Service Tools Division General Mgr
The information to include when you return your DMM is as follows:
Name, Company Name, Street Address, Mail Stop, City, State and Zip Code, Telephone Number, Model Number, Serial Number
Dan Teninty P.E., Senior Design Engineer, Product Safety, FLUKE Corporation[We received another huge collection of messages on the Netscape RC-4 40-bit cracking case. I have selected just a few for RISKS. PGN]This discussion illustrates another common RISK: computerphiles losing touch with low-tech approaches.
It is easy to get credit card numbers through dumpster diving, shoulder surfing, dishonest retail employees, and telephone scams. All of these methods are much easier and simpler than cracking Netscape encryption with currently available technology.
Measured against this standard, Netscape encryption is clearly adequate for credit card numbers until the cracking technology improves a lot. It is an old principle: the lock on the door only needs to be good enough to persuade the burglar to try the window.
Shank has made another logical error: he assumes the machines used to crack the cipher have been paid for by the person using them. Given the lax security at many sites, a workstation farm could be used by anyone persistent enough to break in, or by any insider who knows when they are idle.
40 bits don't buy much security, no matter how you count them. But then, giving your Visa number to random clerks has got to be pretty risky, too. I'd rather have Chaum-bucks, myself.
Nathan Myers ncm@netcom.com[You can celebrate with Chaum-payin' and Chaum-pignon. There is always mush room for improvement. PGN]
The "$10,000" estimate is almost certainly too high, by one to three orders of magnitude. Several estimates I've seen (posted on the cypherpunks list) suggest that RC4-40 can be broken, today, in bulk, using commodity hardware, for between $500 and $1500 per broken key.
If you were to use custom or semi-custom hardware (FPGAs of various sorts), the cost reportedly drops to around $10.00 to $20.00 per broken key.
Here's my estimate for using commodity hardware to attack RC4-40:
A "P100" 100MHz pentium can try on the order of 20000 RC4 keys per second. (I think this may be conservative).
P100 motherboards currently sell for about $600.00, including the processor.
If you add power supply, minimal memory, and a network card, your system cost goes up to around $1000.00 per CPU.
We'll assume the system has a useful life of 3 years.
In those three years, it can try 1.89 trillion keys. 2**40 is roughly 1 trillion.
Therefore, the cost per break clearly under $1000.00
To look at it another way:
If I buy 200 P100's, for a total cost of roughly $200,000, I can break an RC4-40 key every 77 hours.
If I can make $2000 per broken key, I can make my $200,000 back in just under a year.
) The last thing I want to do is ship it over a medium which goes
) through an unknown number of other people's systems on the way.
Which indicates that the "Netscape risk" may not be much or any higher than using your credit card in many other situations. You may have higher risk of the card being abused after it arrives, especially since the recipient can claim that the fraud was the results of evil hackers and not one of their untrustworthy employees.
I applaud the highlighting of this risk to help people make informed choices about it. It sounds like more of this information should be available to those likely to consider using Netscape's method of sending credit card information.
I wonder which immovable object will give way first:
Please report problems with the web pages to the maintainer