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…
Many customers now routinely purchase products over the Internet using their World Wide Web (WWW) browsers. Netscape Commerce Server software accepts orders submitted from a Netscape WWW browser, which are filled out in an on-line web form and transmitted across the net to the server.
Using the Secure Sockets Layer (SSL) protocol, the customer's name, address, phone number, and credit card number are encrypted with the RC4 algorithm developed by Ron Rivest of RSA Data Security. Due to export restrictions placed upon cryptographic software by the U.S. government, the release of the Netscape software most commonly used is limited to encrypting with a key only 40 bits in length.
A recent demonstration strikingly illustrates that this provides insufficient confidentiality for the task at hand — maintaining the privacy of credit card information. After a sample transaction had been executed, and the log of the encrypted server-browser traffic posted to the net, a private individual managed to decrypt the transaction information in just 8 days of CPU time. It would seem that secure commerce on the net, under bureaucratic constraints, is a risky proposition indeed.
-Lewis McCarthy <lmccarth@cs.umass.edu>[Copies of the message from Damien.Doligez@inria.fr sent to cypherpunks@toad.com were forwarded to RISKS by Lewis, and by <elfchief@lupine.org>, Arve Kjoelen <akjoele@shiva.ee.siue.edu>, cdash@ludell.uccs.edu (Charlie Shub). I do not include the Doligez message and a lot of ensuing discussion. Also, I am told that a British team actually beat out Damien by a few hours. PGN]
Late Tuesday evening a person from France posted a news article to the hacker community claiming success at decrypting a single encrypted message that had been posted as a challenge on the Internet sometime on or before July 14, 1994. His response to the challenge is described in an email that has been forwarded widely across the Internet.
What this person did is decrypt one encrypted message that used RC4-40 for encryption. He used 120 workstations and two parallel supercomputers for 8 days to do so. As many have documented, a single RC4-40 encrypted message takes 64 MIPS-years of processing power to break, and this roughly corresponds to the amount of computing power that was used to decrypt the message.
Important points to understand:
Finally, we'd like to reiterate that all this person has done is decrypt one single RC4-40 message. RC4 the algorithm and products which use the algorithm remain as secure as always.
Contact: Anne Enright Shepherd (301) 975-4858
COMMERCE'S NIST ANNOUNCES PROCESS FOR DIALOGUE ON KEY ESCROW ISSUES
Furthering the Administration's commitment to defining a workable key escrow encryption strategy that would satisfy government and be acceptable to business and private users of cryptography, the Commerce Department's National Institute of Standards and Technology announced today renewed dialogue on key escrow issues.
A Sept. 6-7 workshop will convene industry and government officials to discuss key escrow issues, including proposed liberalization of export control procedures for key escrow software products with key lengths up to 64 bits, which would benefit software manufacturers interested in building secure encryption products that can be used both domestically and abroad.
Key escrow encryption is part of the Administration's initiative to promote the use of strong techniques to protect the privacy of data and voice transmissions by companies, government agencies and others without compromising the government's ability to carry out lawful wiretaps.
In a July 1994 letter to former Rep. Maria Cantwell, Vice President Gore said that the government would work on developing exportable key escrow encryption systems that would allow escrow agents outside the government, not rely on classified algorithms, be implementable in hardware or software, and meet the needs of industry as well as law enforcement and national security. Since that time, discussions with industry have provided valuable guidance to the Administration in the development of this policy. For example, many companies are interested in using a corporate key escrow system to ensure reliable back-up access to encrypted information, and the renewed commitment should foster the development of such services.
Consideration of additional implementations of key escrow comes in response to concerns expressed by software industry representatives that the Administration's key escrow policies did not provide for a software implementation of key escrow and in light of the needs of federal agencies for commercial encryption products in hardware and software to protect unclassified information on computer and data networks.
Officials also announced a second workshop at which industry is invited to help develop additional Federal Information Processing Standards for key escrow encryption, specifically to include software implementations. This standards activity would provide federal government agencies with wider choices among approved key escrow encryption products using either hardware or software. Federal Information Processing Standards provide guidance to agencies of the federal government in their procurement and use of computer systems and equipment.
Industry representatives and others interested in joining this standards-development effort are invited to a key escrow standards exploratory workshop on Sept. 15 in Gaithersburg, Md. This workshop is an outgrowth of last year's meetings in which government and industry officials discussed possible technical approaches to software key escrow encryption.
The Escrowed Encryption Standard, a Federal Information Processing Standard for use by federal agencies and available for use by others, specifies use of a Key Escrow chip (once referred to as "Clipper chip") to provide strong encryption protection for sensitive but unclassified voice, fax and modem communications over telephone lines. Currently, this hardware-based standard is the only FIPS-approved key escrow technique. NIST officials anticipate proposing a revision to the Escrowed Encryption Standard to allow it to cover electronic data transmitted over computer networks. Under this revised federal standard, the Capstone chip and other hardware-based key escrow techniques developed for use in protecting such electronic data also will be approved for use by federal agencies.
As a non-regulatory agency of the Commerce Department's Technology Administration, NIST promotes U.S. economic growth by working with industry to develop and apply technology, measurements and standards.
Note to editors: Readers who are interested in obtaining more information about the workshops can contact Arlene Carlton, (301) 975-3240, fax: (301) 948-1784, e-mail: carlton@micf.nist.gov.
Intel and other computer companies are trying to determine the extent of problems caused by a flaw in an RZ-1000 EIDE controller chip that's included in some early PCI motherboards manufactured by PC Tech. The flaw was discovered in 1994 and was corrected through a software "patch," but the latest version of OS/2 disables that patch. (Investor's Business Daily 16 Aug 95 A15)
[I thought perhaps the SUBJECT line was a typo, and that we would now have to worry about UNmarried motherboards. PGN]
The following is my rough translation of the article "Die Ampel denkt nicht" I just read in the German weekly newspaper "Zeit" from August, 11 1995, p.12.
The "intelligent street" - a foolish flop
The traffic light does not think
Stuttgart. - There is no doubt about it, there are intelligent traffic lights. They do recognize, when to switch from red to green. Also, an electronic display exhibits intelligence, if it alerts us about a traffic jam 15 kilometers (km) ahead. Indeed, our traffic signs become more and more intelligent. We report on an experiment to replace the common sense of a driver by traffic signs - a failed experiment, though.
At April 29th 1995 the federal minister for traffic and transportation, Matthias Wissmann, and the state minister for traffic and transformation of Baden Wuertemberg, Hermann Schaufler, pressed a little green button: The "traffic control (literally influence) machinery" at the federal street 27 in the south of Stuttgart started to work. A pilot experiment at a length of 18 km was supposed to end the brass-age: Instead of stupid speed-limit 80 km/h signs in the future there will be "variable speed limits" thanks to "automatic video sequence processing", "radar technology" and "computer based computational methods". The small group was sure: this was the advent of the "intelligent road".
The drivers at this heavily frequented segment got a different impression the other morning. The DM 14.000.000 equipment suggested a speed limit of 120 km/h - during a traffic jam. And during the way home at the evening the super device surprised onece again: It did rain cats and dogs, which triggered the highly sensitive sensors to announce "wet street".
The obvious flop made the ministry of traffic and transportation to stick red crosses over the displays. At July 19th started the second trial. Since then it is allowed to race. Where in former times a speed limit of 80 km/h was in effect for noise and emission reduction, the computer did allow 120 km/h, in non urban areas there was no speed limit at all. Some days ago a vespa-driver fell down, causing a jam, but the "light fiber optical traffic sign" did suggest 120 km/h. Fortunately, the drivers thought it over and did brake. Police and city authorities stopped the madness. Due to their protests, the installation displays constantly 100 km/h in the city area.
There is a saying around Stuttgart: "With 40 the Swabian becomes sensible, others not in eternity". Why should a traffic installation make a difference.
Phillip Mausshardt
This "translation" is not to be considered as a contribution to the intellectual heritage of this century (due to my limited ability to use the English).
There are, however some reports on successfully installing such devices, namely by Kuehne et. al., e.g. in:
Kuehne, R.D. and Roediger, M.B. Macroscopic simulation model for freeway traffic with jams and stop-start waves. In: Proceedings of the 1991 Winter Simulation Conference, pp 762-770
For the interested (and German reading), I can provide more references. I do not know, however, which research team was involved with the traffic control system described above.
Torsten Ihle, Dipl. Inf., TU-Dresden ihle@iki101.inf.tu-dresden.deDan Frankowski's account (RISKS-17.26) of problems with an old frequent flyer account points up a new generic risk: Our electronic "shadows" accrete all kinds of data over a lifetime. Apart from the problem of bad guys getting access, it is rather difficult for us to retrieve our own data. In addition to stale f.f. accounts, we may need to get tax records, Social Security income data, house purchase and repair cost information, investment cost, etc., sometimes back to day zero.
Dave Gelernter at Yale has developed a "lifestream" database model which would capture and organize (by date, as I understand it) all your electronic data, starting with your birth certificate. In addition to all your financial transaction data, there would be all your e-mail, significant images, school homework, all the versions of all the programs you ever wrote, etc. We can imagine carrying this all around on an optical disk in your wallet or on a super smart card. (How much of it should be accessible to other parties like the IRS or to legal subpoena is an interesting question. Encryption might be a good idea, if you can remember a key throughout your whole life!)
I don't know if a comprehensive personal "lifestream" is going to be available any time soon, but the technology is almost there. As a concept, it may help to sharpen our ideas about electronic risks. It certainly would help to find that old account number.
Martin Ewing, Yale Science & Engineering Computing FacilityDell specializes in selling inexpensive computers. Customers who want the cheapest hardware are going to have to face some extra risks, such as the chance of failing to be notified about a buggy BIOS.
Few software companies provide toll-free support, but I don't think this is necessarily bad. I would often prefer paying $50 for a program with minimal support over spending $100 for the same program with better support. Books, third parties, toll- call support, etc. can provide support if I don't mind paying slightly more.
There are risks everywhere, and we have to decide how much effort and money to invest in avoiding them. In the case of the PC clone industry, there are many suppliers and the market is extremely competitive, so consumers can decide whether the risks associated with choosing a low-cost supplier are worth taking.
Don't get me wrong; I'm not recommending that market forces set safety standards, but I also don't think it's necessarily bad that companies cut some corners in order to provide more competitive prices.
Paul Kocher pck@netcom.com (formerly kocherp@leland.stanford.edu)[Below is an article, forwarded with the authors permission. The risks are obvious. I wonder how the risks can be reduced. Andy Chesterton]
As most of us are aware, the commercial online services, such as AOL, Compuserve and Prodigy, represent certain risk to the unsophisticated user. Unfortunately, the Microsoft Network (MSN) raises the vulnerability of such users to unprecedented heights.
Key to this vulnerability is the richness and complexity of the MSN/Windows 95 environment. What is most dangerous is the ability for the author of an e-mail or (certain) BBS documents to embed "objects" in that document. These objects can be readily disquised to appear totally benign to the casual user and be nothing more than MSN navigational aids. Once double-clicked by the recipient, these objects can readily infect the recipient's PC with a virus. Worse, what this object could do is only limited by one's imagination. It is worthwhile noting that MSN appears to be migrating to an open architecture, with the MSN user connecting through the Internet. If this is true, there is nothing which prevents an object, once activated, from transmitting information stored on the user's PC to any other location on the Internet.
In theory, embedded objects can be interrogated to ensure their validity. Unfortunately, this interrogation process is not likely to be carried out by the average user. Even if it is, the user is not likely to understand what they are looking at. It is like warning automobile drivers to look under the hood of their car before starting it to make sure there is not a bomb inside. Most drivers would assume that the odds were with them. Those that did check would have no idea what they were looking at. (At least that's my feeling when I look under the hood of my car :-).
Microsoft's position appears to be that the MSN user is no more vulnerable than one who uses a competing system. I would maintain that this position is just not true. With system complexity comes excessive vulnerability. MSN rates a 9 in complexity. The other services a 4.
The bottom line: Users of MSN are placing themselves at significant risk. If one must use MSN, avoid at all cost activating (double-clicking) objects in e-mail messages and BBS posts. Sophisticated users may think they know what they are doing, but it probably won't be long before they are outwitted by someone who figures out how to totally disguise an object's true purpose.
-Mike Wyman wyman@tiac.netIt strikes me reading these articles on RISKS that someone has confused two Microsoft products. Microsoft SMS (Systems Management Server) collects information about the machines on a corporate network to aid administration. In particular, it collects autoexec.bat and config.sys files, and identifies "packages" installed on the machines (these packages and how they're recognised is configured by the administrators).
I'd guess that someone's been reading too many press releases and blurred the Windows 95 Registration Wizard with the SMS inventory. One of the risks of having so much advertising material flying around...
Elliott> radius of about 357 square miles,
Since when are radii measured in SQUARE miles?
[THANKS. I was thinking of making something out of ROUND miles instead of SQUARE miles, and forgot to go around the square. PGN][Also noted by "Michael J. Chinni, (AMSTA-AR-IMN)" <mchinni@PICA.ARMY.MIL>, and John Pearson <john@huiac.apana.org.au>. There may have been others as well. Perhaps it was an inadvertent test to see who is reading carefully... PGN]
From: Raymond.Turney@ncal.kaiperm.org
> The reason for the interest in the effects of the Internet and VR
> technology is simply that they are unknown. People are reporting problems
> with "Internet addiction", and as an old gamer I can see where there might
> be a problem with people preferring VR flight simulators to their real
> lives.
One thing that has been happening throughout history is that the sorts of activities considered to comprise people's "real lives" have changed, over and over again. How would a hunter-gatherer or a primary farmer or a medieval villein or a monk view our "real lives" today?
Except for a minority we're pretty much out of touch with nature, with the divine, even with our livelihood. We don't hunt, harvest, butcher, or otherwise gather or process our own food. Hardly any of us engage in daily prayer. I assume that most readers of this forum don't believe in the literal truth of our scriptures the way people did only a few hundred years ago.
By the standards of most of history, we're hopeless technology addicts today.
We shouldn't be so quick to judge people who prefer VR to their "real lives".
How real is *your* life? I know when we've got a project in house my life six days a week consists of work 9AM to 9PM, living in a reality of cables and backups and little antique-white squares on a pleasant lilac background.
Peter da Silva Network Management Technology Incorporated> To see why, consider the history of nineteenth-century railroading.
And it was also apparent how to avoid a large part of the problem. Use broader gauge tracks — move the rails farther apart — in relation to width the cars. In Britain, the Great Western Railway was built with tracks of 7' or 7'0.25" (2134-2140 mm) gauge, where others chose the 4'8.5" (1435 mm) that soon afterward became the standard. But the GWR's passenger cars were almost the same width as their competitors'. When involved in a derailment or collision, they almost always *stayed upright* — so unless the car was actually smashed, people would not likely be trapped inside it.
Of course, there is no computer relevance whatever to this story of a system that was technically superior in safety and other respects, but which lost out to one that was more common and cheaper.
Mark Brader msb@sq.com SoftQuad Inc., Toronto This article is in the public domain.Periodically I will remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry general discussions in which risks to privacy are a concern.
information privacy
as the first text in the BODY of a message to "privacy-request@vortex.com"; you will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com".
Information and materials relating to the PRIVACY Forum may also be obtained via ftp to "ftp.vortex.com", gopher at "gopher.vortex.com", and World Wide Web via: "http://www.vortex.com".
Please report problems with the web pages to the maintainer