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…
[This is pretty much what I said earlier this morning in an interview
with James Glave of Wired News (something is expected to appear at
http://www.wired.com), although I have extended it somewhat for RISKS. PGN]
The operative phrase seems to be ``smoke and mirrors'' in the case of the
Pentagon HackAttack. Yesterday we were told by John Hamre (Deputy Secretary
of Defense) that this attack was ``the most organized and systematic the
Pentagon has seen to date''. Today we are told that it was just a bright
high-school kid (or maybe a few) who was able to penetrate so many systems.
Given the incredible collection of breaches of so-called secure systems over
the past few years, one can conclude only that the computer-communication
infrastructure stinks, and that the U.S. Government is foolish to believe or
pretend that it is secure in the first place. And if unclassified are so
weak, what should we expect of the classified systems?
On the *other* hand, perhaps this is a con game. You put out a system with
miserable protection and hope that someone breaks it. Then you can ask for
millions of dollars more to perform further palliative protections, rather
than getting to the core of the problem — significantly ratcheting up the
security of the infrastructure. Or perhaps it is just another bogus
argument for mandatory key escrow or whatever else it might euphemistically
be called (currently, ``key recovery'' a.k.a. ``sound key management'').
The real irony of is that we are continually told that there are no undue
risks in key-recovery crypto systems. But, if our infrastructure is *this*
bad, how can anyone hope to protect what is perhaps most critical, namely,
the crypto keys!
[On the *OTHER* other hand, if the Y2K problem is causing the Government
so much grief, how can anyone expect them to do security properly? Date
arithmetic is not difficult if you know what you are doing. Security is
much harder. Although, I note that in date arithmetic you are often
dependent on other systems, not just your own. The same is true of
security.]
[Check out my own URL for a bunch of related items on this subject,
including House and Senate testimonies on the allegedly secure
infrastructure (http://www.csl.sri.com/neumann/).]
[By the way, there's *is* good stuff in the research community, such
as the Rivest-Lampson Simple Distributed Security Infrastructure
(SDSI) (http://theory.lcs.mit.edu/~rivest/sdsi) as just one example.
It is high time some decent authentication with strong encryption
found its way more vitally into commercial systems. Which gets us
back to crypto policy as well as legislative attempts to link
certificate keys and key recovery! But technology is not enough.
Sanity and common sense are also necessary.]
http://www.us.net/softwar/mcc.html
This is a snip from an interview of Adm. Mike McConnell - former Director of
the NSA under Presidents Bush and Clinton:
SOFTWAR: What is your view of the Clinton administration's current export
restrictions on encryption?
McConnell: It was our view in the 80s that strong crypto will happen. The
export restrictions were only meant to slow down foreign development. It was
a matter of national security. Today, it is not a matter of national
security. The FBI Director has made it a law enforcement issue involving
domestic controls. The Department of Justice and the FBI are still seeking
to "mandate" key escrow.
SOFTWAR: The Clinton Administration is pushing KEY RECOVERY encryption as
a tool to catch criminals and terrorists. Could this type of software be
abused by foreign powers or dictators to persecute dissidents and political
opponents?
McConnell: Can Key Recovery be used against dissidents and political
opponents? In a word, YES.
[See SOFTWAR http://www.us.net/softwar ; the interview is at
http://www.us.net/softwar/mcc.html and it it is fascinating. PGN]
[BTW, how many third parties will YOU trust? PGN]
[redundant incorrect URL fixed in Archive copy.]
[inadvertent stray text removed in ARCHIVE COPY. PGN]
Excerpted from the American Megatrends ("the world's premier BIOS provider")
web site: http://www.amibios.com/support/2000.html
> Year 2000 compliance means that the internal BIOS date and time clock will
> continue above the date 1999. It will not reset it self after 1999 to the
> date of 1980. It will continue to the date of 2099 before resetting to 1980.
Tsutomu Shimomura tsutomu@ucsd.edu +1 619 534 5050
University of California at San Diego/San Diego Supercomputer Center, USA
COMPAQ is replacing the on-screen instruction "Press any key" with "Press the return key", in an attempt to reduce the flood of telephone calls to their help desk asking where the "Any" key is. [Source: UK press, quoted on "The News Quiz", BBC Radio 4, 21st Feb. 1998] Pete Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB
[Note: The last previous Friday the 24th was in October 1997, and the next one, ominously, is in April 1998.] From THE WEEKLY UNIX NEWSPAPER, London, 16-20 Feb 1998, Issue Number 667 On Friday the 24th, I was watching the NASA Channel on cable TV to see how the experiments and Shuttle crew were doing. The men on board needed to send some adjusting instructions to the automated setups doing experiments in the cargo bay, and they were using a laptop to do the sending. As some of you may have heard, there was a "computer problem" on board as reported by CNN. The dialog between the crew and the Johnson Space Center (JSC) went something like this: Crew: Urgent, Johnson, we can't get a DOS prompt! JSC: Press "C:<enter>". Crew: Heck, we're not familiar with all this. JSC: What screen are you looking at? Crew: It says "My Computer", and, er, various other icons. JSC: Click on "Start", and then "Shutdown". Crew: You click the "Start" button to shut down? JSC: Yeah. Isn't it obvious? Crew: Somebody get me an aspirin. JSC: Just hit the damn "Start" button. Crew: We can't do that. It didn't load a mouse. JSC: Didn't load any mouse at all? Crew: Well, yeah, a PS/2 or something. But we don't have one of those. JSC: Okay. Press Alt + Esc. Crew: And what does that do? JSC: It should help. Crew: Negative. JSC: Stand by, will attempt to replicate the problem down here. Crew: Roger. <Long Pause> JSC: Okay then. Double-click on the MS-DOS icon. Crew: I don't have a mouse. JSC: Go to the backup plan. Crew: Which is what? JSC: Dock with the Russians. They have a Unix workstation you can borrow.
My favorite newspaper, the *Weekly World News*, in last week's (27 Jan 1998?) issue, reported that a woman who has been having an intimate relationship via the Internet with a man she has never physically met is with child. She is considering a paternity suit. Tony Scandora, Argonne National Lab, 630-252-7541 <scandora@cmt.anl.gov> [Remember, please, this is a newspaper that apparently uses a computer to generate the plot lines for its stories. PGN]
From at least 1 Feb 1998 until it was fixed on 10 Feb, at 5:20am each morning TCI gave San Francisco's Channel 27 viewers 40 minutes of free porn from the Adam-and-Eve network on its pay-per-view preview channel. (However, there were interruptions for commercials advertising similar stuff.) The glitch was attributed to the computer system turning off the masking supposedly provided by the scrambler, ahead of schedule. [Premature emasculation?] [PGN Stark Abstracting from Nando.net Scripps-McClatchy Western item, by Anastasia Hendrix in the San Francisco Examiner, 12 Feb 1998, http://www.techserver.com/newsroom/ntn/info/021298/info23_29316_noframes.html Thanks to Aydin Edguer <edguer@MorningStar.Com> for noting this one.] [No telling what we'll see when Y2K hits their computer — perhaps total unscrambling!]
[Sent to RISKS courtesy of Dave Farber's IP list.]
Original-Subject: [RC5] [ADMIN] The secret message is...
[http://www.distributed.net/des/nugget.txt]
Once again I have the great privilege of coming to you with good news.
It is with great pleasure (and a sigh of relief) that I can now inform you
that the DES-II-1 challenge has been successfully met by distributed.net.
The winning key to the challenge was detected and submitted to RSA Labs
at 02:26 GMT on Monday, 23-Feb-1998.
The correct key, 76 9E 8C D9 F2 2F 5D EA, revealed the words which we've
been anticipating these past 39 days:
"The secret message is: Many hands make light work."
(If you ask me, this is a nice nod in our direction. Thanks, RSA Labs!)
In addition to proving that 56-bit DES is no longer sufficient for
protecting valuable information, we've now also proved that blind luck need
not be a factor in brute-force decryption attacks. The original DES
Challenge and the more recent RC5-56 wins were fortunate and did not have to
sweep a significant portion of the keyspace. This time around, however, we
managed to complete almost 90% of the keyspace and have now proven that even
when the law of averages chooses to catch up to us and forces us to pay our
dues, we are still an unstoppable force. Our collective victory is all the
more impressive when you consider what we had to accomplish to achieve it.
We tested sixty-three quadrillion keys. That number is simply staggering.
Assuming *0* growth between now and July, we'll be able to sweep the entire
DES-II-2 keyspace in just under 29 days. That's assuming that we do not
recruit another person, don't add any more machines, and are even more
unlucky next time. I daresay at least one of those assumptions is probably
false.
I'd invite all of you to join us in IRC (efnet, #distributed) for a rowdy
victory party. Take a breather. Sit back and watch your clients
automatically roll over to RC5-64.
The only other issue at hand is *who* found the key. The person who found
the winning key has politely asked to remain anonymous. Rest assured, I've
been in contact with them and they know they've won. They will be receiving
their full share of the prize and are quite excited about the victory. All
I'd ask is that we all respect this person's wishes and not bother the list
with public speculation as to their identity. I'm sure we all appreciate
just how important privacy and anonymity can be.
Here are some numbers to chew on while the stats are down:
Project statistics:
Start of contest: January 13, 1998 at 09:00 PST
Start of distributed.net effort: January 13, 1998 at 09:08 PST
End of Contest: February 23, 1998 at 02:26 PST
Size of keyspace: 72,057,594,037,927,936
Approximate keys tested: 63,686,000,000,000,000
Number of 2^30 (average) keyblocks: 67,108,864
Number of keys in average keyblock: 1,073,741,824
Peak blocks per day: 5,540,982
Peak keys per second: 34,430,460,000
The unencrypted message: Many hands make light work
Computing equivalents:
Distributed.net is equivalent in processing power to:
11,264 DEC Alpha 21064 533s
15,316 Sun Ultra I 167s
22,393 Intel Pentium II 333s
68,859 Macintosh PowerPC 604e/200s.
41,712 Intel Pentium 166s
399,374 Intel 486DX2/66s
7,446,033 Intel 386SX/20s
(based solely on DES client performance)
Prospective:
If Keys were dollars, we could pay off the U.S. National Debt in 6.25 minutes
If Keys were pennies, we could buy 536249385 Mazda Miatas each day.
If Keys were pennies, we could buy 256728249 Jeep Cherokees each day!
If you printed a single page to represent each key block as it was checked
and placed those pages in a stack, it would grow 12.83 inches taller every
minute.
If blocks were liters of Dr. Pepper, we could produce 6381493 six-packs
each day.
If Key Blocks were cheeseburgers, fries, and a large Dr. Pepper, we could
feed the entire city of Toronto, Ontario lunch each day.
(On a personal note, It sure feels nice to be doing RC5 blocks again. I
feel like I've just slipped on an old, comfortable pair of loafers that were
lost in the attic for two months.)
In RISKS-19.59 Ross Anderson is quoted by Minow et al. as saying: > <http://www.cl.cam.ac.uk/~mgk25/ih98-tempest.pdf> > In its simplest form, our technique uses specially designed `Tempest > fonts' to make the text on your screen invisible to the spooks. Specially designed fonts as such aren't required; with the advent of routines to generate smoothed anti-aliased fonts on personal computers, the detection of text on a CRT as discussed by Anderson et al is made slightly more difficult as the edges are already smoothed, removing high-frequency signal components. Modifying the system bitmap text anti-aliasing routines, rather than the display drivers as the paper suggests, to 'lowpass-buffer-alias' (for lack of a better term) all output fonts as directed is rather easier than redesign of individual fonts. It offers more transparent results, and the resulting security solution is more easily distributed to and accepted by users than a host of new fonts or a replacement display driver would be. On the Macintosh, you'd generate lowpass-buffer-aliased SoftTempest fonts by modifying the source to Landweber's "Greg's Hack", now his shareware SmoothType (source and pointers to antialiasing algorithms available from http://www.kaleidoscope.net/greg/smoothtype.html [CORRECTED IN ARCHIVE.] On Windows, Microsoft's own antialiasing routines - a later product, also called Smoothtype - are included in their Plus! Pack and with Explorer 4.0. [previously noted by bos, RISKS 19.42] I'd worry about a Tempest virus that polled a personal computer's CD-ROM drive to pulse the motor as a signalling method: * Modern high-speed CD-ROM drive motors are both acoustically and electrically noisy, giving you two attack methods for the price of one; * Laptop computer users without CRTs, and the PC users that can afford large LCD screens instead of CRTs, often have CD-ROM drives; * Users are getting quite used to sitting patiently while their CD-ROM drives grind away for no visibly obvious reason (but that's quite enough about the widespread installs of software from Microsoft CD-ROMs that prompted Kuhn's investigation in the first place.) <L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641
[This was sent me by someone at a Fortune-100 manufacturer, and is anonymized and sanitized at the original sender's request. It is genuine.] > The recent power fluctuations here in [placename] corrupted the NT > registries in our [server-community-names]. As a result, our entire NT > network (>10K machines) is down, and has been since 5 am this > morning. (I'm doing direct IP to [product-name] to do mail. Thank God.) > Once the registries got corrupted, the databases of user signons went, > too. And, of course, the tape backups won't load because NT requires a > timestamp somewhere in the guts that the tape image doesn't match to the > clock. So every NT server, and most NT workstations, won't do anything > except local work. > If this were just office workers, it would be annoying enough. But the > [product name] servers require such close tie-ins to the machine accounts > that they are dead — guess what helps run our factories? Can you say loss > of $1M+ per hour?" > Why am I telling you? Because our NT guys have suddenly realized that this > is a good candidate for a denial of service attack: once the registries > get corrupted, the entire resource domain has to be reloaded by hand -- > and that apparently includes desktops. If you have ideas on how to go > check the registries on your NT servers, I'd suggest you go do so. In another letter, the original sender elaborates: > If you are recovering from this, every desktop user will have to > delete/disable their <user>.pwl file to be able to get back on the > network, because that file hardcodes which domain server they are > on. HOWEVER, if they do that, they can then not get into any other service > on their desktop for which they've stored the password, because they're > all in that file. if the user doesn't remember the password, they're SOL, > because the latest patch from MS keeps the *.pwl files from being hackable > by the "standard" hacker and pwledit tools — but it is also rendered > unreadable to the MS standard pwl editor, too. The total outage was in excess of 12 hours, and the loss-of-revenue from the outage is estimated to be more than $10 million. Mike Andrews, D.P. Director, Okla. Dept. of Transportation mandrews@fd9ns01.okladot.state.ok.us
Baltimore Washington International Airport recently installed a system "for my protection" "with my tax dollars" which delayed me considerably in getting home one night. About a month ago, I noticed small video cameras appearing at the exit lanes of the parking lot. I assumed that they were to record license plates in the event of someone trying to skip paying, or using a stolen credit card. Since my car is kind of short, they've already had to ask me several times to back up so that the camera could get my plate. I usually pay with a credit card so I didn't think this was an especially big deal. Now, I'm not so sure at all. The other night I got back from a late trip, and when I came to pay the lady apologized and explained that there were some delays "because the system is running slow." I said that was no problem because I was paying cash, handed her exact change, and waited for the bar to go up. She was still fiddling with a computer and I began to get irritated and asked her to let me leave. "I can't do that, the state police computer has to clear your tag, first!" I sat there for quite a while, and while I was waiting (maybe a total of 10 minutes) I got more details from her. It seems that "to protect us" Maryland's State Police established the system. Either she was no rocket scientist, or someone had lied to her about the purpose of the system, because she was convinced it was to prevent theft of vehicles. I tried some logic: "if someone was stealing my car from the lot, I would still be away on my business trip, so I wouldn't have reported it stolen, yet." I suppose that a stupid criminal who was going to rob cars would car-pool into the lot with a buddy, but I have to wonder who/what they are really trying to track. My paranoia was heightened by the state police cruiser that was idling in the vacant lot just across the access road. As a computer security guy, I worry about these things more than most people. But, I suppose that the presence of this system means there is a record someplace of who and when people went to a major airport. Since it's presumably not "sensitive" information, the security on that record is probably lousy. (I've seen how government agencies usually handle any computer records that are not CLEARLY sensitive) :( I guess the technology will appear elsewhere - perhaps at stop lights in major intersections "to protect us" by detecting cars that have somehow been identified as "worth catching." When you go to the airport they ask you "has any unknown person asked you to carry anything in your bags?" I guess the savvy frequent flier will make sure they never travel to BWI with an unknown person or in an unknown car -- I am just Real Happy that the police computer didn't have my tag number in its database as a dangerous, armed felon. I see all kinds of potential for disaster in the event of a license tag confusion. I got off lucky because all Big Brother did that evening was waste 15 minutes of my time and give me a good cardiovascular workout by raising my blood pressure a notch. It's nice to see my "tax dollars at work." :-P Marcus J. Ranum, CEO, Network Flight Recorder, Inc. http://www.nfr.net home - http://www.clark.net/pub/mjr
BKINBSGD.RVW 971120 "Internet Besieged: Countering Cyberspace Scofflaws", Dorothy E. Denning/Peter J. Denning, 1998, 0-201-30820-7 %A Dorothy E. Denning denning@cs.georgetown.edu %A Peter J. Denning %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1998 %G 0-201-30820-7 %I Addison-Wesley Publishing Co. %O 416-447-5101 fax: 416-443-0948 800-822-6339 617-944-3700 %O Fax: (617) 944-7273 bkexpress@aw.com %P 547 p. %T "Internet Besieged: Countering Cyberspace Scofflaws" As with the earlier "Computers Under Attack" (cf. BKDENING.RVW), this book is a collection of papers related to the titular topic. This text is not just an updating of the earlier work, although some of the same papers appear, having been revised and updated. It is also more narrowly focussed, with sections discussing the worldwide network, Internet security, cryptography, secure electronic commerce, and finally dealing with law, policy, and education. The anthology style is well suited to a constantly changing and still emergent field. Under the scope of the worldwide network, there is an initial review of the history of the net by Peter Denning. Dorothy Denning follows up with an overview of system security breaking methods over networks. (While it is a fine and readable piece of work, the essay is not quite as riveting as the interview with a system cracker in "Computer Under Attack.") As usual, the most interesting papers deal with real case studies, such as the attack on Rome Labs. Peter Neumann's brief piece on the RISKS-FORUM archives indicates the value that the net can be in protecting itself, since RISKS acts as a kind of repository memory of attacks and weaknesses. The even briefer article on securing the information infrastructure is a kind of call to arms to pay attention to security in important control systems. Part one is finished off with Eugene Spafford's computer virus paper; by now the classic short work in the field. Part two, specifically looking at Internet security, starts with another case study; that of the Berferd attack on Bell Labs. This is followed by an overview of network security threats and protective tools. Two articles look at specific types of assaults: "sniffing", which works because of the broadcast nature of many means of media access, and "spoofing", which works because of the automatic configuration and repair protocols intended to provide reliability. An overview of password use looks primarily at technologies to make password cracking more difficult. Four security tools are introduced, a GPS (Global Positioning System) based authentication scheme, Tripwire, DIDS (Distributed Intrusion Detection System), and SATAN (Security Administrator Tool for Analyzing Networks). Java security also gets a thorough examination. The section on cryptography starts with the development of the Data Encryption Standard. (It is indicative of the rate of change in this field that the following article, looking at the breaking of two recent cryptographic systems, doesn't cover the cracking of DES. The book was published just before that happened.) There is a detailed essay on the Internet Privacy Enhanced Mail (PEM) protocol, and a more conceptual paper on authentication for distributed networks. There is also a taxonomy, or method of classifying, for key recovery encryption systems. Security of electronic commerce covers electronic commerce itself, atomicity in electronic commerce (which determines the general usefulness of a system), another overview of Internet security vulnerabilities, digital forms of money and cash, ad identify misuse and fraud. The final part looks at social issues. The law enforcement in cyberspace address, coming as it does from a US federal agency, is unsurprising in its call for key escrow. Dorothy Denning follows up with a more reasoned review of the market forces. Bruce Sterling gets two cracks at computers and privacy. Eugene Spafford gets the hardest job--looking at computer ethics--and does a decent and practical job. There are two examples of use policies from universities, and a final, very interesting, article on the inclusion of data security topics and activities in the teaching of computer science concepts (rather than the other way around). Even within this limited frame of reference, the book cannot be exhaustive. When you start to consider the gaps that are missing, like the international nature of many activities that make them essentially immune to legal remedies, you also find that whole fronts of the Internet siege are unmentioned, or only tangentially referred to. Spam, fraudulent scams, and chain letters claim many more victims than do system crackers. Still, this work is both interesting and valuable. It should be of particular use to the student or teacher of data security, although there is much to hold the attention of any interested individual. copyright Robert M. Slade, 1997 BKINBSGD.RVW 971120
Please report problems with the web pages to the maintainer