December 2003 - cypherpunks-legacy

Re: Impossible Analysis Paper at Crypto98
by Anonymous 17 Dec '03

17 Dec '03

> There's talk of a paper given at Crypto98 on "Impossible > Differential Analysis" which got the NSA people scribbling > like mad taking notes as though this was something that > had never come up at the agency and they'd better get > right on it. > > Roughly, as I heard it (and I may be way off), the premise is > that instead of using differential analysis for finding weaknesses > in a cipher, to flip that to determine what could not possibly be > a weakness in a cipher and build one with just those attributes. > > Is this report correct, and is there a source for that paper? This was presented at the rump session and apparently there is no paper writeup yet. Biham's home page at http://www.cs.technion.ac.il/~biham/ has a place you can register to be notified when new material comes out. With conventional differential cryptanalysis, you look for pairs of inputs which have differences (xors usually) such that after a certain number of rounds, the ciphertexts have certain differences with excess probability. With "impossible" differential cryptanalysis, you look for inputs with differences which lead to ciphertext differences that are "impossible", or at least have reduced probability. It's the same basic idea but you look for diminution rather than enhancement of the probability of later differences. Because of the reversal of the effect, the techniques for identifying differentials, exploiting them, and designing against them are rather different. As a result ciphers which were designed to resist differential cryptanalysis may be vulnerable to impossible differentials. This technique has apparently led to an improved attack on SkipJack, announced on Biham's web page above as "coming soon". There was also a moderate improvement in attacks on reduced-round IDEA (not effective against the full number of rounds though). At Crypto everyone was scurrying off to see if any of the AES candidates could be knocked out by the new technique.

1 0

Bulk emailing service
by bman offer 17 Dec '03

17 Dec '03

<HTML><PRE><BODY BGCOLOR="#000000"><FONT COLOR="#00FFFF" SIZE=3> Bulkman Direct Email Promotion Bulkman --> Call (336) 214-0344 for ordering information,custom orders, and Website information. Bulkman Services offers professional, effective direct email advertising to promote your business or website. With our service you will reach thousands of people who are interested in what you have to offer. We can send up to 500,000 emails out for you with your own sales letter. The email addresses that we use are freshly extracted daily from people actually online either chatting or surfing! Plus, the people who receive your email aren't overloaded with other offers. We also offer targeted emailing using a target audience that you specify, for example - music lovers, single mothers, college students, etc. We use up to date, high quality programs to effectively extract fresh addresses and successfully mail your message. This is why our service is more effective than others. Bulkman will give the sales boost you've been looking for. Try out our services and you will be overloaded with response and sales!!! We accept any questions and phone orders - Call --> (336) 214-0344 - Anytime - --> please leave a voicemail message and you will be contacted shortly </FONT><FONT COLOR="#000000" SIZE=3>

1 0

Writing skills
by s9812127＠postino.up.ac.za 17 Dec '03

17 Dec '03

YoU wR1t3 l1K3 tH1s aGa1N & 1'll f1@m3 you, dickhead... > From: Jrjeffro(a)aol.com > Date: Wed, 9 Sep 1998 19:27:05 -0700 (PDT) > Bcc: > HaCkaZ OnlY Da EliTeHelLO YaLL DiS is Da MaDD AAOOLL HaCka Ima startin a GreWp fOR HaCs Only So In OthA WerDS yA gOttA KnOw The WAreZ anD HoW toO UsEr FaTe AnD AOL So MaIl Or Im Me FoR Da TeTaIls f > YeR LeeTo K Pe@CE FrOmE The LeeTs HacKJeFFrO) > > > -/"Those who desire to give up freedom in -/exchange for security will not have, -/nor do they deserve, either one." - Thomas Jefferson -/ Crayven. -/"Those who desire to give up freedom in -/exchange for security will not have, -/nor do they deserve, either one." - Thomas Jefferson -/ Crayven.

1 0

No Subject
by s9813117＠postino.up.ac.za 17 Dec '03

17 Dec '03

1 0

Impossible Analysis Paper at Crypto98
by John Young 17 Dec '03

17 Dec '03

There's talk of a paper given at Crypto98 on "Impossible Differential Analysis" which got the NSA people scribbling like mad taking notes as though this was something that had never come up at the agency and they'd better get right on it. Roughly, as I heard it (and I may be way off), the premise is that instead of using differential analysis for finding weaknesses in a cipher, to flip that to determine what could not possibly be a weakness in a cipher and build one with just those attributes. Is this report correct, and is there a source for that paper?

2 1

SNET: [FP] Alaska: Nearly 93% of new parents choose Enumeration At Birth (EAB)
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

From: "ScanThisNews" <mcdonalds(a)airnet.net> (by way of jeremy.compton(a)stonebow.otago.ac.nz (Jeremy Compton)) Subject: SNET: [FP] Alaska: Nearly 93% of new parents choose Enumeration At Birth (EAB) Date: Fri, 11 Sep 1998 01:37:30 +1200 To: snetnews(a)world.std.com -> SNETNEWS Mailing List ====================================================================== SCAN THIS NEWS 9/10/98 This article actually ran in '96, but it is worth reviewing. ====================================================================== Press release from Alaska's Department of Health and Social Services found at: http://health.hss.state.ak.us/htmlstuf/com/pr/media.htm Electronic Birth Certificates and Social Security Cards at Birth Make Life Easier For Parents Februrary 6, 1966 (sic) The Alaska Department of Health and Social Services Bureau of Vital Statistics reports that the Electronic Birth Certificates (EBC) have been installed in all but three of Alaska's hospitals. In a little over a two year time period, the Bureau has gone from no electronic birth certificates to nearly 99% of all Alaska hospital births coming to the Bureau in electronic format. "Innumerable man-hours have been saved at both ends of the registration process," said Al Zangri, Chief of the Bureau. In addition, in cooperation with state-wide hospitals, the Bureau has implemented the Social Security Administration's Enumeration At Birth (EAB) program statewide during 1995. The Enumeration at Birth program allows parents to request a social security number for their newborn through the birth registration process. This program has proven to be so popular with new parents that nearly 93% of all births transmitted to the Bureau request a social security number. ======================================================================= -----Original Message----- From: Katherine A. Sent: Thursday, Sep. 10, 1998 ======================================================================= Reply to: <fingerprint(a)networkusa.org> ======================================================================= To subscribe to the free Scan This News newsletter, send a message to <majordomo(a)efga.org> and type "subscribe scan" in the BODY. Or, to be removed type "unsubscribe scan" in the message BODY. For additional instructions see www.efga.org/about/maillist.html ----------------------------------------------------------------------- "Scan This News" is Sponsored by S.C.A.N. Host of the "FIGHT THE FINGERPRINT!" web page: www.networkusa.org/fingerprint.shtml ======================================================================= -> Send "subscribe snetnews " to majordomo(a)world.std.com -> Posted by: "ScanThisNews" <mcdonalds(a)airnet.net> (by way of jeremy.compton(a)stonebow.otago.ac.nz (Jeremy Compton))

