The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 2 Issue 20

Sunday, 2 Mar 1986

Contents

o Risks in Encryption
Jerry Saltzer
o NSA and encryption algorithms
Curtis Jackson
o Low-Tech Computerized Voting
Harry S. Delugach
o Risks in ballot-counting systems
Larry Campbell
o Misdirected modems
Richard H. Lathrop
o Info on RISKS (comp.risks)

Risks in Encryption

<Saltzer@Athena.MIT.EDU>
Fri, 28 Feb 86 19:01:21 est
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


NSA and encryption algorithms

<ulysses!burl!rcj@ucbvax.berkeley.edu>
Sat, 1 Mar 86 14:56:43 est
>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!


Low-Tech Computerized Voting

"Harry S. Delugach" <hsd%virginia.csnet@CSNET-RELAY.ARPA>
Fri, 28 Feb 86 10:29:10 est
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.


Risks in ballot-counting systems

<hplabs!topaz!harvard!wjh12!maynard!campbell@ucbvax.berkeley.edu>
Sun, 2 Mar 86 23:10:08 est
> [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


Misdirected modems

Richard H. Lathrop <RICKL@OZ.AI.MIT.EDU>
Sun, 2 Mar 86 07:58 EST
    RISKS-LIST: RISKS-FORUM Digest,  Monday, 24 Feb 1986  Volume 2 : Issue 14

    From: <hp-sdd!hpfcla!ajs@nosc.ARPA>
    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

Please report problems with the web pages to the maintainer

Top