Subject: RISKS DIGEST 13.36 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 6 April 1992 Volume 13 : Issue 36 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: More Glitches in Time -- and Gambling profits (anonymous) X400 (Cliff B Jones) Re: Good crypto (Fred Cohen) Correcting Erroneous Database Listings (Steven S. Davis) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Mon, 6 Apr 92 12:37:12 xDT From: [anonymous] Subject: More Glitches in Time -- and Gambling profits This being daylight savings day, a programmer down the hall at another firm and I got onto a discussion of time related programming errors. He related two very interesting real-life errors that I thought you all would be interested in. Both of these programming failures were discovered when he worked at a race and sports book (ie gambling hall). These both happened in Las Vegas, and the names and places are not being posted to protect the guilty from shame. :-) For those not familiar with how sports books work: Basically the book takes bets on sporting events, and horse / dog races. Bets are PLACED up to a particular point (usually start time), at which time that event is CLOSED. After the event is over, the winner is POSTED. Bets are then paid based on the posted winner. The computers (of course), have safety features to prevent you from placing a bet after an event is closed. The closing and posting is done by a single person, who spends all day watching 6 or 7 TV's. Of course, the system keeps an "accurate" audit trail with regard to the times that items are entered. At a local book they were using a system that was designed for horse races, but instead they were using it for dog races. Now Nevada law says that betting stops when the first horse enters the gate (minutes before the race is over), but dog races are not closed until a few seconds before the gate opens. Dog races are also fast, taking ~30 seconds. The difference in time span is crucial, because the system originally only recorded the time in HH:MM, since seconds were not crucial for a long horse race. Because of this, a race could close, start, and be posted, all within the same minute. This meant that you could sometime place a bet after the game was over, and the computer would still accept the bet. (REAL MONEY) At another book, the employees managed to cheat the system for about three months. It was obvious to the auditing department that some cheating was going on, but all the computer records were clean, but it was equally obvious that everyone on the floor was ripping the book off. They way it worked was this: When a game started in New York at 7PM (ATLANTIC COAST TIME), they would close the game at 7PM (PACIFIC COAST TIME). Everybody in accounting assumed that the computer tracked the times in the proper time zone for that game, because that's how the employees were using it. Eventually someone asked one of the programmers, and found out that all times were supposed to be in local time, and well..... P.S. The book that discovered these two bugs never bothered to report them to any of the other books using the same software. :-( ------------------------------ Date: Sun, 5 Apr 92 15:35:11 BST From: Cliff B Jones Subject: X400 I have recently run into a problem with the X400 protocol that could I believe kill e-mail as we know it. Remember when messages used to be conveniently queued? Well, if the X400 is "congested" it sends a (long) rejection message (which does *not* include the original message!) back to the originator. Just imagine a conventional mailing service where the delivery man who has too much to carry just sends back a note saying "I threw your mail in the trash". I also understand that the whole problem comes from charging arrangements between PTT's - no one want to pay for storage so reject the messages when busy, don't send them back (but remember to charge for the rejection message). I'd love to be corrected on this! If I'm right, e-mail could just die. I've already given up using it other than at weekends from here to Germany. cliff jones ------------------------------ Date: Sun, 5 Apr 92 20:21 EDT From: fc Subject: Re: Good crypto [risks of posting risks to RISKS] (Cohen, RISKS-13.34) My computer must be slow ... I still haven't gotten a copy of the risks posting I made several days ago, but I've gotten several computer mail postings from around the world about the posting. I guess information posted to risks gets to the EC before the US. Yes [to a query], you can print what I said in risks elsewhere, but I can't imagine why you would want to. Someone in the EC thought (I think) that I was complaining about the EC's policy. Not so. I was complaining about the US policy that you can't export the DES or RSA, even though you can buy it cheaply everywhere you have to get approval for export. There's even a public domain version of the DES (source in C) widely available in the US. (I would post it on risks, but I'm afraid that risks might then export it). It seems that US law permits me to publish my source code for the RSA and export that, and if you have a scanner, you can read it into your computer legally. I think I am now leaning toward publishing the illegal-to distribute portion of my system on paper and shipping it in the manual. Then you only have to type in the expression (defun encode (x) (mexpt x e n)) to implement the RSA on your system. After all, it is legal to sell software that does very fast modular exponentiation with unlimited precision! if the default version of encode is (defun encode (x) x), it doesn't violate US law because it doesn't encrypt!! As to doing the development in Israel, I understand you can get very inexpensive mathematical expertise in Israel, and according to recent rumors, you can sell in volume to China from there, but on the other hand, the total effort of developing the cryptosystems requires only a few hours of relatively non-expert programming time. You can still do the theory in the US and export it on paper. By the way, the source code for one of the cryptosystems I am not allowed to export without permission was published in Computers and Security (the IFIP journal), so I understand that my competitors are using the algorithm already. I guess it's alright to have my competitors sell my cryptosystem in the rest of the world as long as I can't. Fred ------------------------------ Date: Mon Apr 6 13:05:24 1992 From: paa1338@dpsc.dla.mil (Steven S. Davis) Subject: Correcting Erroneous Database Listings In the article "Bad data allowed to enter driver database and used as basis for arrest" in RISKS-13.34, Eric Postpischil described the problems that resulted when public officials put false data into their databases. The problem of false data finding its way into interacting databases and spreading throughout them and becoming hard to completely eliminate, as you don't even know all the places it may have reached, is already real, and can be expected to get worse. Mr. Postpischil correctly indicates that a person should be reviewed as the owner of his or her data in a public database and be advised of changes and able to make corrections. However, the public databases are only a tiny fraction of those containing records on you. Most of them are private, the owners regard the information as proprietary, and would never accept the expense of notifying the subjects of changes. So what can be done to protect people from bad data ? The answer that I would propose for consideration is that the great nightmare of science fiction, an authoritative official database, may be in fact the only way to protect ourselves from all the little brothers spreading information about us. If an such an authoritative database existed, any other database that used information on you that was contradicted by the authoritative database would expose it's owners to liability. They would therefore have to assure that before any data was used it would be checked against the central database. If some bad data was circulating about you, it could be stopped with one update to the central record, and if that failed, you would have a clear case of negligence, and a much better chance of collecting damages if the falsehoods did you any harm. I don't propose that this database list all the facts about you, though some people might prefer that it carry very complete data. It would include only a)the information that you gave it, and b) information that was placed there as the result of a contract, court case, or other legal action. The subject of the data would have full access to the information and the right to require corrections. There would probably be a fee involved for each piece of information posted ( usually paid by the subject, though in some cases by others or by public agencies, and possibly only covering a certain period of time ), but corrections would be free. It would generally only involve data you need to protect yourself from falsehoods. In most cases this would only involve offering appropriate identification of oneself and documentation of the data, but when facts are disputed the entry might require a court to decide the facts and authorize the change. I've no firm idea on how such a thing would be set up. I don't expect it soon, because of the cost and because of continuing fears of such centralized information. But as there is already a massive amount of decentralized information about us out there, the owners of which are not accountable to us though they can have devastating impacts on us, it seems to me that a centralized, accountable record is a desirable thing, and that the lack of one puts us more at risk than the creation of one. [The silly parts of the above opinions are wholely my own; any intelligence that crept in was probably borrowed. None of it reflects the position of my employer. Steven S. Davis ( ssdavis@dpsc.dla.mil )] ------------------------------ End of RISKS-FORUM Digest 13.36 ************************