2 1

IP: The big blackout?
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

From: "Douglas E. Renz" <dougr(a)zlink.net> Subject: IP: The big blackout? Date: Thu, 10 Sep 1998 15:50:53 -0400 To: "'Chris Ball'" <1stlight(a)mail.tds.net>, "'En_Agape'" <en_agape(a)prodigy.net>, "'Kim/Jr'" <jrandkim(a)juno.com>, "'Kristen'" <kristen_renz(a)juno.com>, "'Steve Cortese'" <Sccortese(a)juno.com>, "'Tom Young'" <tayoung(a)cottagesoft.com> September 7, 1998 The big blackout? Regardless of your own Y2K preparedness, the slow-moving electrical industry could leave you in the dark By Blaise Zerega Companies scrambling to bring their computer systems into year-2000 compliance may discover that their time and effort will be for naught. A lack of preparedness by North America's electrical industry may pull the plug on many companies' transition plans. Although many electric companies have already begun addressing year-2000 compliance, some have not. It was only in June that the first industrywide efforts got under way, which may not leave enough time for testing and contingency planning, according to experts. "I can't tell you overall how we stand. Based on the information we receive, we'll build contingency plans off that," said Jon Arnold, chief technology officer of the Edison Electric Institute (EEI), a trade organization in Washington that represents companies supplying roughly 75 percent of North America's electricity. The North American Electric Reliability Council (NERC) will present the first industry report on year-2000 readiness to the Department of Energy (DOE) on Sept. 14, with public release slated for Sept. 17. Until the publication of this report, serious questions about the capability of power companies to generate, transmit, and distribute electric power -- and the consequences for IT system and business disruptions -- will abound. Industry experts point to the electric system's interconnectedness as the potential source of most problems. North America is divided into three interconnected power grids, which are made up of electric generating, transmitting, and distribution companies. These thousands of companies compose a high-level network that is only as strong as its weakest segment. "If you have a failure in one place, it can affect the power delivery in many places," said Stephanie Moore, an analyst at the Giga Information Group, a research company in Westport, Conn. The risk posed by interconnectedness is made worse by deregulation. For example, a California company purchasing power from a Tennessee company may not receive it because of a transmission problem in Kansas. Unfortunately, companies have very few alternative power options, analysts say. Large companies should investigate on-site power generation, largely from generators, while small companies with limited resources might resort to candles and a return to paper -- until power is restored and IT systems brought back up. "The truth is, I don't have any good advice," said Rick Cowles, director of industry year-2000 solutions at Tava Technologies, in Penn's Grove, N.J. Many companies have been slow to tackle the year-2000 risks of their power supply, concentrating instead on their internal computing systems, analysts said. A large Fortune 200 manufacturer in the Midwest is taking this risk seriously, but has yet to cement a plan to manage the risk. The manufacturer has more than 50 worldwide locations and is urging its local facilities to contact their electricity suppliers immediately. "As we start to develop insight to what those providers are capable of, we'll draw that into business continuity and contingency planning," the manufacturer's year-2000 project leader said. Other companies such as credit card provider Household International will use in-house resources to meet the possibility of power disruption. "All our major facilities are being prepared to handle any external or internal failure, [by] having back-up generator and back-up diesel capability," said Thomas Wilkie, Household International's director of risk management, in Prospect Heights, Ill. For now, companies have to wait while the electric power industry as a whole undertakes the critical steps of gaining and sharing information. "We can't answer questions on preparedness at this point," said Gene Gorzelnik, director of communications at NERC, in Princeton, N.J. NERC is compiling results of questionnaires sent in June to the 200 largest North American power companies, and to four trade associations representing 3,000 distribution companies. Results will be included in the industry report delivered to the DOE in September. NERC will follow the report with a coordination of preparedness plans and scenario analysis ending in July 1999, and a coordination of precautionary operations during the year-2000 transition. Although NERC and the EEI expect the September DOE report to be positive generally, it is not clear whether "mom and pop" distributors or large electric utilities -- generally thought to be more vulnerable -- present a greater risk. "In a lot of cases, you can't make the assumption that mom and pops are going to be the problem, because the larger companies tend to have a lot of automation," the EEI's Arnold said. Another risk in need of assessment is the nuclear power industry. According to the Nuclear Energy Institute, a trade organization in Washington, the United States depends on nuclear power to generate 22 percent of its electricity. "You can't talk about [year 2000] and electricity without including the nuclear power industry," Cowles said. In June, the Nuclear Regulatory Commission (NRC) sent a letter the 108 U.S. nuclear power plants advising the industry of year-2000 risks and requesting a detailed written statement of readiness by July 1, 1999. Much like the NERC effort, the NRC information-gathering is a good first step, but one that leaves companies considering contingency plans in limbo. "My advice is wait for the [industry] reports and strike up a dialogue with your utility at the local level," Arnold said. ********************************************** To subscribe or unsubscribe, email: majordomo(a)majordomo.pobox.com with the message: (un)subscribe ignition-point email@address ********************************************** www.telepath.com/believer **********************************************

