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) <[email protected]>
Subject: RISKS-2.20
Sender: [email protected]
To: [email protected]

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 [email protected], Requests to [email protected].)
(Back issues Vol i Issue j stored in SRI-CSL:<RISKS>RISKS-i.j.  Vol 1: MAXj=45)

----------------------------------------------------------------------

Date: Fri, 28 Feb 86 19:01:21 est
From: [email protected]
To: RISKS FORUM    (Peter G. Neumann, Coordinator) <[email protected]>
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: [email protected]
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" <hsd%[email protected]>
To: risks%[email protected]
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: [email protected]
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:[email protected]       120 Fulton Street
UUCP: {harvard,cbosgd}!wjh12!maynard!campbell  Boston MA 02109

------------------------------

Date: Sun, 2 Mar 86 07:58 EST
From: Richard H. Lathrop <[email protected]>
Subject: Misdirected modems
To: [email protected]

   RISKS-LIST: RISKS-FORUM Digest,  Monday, 24 Feb 1986  Volume 2 : Issue 14

   From: <[email protected]>
   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
************************
-------