2-Mar-86 23:31:37-PST,12375;000000000000 Mail-From: NEUMANN created at 2-Mar-86 23:29:18 Date: Sun 2 Mar 86 23:29:18-PST From: RISKS FORUM (Peter G. Neumann, Coordinator) Subject: RISKS-2.20 Sender: NEUMANN@SRI-CSL.ARPA To: RISKS-LIST@SRI-CSL.ARPA RISKS-LIST: RISKS-FORUM Digest, Sunday, 2 Mar 1986 Volume 2 : Issue 20 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Risks in Encryption (Jerry Saltzer) NSA and encryption algorithms (Curtis Jackson) Low-Tech Computerized Voting (Harry S. Delugach) Risks in ballot-counting systems (Larry Campbell) Misdirected modems (Richard H. Lathrop) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA.) (Back issues Vol i Issue j stored in SRI-CSL:RISKS-i.j. Vol 1: MAXj=45) ---------------------------------------------------------------------- Date: Fri, 28 Feb 86 19:01:21 est From: Saltzer@Athena.MIT.EDU To: RISKS FORUM (Peter G. Neumann, Coordinator) Subject: Risks in Encryption Dave Platt asks: "Have any studies been done concerning the risks of having, or not having a secure data-encryption scheme to guard the integrity of one's data?" Studies I am not aware of, but my own informal observations suggest that one of the biggest risks in using good quality encryption is that when you come to use the data you may discover that a) you have misplaced the key b) it was encrypted with a different key than you thought c) a few bits have been damaged in storage d) something else went wrong and the data is unusable garbage. All these problems can be avoided, of course, but only if very careful system design is applied to key management and verification that the encryption was done right. The way to think of the problem is as follows: before you delete the original cleartext you would like a very credible proof of the theorem that "this stuff will be decipherable six months from now when I want it." After thinking about it you may decide to simply copy the cleartext to a floppy disk and lock it in your desk. At least then you have some intuition about the list of threats you are up against. Jerry ------------------------------ From: ulysses!burl!rcj@ucbvax.berkeley.edu Date: Sat, 1 Mar 86 14:56:43 est To: ulysses!risks Subject: NSA and encryption algorithms >international encryption standard sanctified by ISO. The NSA (National >Security Agency) was lobbying very strongly within ANSI (the United States' >representative within ISO) to have DES disapproved... the apparent reason >being that wide standardization of DES, and its routine use, would make it >substantially more difficult for NSA to monitor overseas voice and data >communications. IBM pushed very strongly within ANSI for a "yes" vote This is not the first time NSA has tried to stomp an encryption standard for these reasons. A few years back several business organizations (mostly major banks and other financials) got together and came up with an algorithm involving encrytion keys that were HUGE prime numbers (like 50-100 digits) to use in protecting sensitive financial data transmissions. NSA stepped in and put tremendous pressure on them not to use this algorithm -- seems it would take all their Crays about 3-4 days to break any given transmission. The pressure worked, the idea was dropped. The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj ...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj P.S.: I really don't remember where or when I read this, so correct me (publicly, if I am wrong enough) if you can and don't ask me for more details 'cause that's all I remember. Thanks! ------------------------------ Date: Fri, 28 Feb 86 10:29:10 est From: "Harry S. Delugach" To: risks%sri-csl@CSNET-RELAY.ARPA Subject: Low-Tech Computerized Voting Our local elections are tabulated by computer. The balloting itself uses that ancient (but tangible) 80-column punch card placed in a holder with candidates' names, The voter uses a little punch next to the name. After voting, the card is placed in a sealed counter, under the eyes of a polling official. Each ballot comprises a single card -- if you make a mistake, the election official tears up the card and gives you a new one. This method is a long way from the technologist's state-of-the-art, but it fosters public confidence in the vote count, because each ballot exists as a piece of paper. My father has been a polling judge for many years. His precinct (in another state) uses mechanical voting machines. To ensure an accurate count, one person reads the total off the machine while a second person watches to double-check. A third person writes them in ink on a paper tally sheet, while a fourth person double-checks. After the tallies are made, the *entire machine* is sealed and sent downtown for checking. It would involve the complicity of lots of pairs of people in many locations to make ballot- stuffing work, and not just (perhaps) one or two dishonest programmers. Not high-tech, but still reliable. As the Philippine election suggests, the public's highest priority is its trust in poll workers and the honesty of the count. The speed of the count is not as important. ------------------------------ From: hplabs!topaz!harvard!wjh12!maynard!campbell@ucbvax.berkeley.edu Date: Sun, 2 Mar 86 23:10:08 est Subject: Risks in ballot-counting systems To: RISKS@SRI-CSL > [Even in paper ballot systems, there is usually a serial number which > provides a back-link from the voter to the ballot. Otherwise fraud is > far too easy, with mystery ballots appearing out of nowhere. But > recall the earlier Phillipine election in which a local power failure > downed the central ballot-counting computer, which upon reboot > immediately finished the ballot counting. Somebody has to be trusted > somewhere. There is a choice as to whom the trust must be given. PGN] I've never seen a voting machine, so I can't comment on them. But I have been active in Massachusetts state and local politics for a few years and have always voted on paper ballots. I've *never* seen any sort of serial number and would be shocked to see such a thing. When I vote, the following steps are involved: 1. I go to the first table and tell the person there my name and address. She crosses my name off the voting list. 2. The person at the next table hands me a ballot. There is no serial number on the ballot, and no notation is made on the voting list other than to cross off my name. 3. I mark my ballot and go to the other side of the room (away from the voting list table). 4. A person there, at the ballot box, takes my (folded) ballot and inserts it into the ballot box slot. While I watch, the crank is turned to suck the ballot into the (locked) box. There are a number of techniques used to prevent fraud. 1. Each political party designates one or more observers to oversee both the polling place and the counting of ballots. Of course the observers are biased, but in opposite directions that hopefully cancel out. 2. The ballot boxes used here have a slot into which the ballot is inserted and a crank that's turned to suck it in. I don't know, but the crank could also stamp the precinct number on the ballot. If fraud is suspected, you'd look for precincts turning in more ballots than they had registered voters. 3. The voting procedure is open to challenge at any time. Voter lists are public information and are scrutinized before the election by political workers (I know, I have done this for a campaign). Anyone can go up to the polling place and challenge a vote ("I think Joe Shmoe is a pseudonym and I challenge his ballot"). When Joe Shmoe votes, his ballot is set aside as a challenged ballot and is verified separately. Of course, in this case his ballot is marked (I presume by being placed in a sealed envelope with his name on it) but if he is verified as a legitimate voter then his ballot can be mixed in with the other ballots anonymously. (Just like an absentee ballot.) Of course, once the ballot is cast it's anonymous and can't be challenged in particular. When I worked as an observer at the polls we were encouraged to challenge any voter or name that looked the least little bit fishy (of course, the unspoken rule was you'd only challenge voters wearing a button for the opposition). It doesn't hurt to challenge a ballot that turns out later to be valid (other than annoying the precinct workers) but if you fail to challenge a truly invalid ballot, it's pretty difficult to do anything about it after the fact. Sorry about the length, but the gist of this is that, around here anyway, once you investigate you find that there are enough checks and balances to make fraud (not impossible but) unlikely, and also to guarantee secrecy. If voting operates substantially differently in other parts of the country I'd be interested in hearing about it. -- Larry Campbell The Boston Software Works, Inc. ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109 ------------------------------ Date: Sun, 2 Mar 86 07:58 EST From: Richard H. Lathrop Subject: Misdirected modems To: RISKS@SRI-CSL.ARPA RISKS-LIST: RISKS-FORUM Digest, Monday, 24 Feb 1986 Volume 2 : Issue 14 From: Date: Mon, 24 Feb 86 11:12:54 pst Twice recently, computers at our company (Hewlett-Packard) have been the embarrassing causes of telephonic annoyance. Phone numbers entered incorrectly in uucp L.sys files, due to typos or misunderstandings, have led to systems repeatedly calling private telephones in Fort Collins. The recipients of such calls, understandably annoyed, have had to backtrack through Mountain Bell to discover the cause. I bet this happens a lot more than anyone realizes or admits. Yes, I suspect this does. I am reminded of a time several years ago when I was in Oregon working on a tide-monitoring system for NOAA (Natl. Oceanic & Atmospheric Admin.). They were interested in accurate measurements of tidal depth for navigation charts, storm surge & tsunami monitoring, etc., and we developed a remote station for them which would measure the water depth to the nearest 1/100 inch every 6 minutes and store the data in internal memory. There were several of these scattered along the coasts and Great Lakes, and every couple of days a master controller would call them all up (at midnight, to take advantage of lower phone rates & line activities) & drain their data. At the time I was writing the Assembler telecommunication subsystem and a partner was writing the Fortran user-interface and control system. Since we only had one development machine, I was on a night schedule & he was on days. Predictably (by 20-20 hindsight), while testing one midnight the call was answered, not by our remote, but by a very sleepy & puzzled Michigan housewife (2:00 am there). I suddenly found myself on the line trying to explain that I was not a prankster, but that my computer had dialed her up from Oregon and warbled at her, by mistake. Of course, a typo had been made in the data file that specified the phone numbers. One thing to note about this incident is the separation between the specification function (done on the daytime schedule) and the test function (nights). While it is always possible to err, this separation precluded the possibility that we could cross-check each other. -=*=- Rick Lathrop rickl%oz@mit-ai ------------------------------ End of RISKS-FORUM Digest ************************ -------