1 0

IP: [FP] Smart Cards -- Public Acceptance?
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

From: "ScanThisNews" <mcdonalds(a)airnet.net> Subject: IP: [FP] Smart Cards -- Public Acceptance? Date: Wed, 9 Sep 1998 22:07:48 -0500 To: ignition-point(a)majordomo.pobox.com ====================================================================== SCAN THIS NEWS 9/9/98 ======================================================================= New Poll: 76% Indicate Interest in Smart Cards SAN FRANCISCO--(BUSINESS WIRE)--Sept. 9, 1998-- Smart Card Forum research study seeks keys to market success, ways to bridge the gap between early adopters and the mainstream consumer market The Smart Card Forum (SCF), a multi-industry organization working to accelerate the widespread acceptance of smart card technology, today announced some initial top-line poll results of a qualitative and quantitative research study it has commissioned. A detailed analysis of the comprehensive study will be finalized in tandem with the Forum's Work Group meetings this November in Florida. The Forum is attempting to better understand what North American consumers would like in a smart card that they could carry around with them that stores information or value (or both) from various applications (e.g., health care, insurance, banking, loyalty programs). These applications are just some of what a smart card can do (the technology has many more applications), but a study of how consumers perceive them will help the industry better understand the potential size and shape of the future market for smart card technology. "The smart card is a very exciting and powerful emerging technology," says Forum President William J. Barr. "To extend its promise into the mainstream commercial marketplace means understanding and then delivering what consumers want. After all, it's a basic marketing premise that you have to understand the public's needs before you can deliver a solution that will win their support and loyalty. Previous Forum market research has shown consumer interest in our industry; this next wave of research is designed to provide us with more specific information that we can apply to the task of introducing smart cards to the broadest possible consumer audience." FIND/SVP, a nationally known New York-based research and consulting firm, was asked by the Forum to design the research study to capture consumer perceptions of smart cards and the keys to their acceptance and use. To do this, they designed a qualitative (14 focus groups) and quantitative (telephone survey of 2,400) research study(a) conducted in the United States and Canada. It was tightly focused to determine certain attributes of smart cards, which applications would be supported and why, plus servicing, branding, and pricing issues. For the purposes of the research, a very specific "smart card concept" was developed and tested. It was described as a "card-sized unit with a memory that can hold just about any kind of information but requires some sort of reader to input or output data." Among the research findings: - three quarters of those polled (76%) said they were "extremely," "very" or "somewhat" interested in the smart card concept; about one-third (31%) were "very" or "extremely" interested - of the 31% "very" or "extremely" interested, the majority said that they would "definitely want" smart cards for applications such as med-alert information (74%); health insurance ID (62%); ATM and related bank access (59%); drivers licenses (56%); and credit cards (53%) - the most interested group were, in general, willing to pay up to $50 to obtain a smart card, and a $25 annual fee to maintain the card - that same group carried far more cards in their wallets than those not interested (6.3 cards vs. 3.9 cards) - those most interested fit the profile of early technology adopters: younger, higher income, own a PC, etc. - convenience and security were seen as key motivating factors for adoption "These initial results reveal a number of interesting things we didn't know before," says Barr. "First, smart cards -- as they were conservatively described in the research -- have a potential core early-adopter constituency to start with of about a third of the population. Second, some of the applications a smart card can enable are easily understood and appreciated by that segment of the population. That's good news for the industry, because it is the use of smart cards for each of these individual things that will collectively increase the momentum towards multiple-application smart card interoperability and ubiquity." Interest in smart cards. All focus group respondents expressed interest in the "smart card concept." It should be noted that these groups were pre-screened to eliminate "technophobes," and participants developed concepts themselves, so higher levels of enthusiasm for smart card technology were to be expected. However, approximately three-quarters of those polled in the telephone survey said they were either "somewhat," "very" or "extremely" interested in the smart card concept. About a quarter were not interested. Who are most interested in the idea of smart cards? The research discovered that those interested in smart cards - compared to those "not interested" in the concept -- are: - much more likely to have PCs, cell phones, or other high-tech devices (98% vs. 68%) - much more likely to look forward to new technology (44% vs. 18%) - younger (38 vs. 48 years old) - have higher incomes ($54,000 vs. $45,000) - already carrying more cards than those not interested (6.3 vs. 3.9) "Those numbers tell us that as an industry, we must extend our efforts beyond the classic early adopter community and connect with the majority of consumers who need to be educated about the many benefits to them of smart card technology," says Barr. "Our ability to bridge that gap will determine the future success of our industry." One card to replace many. As designed by the focus groups, "Such a (smart) card would replace most of what they now carried in their pockets and do other things as well. It would not be used in addition to the cards in the wallets, but instead of those cards." Of those interested in having a smart card (N=741): *T Would want only one smart card 35% Would want two smart cards 30 Would want three smart cards 27 Would want four or more cards 6 *T One card that does many things. Within the qualitative phase, people were able to easily generate potential uses for a smart card. More than 100 plausible application ideas were generated, both for personal and for business use. These included: replacing money and credit cards, replacing many of the cards in one's wallet, storing records, and managing daily events. Of those interested the smart cards, respondents said that they would "definitely want" them for: Med-Alert information 74%, Health insurance ID 62, ATM and related bank access 59, Drivers license 56, Credit cards 53, Prescription card 51, Car information 50, Money for small purchases 48, Medical records 44, "Other" ID 39, Discount shopping cards 39, Money for larger purchases 36, Frequent flyer information 34, "Other" membership cards 26. According to Barr, "we are pleased by these findings on applications, because that's what smart cards are supposed to be all about. Smart cards are supposed to perform lots of diverse functions, and we're pleased that those surveyed could identify so many of them. Multi-application interoperability is both the objective of the Smart Card Forum and the key to unlocking the business potential of our industry." The ideal way to distribute and control smart cards. A consensus emerged among those most interested in the concept about how one would/should get and maintain a smart card: - consumers would obtain a "starter" smart card from one of many sources, either free or for a small fee - they would "build" onto it by adding identification and licenses, personal data, and credit data (among others), either free or for a small fee - users would pay an independent service an annual fee to help maintain and protect the card - individual smart card-holders would allow different organizations different levels of access to the card Respondents disliked the idea of a single authority having access to all their smart card key data. They accepted that in the absence of such an authority, problems with maintaining the card, replacing it, canceling it, etc. would become overwhelming. Accordingly, their plausible solution was "distributed," allowing for widespread sale of smart cards at a very low price, with the cards supported by an individual choice of one of many independent "bonding agencies" paid monthly or annual fees for their services. It was thought that data might also be backed up by this agency (in encrypted form), or saved by the card's owner who would have two versions of his/her card made. Mild preference for adding data oneself 61%, Mild preference for having one company to call for problems 59%, Mild preference for many suppliers 58%. Pricing. In general, the research discovered that of those most interested in the smart card concept, respondents were willing to pay up to $50 to obtain a card, and approximately a $25 annual fee to maintain the card. Potential smart card users rarely envisioned a single-use card that would be used in addition to the cards in their wallets. Rather, they were interested in a card that would put multiple uses on a single device. The key reasons for embracing the card thus focused heavily on convenience: fewer things in one's wallet, fewer things to remember to carry. Another initial motivator might be security. A smart card can be made significantly more secure than a normal magnetic stripe card, and when introduced to that information, survey participants indicated that smart cards might, by "electronically storing receipts in some way," provide additional reassurance. The use of electronic fingerprinting (biometrics) as proof of identity was also seen as a way to protect the security of information stored on smart cards. "Security" was also interpreted as meaning medical safety and physical well being. Accordingly, a smart card with emergency information accessible by physicians and paramedics was also considered desirable. Other ways to encourage initial smart card use focused on having a smart card doing certain things better than its "dumb" predecessor (e.g. a "faster" or "less expensive" card). Using the card as an electronic key, to which other applications might be added later, was also seen as a possible benefit. The bottom-line. "Using a very precise and narrow definition of a smart card, we have discovered useful new information that we can apply as the full spectrum of smart card applications emerges into the mainstream commercial environment," says Barr. "This is just the beginning of our industry's efforts to learn about how we can connect with and educate consumers whose interest in smart card technology increases in relation to the information they have about it." The Smart Card Forum (www.smartcardforum.org) is a non-profit, multi- industry organization of 200 members working to accelerate the widespread acceptance of multiple application smart card technology by bringing together, in an open forum, leading users and technologists from both the public and private sectors. NOTES: - The "qualitative" aspect of this study comprised a set of 14 focus groups that were conducted in four US cities (New York City, NY; Chicago, IL; San Francisco, CA; and Jacksonville, FL), and two Canadian cities (Guelph and Toronto, ON). - The "quantitative" aspect comprised a much larger and more "projectable" sample of 2,400 American and English-speaking Canadian citizens aged 18 and over who completed a structured telephone interview. Respondents were capable of using a smart card (e.g., had some other form of "plastic" card or checking accounts) but otherwise were randomly selected. CONTACT: Megan McDonnell Environics Communications 1 (203) 325-8772, #14 mmcdonnell(a)environics-usa.com or Karen Silberman Smart Card Forum 1 (703) 610-9023 help(a)smartcardforum.org ======================================================================= [forwarded from F.D. Bowden] ======================================================================= Reply to: <fingerprint(a)networkusa.org> ======================================================================= To subscribe to the free Scan This News newsletter, send a message to <majordomo(a)efga.org> and type "subscribe scan" in the BODY. Or, to be removed type "unsubscribe scan" in the message BODY. For additional instructions see www.efga.org/about/maillist.html ----------------------------------------------------------------------- "Scan This News" is Sponsored by S.C.A.N. Host of the "FIGHT THE FINGERPRINT!" web page: www.networkusa.org/fingerprint.shtml ======================================================================= ********************************************** To subscribe or unsubscribe, email: majordomo(a)majordomo.pobox.com with the message: (un)subscribe ignition-point email@address ********************************************** www.telepath.com/believer **********************************************

