You are viewing an obsolete version of the DU website which is no longer supported by the Administrators. Visit The New DU.
Democratic Underground Latest Greatest Lobby Journals Search Options Help Login
Google

Reply #27: A LWV Memeber Explains In Laymen's Terms.... [View All]

Printer-friendly format Printer-friendly format
Printer-friendly format Email this thread to a friend
Printer-friendly format Bookmark this thread
This topic is archived.
Home » Discuss » Archives » General Discussion (Through 2005) Donate to DU
RedEagle Donating Member (1000+ posts) Send PM | Profile | Ignore Tue Jul-29-03 01:34 PM
Response to Reply #25
27. A LWV Memeber Explains In Laymen's Terms....
We have League members working their best on this issue! This explanation also does not need remote access.


To: LWVTopics
Date: Tue, 29 Jul 2003 02:29:32 -0700
Subject: Re: DRE paper trails

All, I wasn't going to continue with more comments, but I seem to think that realistic situations are not being considered in this discussion.

First, though I do not have a degree in computer science, I have
taken numerous courses and have spent my professional life
programming and testing computers do to a number of complicated
tasks from making one computer to talk to another a precursor to the internet), to commanding satellites, to developing sophisticated codes to simulate the circulation patterns of the ocean.

I know what it takes to test software and know that programming
errors occur.

One has to separate the issues.
1) Reliability of the software to correctly count.
2) Corruption of code by individuals.


Issue 2) Code Corruption: here I assume that the computer voting
machines are not connected to a network. Say there are
7 vendors of such machines nationwide. And let's say
that 1 vendor has 1 (or several) corrupt programmer.
This programmer modifies the code so that it will change
Republican votes to Democratic (since the programmer
doesn't know where a machine will end up, can't really
modify votes of individual names). Also, the programmer
may or maynot know what area the machine will end up in,
so changing Rep. votes to Dem. votes may not matter. This
type of corruption can be checked for with good certification
testing and procedures.

Actually, a good programmer would devise such a logic bomb to evade the testing procedures. Here's how I (with over 35 years of programming experience) would do it, if I were a dishonest (or fanatically zealous)programmer at one of the DRE vendors:

- I only care about rigging the elections for President, Governor, US
Senate, and Congress, so those will be the only ones I affect. (Maybe
I'll include the state legislature as well, but the names of those
offices vary so much from state to state -- Assembly, House of
Delegates, State House -- that incorporating the information for all 50 states might be too much trouble to go to.)

- Since I don't know who will be running in any given race, I will go
by party affiliation.

- Since I don't want it to be obvious, I will take, say, on average ten percent of the votes for party X and give it to party Y. I will
display to the voter what they selected, but I will record it
internally the way I want. This will only affect close races (55/45
and closer), but then that's the point. To give an election to one
party in a district that's safe for the other would arouse suspicion.
Shifting 10% of the votes should be sufficient. (I can also take more
votes from the minor parties -- they won't notice.)

- Since I have to show the source code to the testing authorities, I
will create my "logic bomb" using the techniques described by Unix
co-inventor Ken Thompson in his 1984 ACM Turing Award lecture so that
it doesn't show up in the source code. (See
http://www.acm.org/classics/sep95 for the description.)

- Since I need to be honest when the elections officials and testing
authorities run the logic and accuracy tests, I won't actually alter
the ballots as they are cast, but wait until the machine is "closed".
If the machine is being closed at a reasonable closing time (say,
between 8pm and 8:30pm), and it was opened at a reasonable opening time (say, between 6am and 7:30am), and it's the first Tuesday after the first Monday in November in an even year, then I will go back over all the stored ballots and rewrite ten percent of the votes given to the "wrong" party. If it's not election day, or it's outside normal election times, or the machine is being opened way late or closed way early, I'll assume that this isn't a real election and I won't change any votes.

- I will use a random-number generator, seeded by the machine-readable
serial number, to decide which of, and what percentage of, the "wrong"
ballots to change. The reason for this will become clear further on.

- Since the testing people may try to fool me by changing the date and
time, I'll fool them instead. The real-time-clock (RTC) chip is set at the factory using a manufacturing interface, not through the screen.

The testing authorities and the elections officials don't have access
to the manufacturing interface, so they have to use the screen when
they want to change the date or time. So when that interface is used,
instead of changing what's in the RTC, I'll just store the difference
in a memory location, and take that into consideration when displaying
the time. For example, if it's noon on Monday, November 1st, 2004, and they set the date to 8am Tuesday, November 2nd, I'll put "20 hours" into the offset location, and add it to the RTC value whenever I need to display it. My logic bomb will only trigger if the RTC says it's really election day and the offset value is zero (or close to zero; maybe I'll let them change the time by a few minutes.)

- Just to make sure, before I alter any votes, I'll make sure they
haven't been cast in the typical logic-and-accuracy pattern of one vote for each of the first selections, two votes for each of the second selections, and so on. I'll also check for the "typical" voting pattern of a few voters in the morning, a lunch-time surge, scattered voting in the afternoon, and an evening rush.

- About the only way they can detect that I've rigged the machine is by setting aside some machines on election day and casting ballots on them throughout the day using a pre-arranged script. The script will have to include when to cast each ballot as well as how, since it has to mimic an actual polling place. If they find a discrepency, they'll
have to decide if it's the machine, or if they made a mistake in following the script. If they test multiple machines with the
identical script, my use of a random-number generator will result in
different machines behaving different ways, further confusing the
testers. And if they do decide it is the machine, what are they going
to do? The polls are closed! Are they going to order a new election?

Not likely! They'll probably order more tests, and on additional
machines, and since the election will be over when they conduct these
tests all the machines will work perfectly.




So, ______, and everyone else who doesn't see the necessity for a
voter-verified audit trail: You're the election official. Assuming
you've gone to the trouble of conducting this so-called parallel
monitoring, what are you going to do? (I doubt most election officials would go to the trouble of parallel monitoring anyway.)


--Steve Chessin
LWV
Printer Friendly | Permalink |  | Top
 

Home » Discuss » Archives » General Discussion (Through 2005) Donate to DU

Powered by DCForum+ Version 1.1 Copyright 1997-2002 DCScripts.com
Software has been extensively modified by the DU administrators


Important Notices: By participating on this discussion board, visitors agree to abide by the rules outlined on our Rules page. Messages posted on the Democratic Underground Discussion Forums are the opinions of the individuals who post them, and do not necessarily represent the opinions of Democratic Underground, LLC.

Home  |  Discussion Forums  |  Journals |  Store  |  Donate

About DU  |  Contact Us  |  Privacy Policy

Got a message for Democratic Underground? Click here to send us a message.

© 2001 - 2011 Democratic Underground, LLC