Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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
>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!
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.
> [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
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