1 0

IP: [FP] FW: CA Fingerprinting legislation
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

From: "ScanThisNews" <mcdonalds(a)airnet.net> Subject: IP: [FP] FW: CA Fingerprinting legislation Date: Wed, 9 Sep 1998 22:12:08 -0500 To: ignition-point(a)majordomo.pobox.com ====================================================================== SCAN THIS NEWS 9/9/98 [Forwarded message] ====================================================================== Fr: Jon Golinger, CALPIRG Re: Wrap-up on Bank Fingerprinting/Biometrics Legislation in California this year Date: 9/9/98 As you know, there was significant activity in the State Legislature this year surrounding the use of fingerprints and other biometric identifiers by banks and commercial entities. This is an effort to summarize what happened this year and solidify a coalition to work together on these issues next year and in years to come. There were two main bills introduced to address the fingerprinting/biometrics issue - SB 1622 by Senator Steve Peace, which would have prohibited banks from fingerprinting customers, and AB 50 by Assemblyman Kevin Murray, which would have created some guidelines for the use of fingerprints and other biometrics in the commercial sector. Neither piece of legislation passed this year. SB 1622, backed by CALPIRG, the Privacy Rights Clearinghouse, ACLU, Ralph Nader, and others, was approved by the State Senate and the Assembly Judiciary Committee. Opposed by the California Bankers Association and some law enforcement officials, the bill was voted down in the Assembly Banking Committee in early August and remained there for the rest of the year. AB 50, backed by the California Bankers Association and some law enforcement officials, was heavily amended and approved by just one Committee, the Senate Judiciary Committee, after extensive negotiations. Opposed by Nader, ACLU, CALPIRG, Privacy Rights Clearinghouse, and the California Reinvestment Committee, AB 50 was expected to pass but was pulled from the Senate Floor and killed by leadership the day before the session ended. So, the status quo leaves many California banks still fingerprinting customers and the potential for other commercial uses of biometrics very much an open question. However, the banks and their allies failed to close the door on this issue by passing the weak "consumer protections" in AB 50 that would have effectively paved the way for fingerprinting and biometrics in a variety of commercial situations and made it difficult to pass consumer-friendly legislation in the future. This issue will surely be the subject of legislation next year. I believe that it would be in the interests of those concerned about privacy, discrimination, and "Big Brother" issues related to this subject to begin discussions or meetings before the new legislative session begins about a plan for the coming year. We may also want to consider establishing a "Privacy Coalition" to work on these and related issues as they arise. I will be in touch with interested groups and individuals about this in the coming weeks. We can be certain of one thing: the banks and their allies will be back. So will we. -----Original Message----- From: Jon L Golinger [mailto:calpirg.golinger@juno.com] Sent: Wednesday, September 09, 1998 2:56 PM To: mcdonald(a)networkusa.org Subject: CA Fingerprinting legislation ======================================================================= Reply to: <fingerprint(a)networkusa.org> ======================================================================= To subscribe to the free Scan This News newsletter, send a message to <majordomo(a)efga.org> and type "subscribe scan" in the BODY. Or, to be removed type "unsubscribe scan" in the message BODY. For additional instructions see www.efga.org/about/maillist.html ----------------------------------------------------------------------- "Scan This News" is Sponsored by S.C.A.N. Host of the "FIGHT THE FINGERPRINT!" web page: www.networkusa.org/fingerprint.shtml ======================================================================= ********************************************** To subscribe or unsubscribe, email: majordomo(a)majordomo.pobox.com with the message: (un)subscribe ignition-point email@address ********************************************** www.telepath.com/believer **********************************************

1 0

IP: Looming Y2k Crisis
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

From: "Douglas E. Renz" <dougr(a)zlink.net> Subject: IP: Looming Y2k Crisis Date: Thu, 10 Sep 1998 15:53:12 -0400 To: "'Chris Ball'" <1stlight(a)mail.tds.net>, "'En_Agape'" <en_agape(a)prodigy.net>, "'Kim/Jr'" <jrandkim(a)juno.com>, "'Kristen'" <kristen_renz(a)juno.com>, "'Steve Cortese'" <Sccortese(a)juno.com>, "'Tom Young'" <tayoung(a)cottagesoft.com> 36 Seemingly Innocuous Questions That Pry the Truth Out of Managers and Programmers Regarding the Year 2000 (Y2K) Problem and Their Organization's Looming Crisis (c) Gary North, 1997 http://www.garynorth.com The author hereby gives permission to any reporter, columnist, or journalist to e-mail a copy of this report to any colleague in the profession. INTRODUCTION The Year 2000 (Y2K) Problem is real. If it weren't, Chase Manhattan Bank would not have budgeted between $200 million and $250 million to solve it. Nobody knows what the fallout will be. My Web site offers summaries and links to documents posted all over the Web. But there are so many potential falling dominoes that nobody can predict most of what's going to happen. We will be hit from all sides without warning. Things that nobody is thinking about today will be disrupted. For example, the water-control locks on the Panama Canal are controlled by a mainframe computer system. Jimmy Carter and Congress signed away the Canal back in 1977. It goes to Panama on January 1, 2000. Will the U.S. government fund this Y2K repair? (Ha!) If not, what happens to the canal in 2000? What happens to shipping? The government is not discussing this. Dominoes. Nothing but dominoes. Maybe you can find some interesting ones locally. I have set up a closed discussion forum on my Web site for reporters who are working on Y2K assignments. You can post messages to each other. Maybe it will help. If you find an interviewing strategy that works better than what I suggest here, let me know. Meanwhile. . . . I. EXPECT TO BE STONEWALLED OR MISLED This reporting assignment is easier for women. The company's PR department will assume that a woman doesn't know anything technical. The manager or PR flak may be less guarded. If you're a woman who majored in English lit, let the public relations people know this early. For general background, read the cover story of NEWSWEEK (June 2). This is an accurate account. If anything, it is overly subdued. You need to know what is at stake internationally before you begin research on how the Millennium Bug will affect your community. My report is no cure-all. A well-informed manager is going to be paranoid about a story on Y2K and his organization. You have to hope you wind up interviewing a manager or spokesman who really doesn't understand the problem. The closer you get to the truth, the more that a careful manager will raise his "deflector shields." "We cannot divulge any proprietary information." "Our contractor is in charge of this project." "No, he cannot speak with you about this." "Our vendors are taking care of this." "No, we cannot supply their names." "We are on schedule: late 1998." When you hear any of these, be assured: you're onto something important. To get the full story, you must now earn your paycheck. You can invoke the time-honored, "We want you to have an opportunity to tell your side of the story." You may choose to hand him a photocopy of the NEWSWEEK article. "This paints a pretty glum picture. I had hoped to find out if things really are as bad as this report indicates. If your organization is on top of this problem, I would like to be able to report this to our readers." You can gently make it clear that a refusal to answer questions will make the company's situation look bad -- maybe worse than it really is. If you can't get access to a programmer, keep asking the spokesman questions, even if you get "no comment" to all of them. Write each refusal down in your notebook. This will make him nervous. The most important Y2K-threatened organizations in your community are the public utilities: water/sewers, natural gas, and above all, electricity (the national power grid is at risk). You could do a powerful series of articles on just these. They can't stonewall you as easily as a private firm can. They are politically controlled. You can go to members of the public utilities commission, tell them they you're being stonewalled, and ask for help. Ultimately, public utilities commission members will become personally liable if the system goes down and they knew about it in advance. You can even print out two or three of the documents I've posted on my Web site under "Litigation." Hand these print-outs to one or more of the PUC's members. My site's address is: http://www.garynorth.com A member of a public utility commission is at great personal risk if he lies or deliberately misleads the public, and then a disaster takes place. Call it "Chernobyl syndrome." Ask one or more of them to run interference for you. You want the interview. If you absolutely can't get access to a programmer at a public utility, print out a copy of this report and hand it to every member of the public utilities commission. Tell them they had better get these questions answered for themselves, and soon. I know of only one detailed local Y2K study that is easily available: the report on North Platte, Nebraska, written by three Creighton University economics professors. I have posted it on my site under "Government." A front-page story on Dick Brich, the programmer in charge of the county's computer system, appeared in the May 1, 1997 issue of USA TODAY. To understand the programming problem, you need a standard for comparison. Here is a good one. Social Security has had 400 programmers working since 1991 to fix its system, which has 30 million lines of code. The SSA discovered the problem in 1989. As of 1997, the system is still noncompliant. (See my Web site's category, "Government.") Use Social Security your benchmark. II. WHAT IS THE THREAT? You should assume that the spokesman or manager who has consented to be interviewed has no idea of what is involved technically in a Y2K repair. He does not know how long it will take. Neither does anyone else. Nothing on this vast scale has ever been attempted in the Information Technology world. The company probably has an official deadline: December 31, 1998. This has been forced on management by the threat of post-1999 litigation: a due diligence date, just in case the repair fails. At least a year of testing is necessary to verify that the repair is bug-free or at least manageable. The question is: Manageable by how many people? Kathy Adams of Social Security says that a 1% error rate is too high. With either 43 million or 50 million monthly checks -- she invoked both figures on separate occasions -- either 430,000 or 500,000 phone calls would hit the branch offices within days. It would overload the SSA's system, she says. (Her estimate is just for month one. What if these complaints all not taken care of, and another 1% error rate happens again next month? SSA will get a cascading effect -- noise, confusion, and telephone busy signals. Shutdown!) Medicare expects to pay a billion claims in 2000. What percentage of errors would overwhelm the system, assuming the system doesn't shut down on Jan. 1, 2000? But the manager who is speaking with you -- think of him as Dilbert's boss's boss -- has not thought about any of this. So, he has no idea what constitutes a failed repair, short of an absolute shutdown. His job is to paint a happy-face picture for you and all other inquirers. If the company is facing a disaster, he doesn't want you to find out, assuming that anyone in the company has warned him, which is doubtful. Everyone in the company has an incentive to lie. Dilbert is paid to write code. He does not make waves. Meanwhile, his boss is threatened with getting fired if he tells senior management, "I can't get this project finished on schedule. The system will crash." The boss says his team in on schedule. Who can check up on him to find out if he's behind schedule? Nobody in management. He collects his pay until December 31, 1999, at which time he turns into Maxwell Smart: "Sorry about that." Senior managers desperately want to believe the IT department, so they don't ask further questions. They hope that all their competitors are in the same condition, which is surely the case. This is why bond-rating services have refused to downgrade any organization's bonds because of Y2K risks. They're all equally at risk. III. ASSESSING THE ORGANIZATION'S VULNERABILITY Here are the Six Fundamental Questions: 1. "In what ways is your system is dependent on dates?" (It's is a soft-core version of this: "If you fail to fix this, what happens?") 2. "When did the company find out about Y2K?" 3. "At what stage is the repair: inventory, assessment, code-fixing, testing [ha!]?" 4. "How many lines of code are in the system?" 5. "How many programmers are working on it?" 6. "What is your deadline to begin testing?" It is a standard estimate that a skilled programmer with a date-search software tool ("silver bullet") can correct about 100,000 lines of code a year. This number is crucial to your final story. If you can find out how many lines of code the organization must correct and the number of programmers working full-time on the repair, you can estimate whether there is any chance they will get the problem fixed. By this I mean the local computer. This does not solve the ultimate problem: integrating a repaired computer with other computers, which, if not repaired, or repaired with a different approach, will send bad data into the first computer, ruining the repair. (There is no agreed-upon standard for Y2K repairs; every programming team is on its own, all over the world.) Be generous. Let's say that the programmers are all hot-shots. Let's say they can fix on average 10,000 lines a month. Multiply this by the number of months left until the universally agreed-upon date for the beginning of testing: December 31, 1998. Then multiply this number by the number of programmers. This will tell you if the outfit has a chance of meeting the deadline for testing. If the programmers miss the deadline -- and in 85% of all large-scale code revision projects, they do -- then this outfit the equivalent of the Titanic. Do you think that a program that's at least 500 times more complex than your word processor can be re-coded by a committee and not suffer a crash or a major glitch the first time it's run? They had better test it. What happens if they don't have time? Second, what happens if the test crashes the new system? The Jan. 1, 2000 deadline is a brick wall. Normally, 40% of a Y2K repair budget must be allocated for testing. This means 40% of the time budget unless proven otherwise. It may be higher in complex systems -- above 100 million lines of code. The spokesman may tell you the truth about the Y2K discovery date if he's proud of it: 1995 or early 1996. Keep thinking "Social Security." They found out in 1989, got started on the repair in 1991, and it's still not compliant. "Which stage?" He may not know at which stage their repair team is. If he does know, he may not want to tell you. Maybe the programmer in charge will, if he doesn't think it's privileged information. So, your goal is to get the spokesman to turn you over to the senior programmer -- or, better yet for information purposes, a subordinate programmer, who probably has no idea of the sensitivity of the information he possesses. IV. DETOUR: "PACKAGED SOFTWARE SOLUTION" I don't count these among the 36 questions. The spokesman may tell you that they will soon buy a packaged system. If you were conducting this interview in 1992, this might make sense. Today, it's too late. Packaged systems for highly complex, highly customized software are very expensive to buy and very time-consuming to implement. A packaged system is no panacea today. The problem is this: How can they port their old data and operations to the new, date-compliant software? This job takes years. (Some consultants say that it's now too late to repair code in the old systems. I'm of this opinion. But is there enough time to design and implement a replacement system? Management hasn't a clue.) He may tell you that they are switching to a client/server system. Ask how much the old system cost. Unfortunately, he may have no idea. The new system had better cost at least five times as much, given the difference in prices (inflation). If the new figure isn't at least five times higher than the old one, the company doesn't understand the magnitude of the complexity of the old system and the difficulty of switching. (On this point, I was advised by Cory Hamasaki, a full-time Y2K programmer. For his voluminous Web postings, as well as his humor, search "Hamasaki" on www.dejanews.com ) [Side Note: in a July 2, 1997, letter to me, Hamasaki reported on the U.S. government's present Y2K status. He lives near Washington. "Everywhere I checked last year, they said that they were either working on it or had solved the problem. This year, the same places are saying that it'll be tough, but they're having meetings and are doing their planning. What will they say next year? I expect that they will finally be past denial, and the screaming and scape goating will begin."] If he says they plan to outsource the job to India or Ireland, ask: "Do you have a contract with the software repair company yet?" These companies are now booked up or are close to it. The shortage of mainframe programmers is real, though not yet an insurmountable problem. It will become insurmountable in 1999. A WASHINGTON POST story predicts a U.S. shortage of 500,000 to 700,000. Another estimate places England's at 300,000. (I have posted this information on my Web site under "Too Late?") If the company has "outsourced" the project, request an interview with the contracting firm's project manager. If he says no, then you're onto something. But if you can't get additional information, the interview will be much harder. You will have to interview the person inside the local outfit who serves as the technical liaison. V. HOW TO GET ACCESS TO A PROGRAMMER After you ask the spokesman about the date they discovered the problem, ask him a technical question that seems to be important to you, but which is actually designed to get him to let you get your interview with a programmer. I suggest this question: 7. "Which method of dealing with the problem have you chosen: encapsulation, windowing, or expansion?" He won't know. It's a purely technical question. Nobody with decision-making capacity in management would know the answer. So, his ego isn't involved if he says he doesn't know the answer. You must now press politely but firmly him allow you to interview a programmer. What if he asks why you want to know? Answer: "So that I can estimate how their repair will integrate with the repairs made by other firms in your industry." You do, in fact, need to know this. This, in fact, is the crucial Y2K issue. Any repair of one system that fails to integrate with the industry's other newly repaired systems will either: (1) kick the local computer out of the system or (2) bring down the whole system. If, for example, the banks don't get together on their fixes, you and I will not be getting paid for our brilliant writing skills in 2000 and beyond. (Sad, but true.) If the spokesman thinks you're interested mainly in techie-type information, he may leave you alone with a programmer. That's your goal. If he insists on being in attendance, you must ask questions that seem to be merely technical, but which will get the programmer to tell you facts that will enable you to estimate whether the organization is going to make it. VI. YOU AND THE PROGRAMMER The lower on the hierarchy he is, the less he knows about what constitutes sensitive information. Even if the PR flak knows, he may be hesitant to tell the guy to shut up. He may not want to appear to be stonewalling. The more information you can get early, the less vulnerable you'll be to a "no further questions" announcement. That's why your early questions should be more technical. They will seem innocuous. Ask the programmer about windowing, expansion, and encapsulation. The guy will know. Ask him why they adopted their approach. The answer may or may not be comprehensible. Let him talk. It loosens his tongue. (OK, OK: loosens HER tongue. This is no time to worry about political correctness.) He's in his element. 8. Ask to see some of the code. It will be gobbledegook to you. But ask to see it. 9. Ask the guy to tell you what he has to do to change a date. Sit next to him at his screen and watch how he does it. This will give you an education. Also, it puts him in his element. He's more relaxed. He's in charge. Meanwhile, the spokesman is as clueless as you are. If possible, conduct the rest of the interview while the programmer is staring at his screen. It will give him confidence. Look at his screen or your notebook as much as you can. A lot of eye contact may make him nervous. You're after information about the number of lines of code in the system. Ask him: 10. "Would you have adopted either of the other approaches if you had been facing a system with fewer lines of code?" Let him talk code. He feels more secure. Then ask: 11. "How many lines of code are in the system?" If the spokesman doesn't intervene here, you've got a story. If it's 5 million lines or more, the outfit is in big trouble. It's a huge, complex system. Now you want to find out how many programmers are working on it full-time. Ask (12). He might even tell you. Next: 13. "When did you begin the actual code repair?" If he says that they're still in the assessment or inventory stage, this outfit is dead. Management just doesn't know it yet. Any programming team that is not actively repairing code today will be incapable of finishing the job by 2000. You will want to visit my Web site for confirmation. Read the California White Paper. Once you have the Six Fundamental Questions answered, you can begin to evaluate the company's actual condition. The spokesman may not know how to put all this information together. In fact, he probably doesn't know. He may not even see what you're up to when you ask about which stage the repair is in. If he does, he may invoke "proprietary information." Keep going: you're now after "no comments." VII. ASSESSING THE TASK'S COMPLEXITY 14. "I've heard that there are more languages embedded in a system than just COBOL. How many have you come across? Some systems will have 20 other languages. Assembler is one of the monsters. Find out if any of the system is written in Assembler. (Most of the IRS's system is in Assembler. The IRS told Congress in June of 1997 that it needs $258 million in 1998 to repair its system. The IRS may not get this money, given its admission in January, 1997, of its 11-year, $4 billion failure to consolidate its system into one. Interesting?) Then ask: 15. "How difficult will it be to keep all of the languages and programs in this system to remain integrated after you've made the necessary date changes in the code? One major problem is the compiler: a piece of software that fits all parts of the system together. The compiler that the original programmer used to build the system was not designed to handle 4-digit dates. It may not have been updated -- in fact, probably has not been updated. The company that made it may be out of business. So, if he mentions "compiler," pursue the matter, but don't mention it first. Remember, you're ignorant. Now go for the jugular. You must play the "please help me to understand all this" role. You just don't understand. You had better hope that the flak doesn't either, if he's still sitting in the room. What you're after here is information regarding the vulnerability of this organization. Which kind of dates can blow up the system and why? He won't tell you if he thinks you're looking for bombs, but he'll tell a whole lot if he thinks he's your new-found mentor. If you're looking at the screen or a print-out of indecipherable code, look helpless. Always look helpless. You may even ask the spokesman to sit closer. Let this become a joint-learning experience. 16. "You use dates in your computer software and in old data records. How do you or your software tools find them?" He probably won't volunteer that there are hidden dates in the system's programs. Dates are hidden in subroutines that his "silver bullet" can't find. Finding these is a very difficult, time-consuming task. Ask: 17. "Can the tool you use automatically find every date in the code?" It can't. There is no such thing as a true silver bullet. This is why the task is so painstaking. 18. "How do you spot dates if they're not visible?" Find out. He may tell you about the screwball names, such as some old girlfriend's first name, that the original programmer used to identify his clever, undocumented code. I emphasize "undocumented." Ask: 19. "Do you have the original documentation in front of you when you do the search?" If he says the company doesn't have it (which is probably the case), you've hit pay dirt. Don't let your face show it. Say, "Boy, that must make your work hard." It does. Let him whine about it a bit. Next: 20. "I'm having trouble understanding all this. Am I interpreting this correctly? Is the problem that all of these dates are stored as mm/dd/yy or in any other combination that has yy instead of yyyy?" This is indeed the problem. The fate of the world's economy hinges on the solution to it. Then ask: 21. "If your dates are not already in the yyyy format, do you have to go in and add the extra 2 digits, line by line, through the entire system, including all of the old data files?" Let him explain this to you. Then. . . . 22. "Is it true that when you rewrite a single line of code, this can have unpredictable repercussions in other parts of the system?" Here is the terrifying truth -- a truth that literally threatens the survival of our economy. If a programmer makes a date change in one line of code, this can have unforeseen repercussions -- always bad -- anywhere else in the system. This is why final testing is crucial. It is also why final testing will crash many systems. Then the team will have to start over: search all of the lines of code for non-date anomalies (no date- locating silver bullet tool can help here), rewrite the affected code, and test again. The system may crash again. It probably will crash again. Time will be running out. All this testing, fixing, and re-testing must be done in 1999. This assumes that firms actually meet the formal deadline for testing: December 31, 1998. This is why Chase Manhattan Bank (200m lines of code), Citicorp (400m lines) and AT&T (500m lines) have problems. So do you and I if we expect the economy to stay afloat after Dec. 31, 1999. 23. "If one change can crash the system, do you have to check every line of code in every program to insure that if a date is being used, it can accept the new date format?" He had better say yes. If he says his "silver bullet" tool can help him do this, fine, but he is still limited to about 100,000 lines of code a year. Ask him how many lines of code he can fix in a year (24). Now, you must take him into new worlds where no man has gone before. 25. "How will you test the system after all of the dates have been changed? He had better tell you by parallel testing: running data into the original program and the revised one simultaneously, to see if the revised system crashes. 26. "How long will it take to test all this?" If he estimates anything under six months, use this for comparison purposes with other local systems. The larger the program, the longer the testing period should be. Now, for the killer, the one that is unanswerable: 27. "Won't parallel [mirror] testing require two times your computer capacity and staff?" If the spokesman lets him answer this, he has made a big mistake. The rule for mainframes is "24 x 7 x 365": all year long. These expensive machines are run all day at 90% capacity except for routine maintenance in non- prime time. Here is the Achilles Heel for all of the Y2K repair hopes: there will not be enough excess computer capacity -- memory, data tapes, and staff -- to run full parallel testing if every system that must be fixed is brought to the testing phase. On the other hand, if there is no shortage in capacity, then it's because very few firms have reached the testing phase. (This is my bet.) Finally, if systems aren't tested in 1999, most of them will crash or act up to the point of uselessness in 2000. 28. "Does your firm plan to rent computer time in order to run the tests?" If he says no, ask how they can do in-house. If he says yes, ask this question: 29. "Where will you rent the excess capacity in 1999 if other organizations are also looking to rent time on mainframes?" By now, the guy knows that you know they can't fix it, test it, and implement it by 2000. You've got your story. Nevertheless, keep on going if you're allowed to. 30. "Companies rely on outside vendors for some of their programs. Have your vendors supplied you with Y2K-compliant updates? 31. "Most mainframes are not Y2K compliant, and currently no PC is. Will you be replacing all of your computer hardware as well as your computer software?" 32. "Some of the firms that you interact may not make the deadline. What steps will you have to take to insure data you get from other computers is also Y2K compliant?" VIII. BACK TO MANAGEMENT Now you can go talk to the spokesman back in his office. If he let you get this far, he doesn't understand what you've got. Move away from discussing his firm. Discuss the industry. This lets him relax. 33. "About how many suppliers does the typical organization in this industry rely on?" 34. "Is your firm typical, approximately?" 35. "Has the industry discussed contingency plans if some of its major suppliers should fail to meet the Year 2000 deadline?" Last question (36): "Where can I get copies of anything that the industry has released on Y2K?" If there isn't anything, this industry is headed for a disaster. CONCLUSION As the year 2000 approaches, this story is going to move toward the front page of every newspaper. As yet, stories on local companies have been mostly tapioca pudding. Reporters are accepting at face value the happy- face, "we're on top of this" PR interviews offered by local managers. The articles dutifully report the story: "Yes, there's a problem, but it's being dealt with by the [ ] company." Fact: the only problem being dealt with successfully the company is the reporter problem. If a local public utility goes down and stays down on January 1, 2000, the days of wine and roses will end in your community. The larger your community, the greater the problem. It is fair to give people a warning if they are really at risk. But if they are at risk, nobody in authority at the local public utility will want to admit this. Deferral has become management's job number-one. This strategy works because nobody in the media blows the whistle. Reporters (as with almost everyone else) are in denial about Y2K. Deferral and denial are the Tweedledum and Tweddledee of the Year 2000 story. * * * * * * * * * * * * ABOUT THE AUTHOR Ph.D., history, U. of California, Riverside. Contributor, <The Year 2000 Problem: Strategies and Solutions from the Fortune 100> (1997), edited by Leon Kappelman. ********************************************** To subscribe or unsubscribe, email: majordomo(a)majordomo.pobox.com with the message: (un)subscribe ignition-point email@address ********************************************** www.telepath.com/believer **********************************************

1 0