Linux vs. windows for voting systems?

In comp.os.linux.advocacy, Jean-David Beyer
<jeandavid8.RemoveThis@verizon.net>
wrote
on Wed, 01 Aug 2007 22:30:53 GMT
<xQ7si.8510$FO1.7558@trnddc05>:
> The Ghost In The Machine wrote:
>> In comp.os.linux.advocacy, Jean-David Beyer
>> <jeandavid8.RemoveThis@verizon.net>
>> wrote
>
>> Of course the tally box might have its own ideas on the
>> matter anyway. "Oh, he voted for Smith. I'll count it
>> for Jones instead". Fortunately, gimmicked tally boxes
>> are replaceable if someone asks the right questions (and
>> can detect the tampering somehow; one might sample the
>> vote for checking purposes during the voting interval).
>
> Well, were I to try to compromise a tally box, I would have
> it goof around for an hour or so, and then have it erase all
> evidence of its presence. So someone would have to suspect I
> did that and replace the tally box. The chances of that are remote.

A very good point. I'd randomly pick a certain percentage
of votes -- roll an N-sided die, internally; if it comes up
1 I play diddle -- and at least that way it's less obvious.

>
> What good would sampling the vote do? You would compare it with
> what?

I would compare a sample of the vote using another tally
box with the "official" vote on the original tally box.
That may or may not be possible -- or even desirable;
what's to prevent both tally boxes from being shipped
to the state controller, or for that matter being
gimmicked? -- but it's the best I can do.

Exit polls are also a possibility; they were, up until
2000 or 2004, fairly close to the official vote. But
at some point, one wonders what happened -- either the
voters lie to the pollsters, or the ballot is lying to
the counters.

> If I
> were tampering with the tally box, I would not put all Democrat
> votes in the Republican pile (or vice versa). Perhaps I would put
> only the minority parties in the party of my choice pile,
> lowering the probability of detection.

In a close race, very little tampering would be required.
Even if the race weren't all that close, one might pull
off a "surprise" if one can get it to within about 2%
of the magic 50%-50% boundary.

> Even with paper ballots, or old lever action machines this
> happens. One year I voted for a candidate for a minority
> left-wing party in my town that is so Republican that
> Democrats do not even bother to run for all the available
> offices. Well, when the newspapers came out, they counted
> NO votes for my candidate. They should have counted at least one.

Interesting. Of course the 2000 election got very strange
in Florida, with such things as dimpled and pregnant
chads. Not everyone can punch the awl (our system here
in Santa Clara country prior to 2004 or so; it was cheap
and reasonably simple, but we replaced it anyway )
or pull the lever with sufficient force.

>>
>>> 3.) What does the voter do when the bad guy uses his Credit Card ID and so
>>> when the good guy tries to vote, the central machine rejects his vote
>>> because it was already used? How does he prove that someone else hijacked
>>> his vote?
>>>
>>
>> Certificates can't really address this problem either.
>> Related issues include "pet/dead guy" voting, ballot
>> box stuffing, and throwing out valid votes -- an extreme
>> case is to throw out every vote for a Democrat, or just
>> a percentage thereof, in certain assembly districts.
>>
>> Not that paper ballots can do much here, either, although
>> it might fix the "pet vote" problem -- can Fido hold a pen?
>> But boxes filled with ballots are "lost" easily enough, even
>> in a paper world.
>>
>> E-voting just make "losing" ballots easier and less obvious.
>>
>

--
#191, ewill3.RemoveThis@earthlink.net
Useless C++ Programming Idea #12995733:
bool f(bool g, bool h) { if(g) h = true; else h = false; return h;}

--
Posted via a free Usenet account from http://www.teranews.com

The Ghost In The Machine <ewill.RemoveThis@sirius.tg00suus7038.net> wrote in
news:ul77o4-r35.ln1@sirius.tg00suus7038.net:
> In comp.os.linux.advocacy, Jean-David Beyer
> <jeandavid8.RemoveThis@verizon.net>
> wrote
> on Wed, 01 Aug 2007 19:33:32 GMT
> <ge5si.8067$8u1.3836@trnddc07>:
>> x0054 wrote:
>>> resonator80 <w.edelstein.RemoveThis@gmail.com> wrote in
>>> news:1184512183.628120.165180@q75g2000hsh.googlegroups.com:
>>>
>>>> Computerized voting systems (aka DREs or Direct Recording
>>>> Electronic) must be based on an operating system, for example,
>>>> Windows or Linux.
>>>>
>>>> Linux has the advantage of being open so that all the source code
>>>> can be open. Windows source code will not be opened to anyone.
>>>>
>>>> Some people have argued that the basic Windows operating system can
>>>> remain secret as long as the voting application program (i.e. C,
>>>> Python, etc) is open.
>>>>
>>>> Here are some questions about such an arrangement.
>>>>
>>>> 1. Could someone tamper with the Windows OS or put in some
>>>> additional code that would not be found in an inspection of the
>>>> application program that could alter the results?
>>>>
>>>> 2. Could viruses and other malware affect the OS and, ultimately,
>>>> an election without its effects being detected by examining the
>>>> application program?
>>>>
>>>> Any other comments are welcom.
>>>>
>>>> Thanks, Bill Edelstein Baltimore, MD
>>>>
>>>
>>> Solution to all voting problems: FireFox. Just do internet voting
>>> that would work through a secure tunnel that can be established
>>> using a modified copy of FireFox.
>
> And a modification would be required precisely...why?
>
>>> It's simple, could work on any computer, and
>>> would be really easy to implement. Instead of a voting card you get
>>> a Credit Card CD. You put it into your computer and it either boots
>>> from it, or starts a modified copy of FireFox with individual SSH
>>> key to the central server.
>
> ITYM "certificate". There is a provision in RFC4346 --
> I'd have to look to see exactly where -- that allows a
> server to only allow connections from boxes with valid
> certificates that the server can trust (as determined
> by trust chain). I'd have to dig/experiment to see how
> to properly set this up, but Firefox can easily import
> certificates ("your certificates").
>
> Certificates also expire after a certain amount of time.
> Assuming the server's not compromised (!), it can
> easily check to see whether one is voting with an expired
> certificate.
>
>>> Once you have voted, the key is deleted from the server
>>> so you can no longer vote but there is no way to link you to your
>>> vote, for privacy reasons, and at the same time you get a print out
>>> with a generated key that has your votes encrypted into it along
>>> with unique identification number for identification.
>
> Certificate revocation is possible. Not sure who would
> do the actual revocation, and the Internet isn't *that*
> reliable -- press on "SUBMIT", and watch one's network
> link go down, for example; did one vote or not?
>
> (The issues aren't too different from commercial
> transactions, though the latter have the advantage of
> requiring the buyer to be identified through his card
> number -- and of course eventual payment.)
>
>>>
>>> It's simple, and easy, and can be done in any library or school with
>>> no extra useless equipment.
>>>
>> For every difficult complex problem, there is a solution that is
>> simple, elegant, and wrong.
>
> Indeed.
>
>>
>> This does not address several factors:
>>
>> 1.) How does the voter assure himself that the Credit Card CD, or
>> whatever is used, is a valid one and is not a substitute provided by
>> someone, possibly an employee of the election commission, attempting
>> to commit election fraud?

Well, for one because each CD would have a unique key that identifies it to
the server, and there will be only as many CDs as there are registered
voters. But, furthermore, how does the voter know now that the election
commission worker isn't giving himm or her a fake paper ballot, or even
counting that ballot rather then just shredding it as soon as the voter
leaves.

>
> Certificates include certain identity features, including
> city of issuance and a parent. This might be construed
> as a partial solution -- fictitious names are easily
> registered if the process is not careful.
>
>>
>> 2.) How does the voter know that the program at the other end is
>> fraud proof. It could easily count your vote and put it in the wrong
>> column, but return you the vote as you made it. All the problems
>> associated with electronic voting machines in a polling place still
>> exist, and you have added a few more.

There is no full proof system, the problem you are describing are as
possible with paper systems as they are with electronic systems.

>
> Certificates will not address this problem. I'll admit
> I see no elegant method by which one can verify that what
> the tally box counts is what the voter put in. Best I can
> do is to have Firefox locally hash the vote (this can
> be done in Javascript) and then bundle the hash along
> with the vote, digitally encrypt it with the temporary
> certificate's private key, then send the encrypted packet
> to the voting box. Ideally, one would send a thumbprint
> as well, though there are some issues if one tries to look
> up said thumbprint and find the voter's identity; the vote
> should be verifiably from a citizen, but private. Of course
> thumbprints are a hardware problem...
>
> Any tampering with the vote values would invalidate the
> hash. This might be overkill (signing it is a hash anyway).
>
> Of course the tally box might have its own ideas on the
> matter anyway. "Oh, he voted for Smith. I'll count it
> for Jones instead". Fortunately, gimmicked tally boxes
> are replaceable if someone asks the right questions (and
> can detect the tampering somehow; one might sample the
> vote for checking purposes during the voting interval).
>
>>
>> 3.) What does the voter do when the bad guy uses his Credit Card ID
>> and so when the good guy tries to vote, the central machine rejects
>> his vote because it was already used? How does he prove that someone
>> else hijacked his vote?

What happens in Chicago when you go up to your district to vote but for
what ever reason they have you down as already voted? Fraud will always be
part of the system. However, think about it this way, if we use a 2048 bit
key to identify the valid voters, and we have, at the very most, 200
million voting (more like 100 actually) the possibility of the "bad guy"
finding even one correct key is 1 in 1.6E608. Yes that's 1 to 16 with 607
zeros after it. If you limit a connection try's to one per IP per min there
is no way any one will be able to guess the correct key.

>
> Certificates can't really address this problem either.
> Related issues include "pet/dead guy" voting, ballot
> box stuffing, and throwing out valid votes -- an extreme
> case is to throw out every vote for a Democrat, or just
> a percentage thereof, in certain assembly districts.
>
> Not that paper ballots can do much here, either, although
> it might fix the "pet vote" problem -- can Fido hold a pen?
> But boxes filled with ballots are "lost" easily enough, even
> in a paper world.
>
> E-voting just make "losing" ballots easier and less obvious.
>

Here is the way voting works in the City of Chicago:

1. You register at the voting place and are given a big, placemat looking
thing and a marker.

2. You mark the names you are voting for and give that placemat to an
election admin who then places this exceedingly large paper into a large
scanner and digitizes it.

3. The results are stored on a compact flash card, yes, a compact flash
card!

4. Once the card is full they take it out of the scanner and place it into
a small transmitter box which uses the pager network, yes, I am not joking,
a pager network, to send the results to the central computer.

Now, you tell me the system I proposed isn't safer! I think there is
absolutely an easy way to do this, there just is. I agree that the system
should be centralized as well as decentralized, and should contain safety
checks. But we really need to get away from a paper system.

- Bogdan

In comp.os.linux.advocacy, x0054
<x0054.RemoveThis@index.com>
wrote
on 01 Aug 2007 22:51:47 GMT
<Xns997FA18C634B1x0054indexcom.RemoveThis@yourdomain.com>:
> The Ghost In The Machine <ewill.RemoveThis@sirius.tg00suus7038.net> wrote in
> news:ul77o4-r35.ln1@sirius.tg00suus7038.net:
>> In comp.os.linux.advocacy, Jean-David Beyer
>> <jeandavid8.RemoveThis@verizon.net>
>> wrote
>> on Wed, 01 Aug 2007 19:33:32 GMT
>> <ge5si.8067$8u1.3836@trnddc07>:
>>> x0054 wrote:
>>>> resonator80 <w.edelstein.RemoveThis@gmail.com> wrote in
>>>> news:1184512183.628120.165180@q75g2000hsh.googlegroups.com:
>>>>
>>>>> Computerized voting systems (aka DREs or Direct Recording
>>>>> Electronic) must be based on an operating system, for example,
>>>>> Windows or Linux.
>>>>>
>>>>> Linux has the advantage of being open so that all the source code
>>>>> can be open. Windows source code will not be opened to anyone.
>>>>>
>>>>> Some people have argued that the basic Windows operating system can
>>>>> remain secret as long as the voting application program (i.e. C,
>>>>> Python, etc) is open.
>>>>>
>>>>> Here are some questions about such an arrangement.
>>>>>
>>>>> 1. Could someone tamper with the Windows OS or put in some
>>>>> additional code that would not be found in an inspection of the
>>>>> application program that could alter the results?
>>>>>
>>>>> 2. Could viruses and other malware affect the OS and, ultimately,
>>>>> an election without its effects being detected by examining the
>>>>> application program?
>>>>>
>>>>> Any other comments are welcom.
>>>>>
>>>>> Thanks, Bill Edelstein Baltimore, MD
>>>>>
>>>>
>>>> Solution to all voting problems: FireFox. Just do internet voting
>>>> that would work through a secure tunnel that can be established
>>>> using a modified copy of FireFox.
>>
>> And a modification would be required precisely...why?
>>
>>>> It's simple, could work on any computer, and
>>>> would be really easy to implement. Instead of a voting card you get
>>>> a Credit Card CD. You put it into your computer and it either boots
>>>> from it, or starts a modified copy of FireFox with individual SSH
>>>> key to the central server.
>>
>> ITYM "certificate". There is a provision in RFC4346 --
>> I'd have to look to see exactly where -- that allows a
>> server to only allow connections from boxes with valid
>> certificates that the server can trust (as determined
>> by trust chain). I'd have to dig/experiment to see how
>> to properly set this up, but Firefox can easily import
>> certificates ("your certificates").
>>
>> Certificates also expire after a certain amount of time.
>> Assuming the server's not compromised (!), it can
>> easily check to see whether one is voting with an expired
>> certificate.
>>
>>>> Once you have voted, the key is deleted from the server
>>>> so you can no longer vote but there is no way to link you to your
>>>> vote, for privacy reasons, and at the same time you get a print out
>>>> with a generated key that has your votes encrypted into it along
>>>> with unique identification number for identification.
>>
>> Certificate revocation is possible. Not sure who would
>> do the actual revocation, and the Internet isn't *that*
>> reliable -- press on "SUBMIT", and watch one's network
>> link go down, for example; did one vote or not?
>>
>> (The issues aren't too different from commercial
>> transactions, though the latter have the advantage of
>> requiring the buyer to be identified through his card
>> number -- and of course eventual payment.)
>>
>>>>
>>>> It's simple, and easy, and can be done in any library or school with
>>>> no extra useless equipment.
>>>>
>>> For every difficult complex problem, there is a solution that is
>>> simple, elegant, and wrong.
>>
>> Indeed.
>>
>>>
>>> This does not address several factors:
>>>
>>> 1.) How does the voter assure himself that the Credit Card CD, or
>>> whatever is used, is a valid one and is not a substitute provided by
>>> someone, possibly an employee of the election commission, attempting
>>> to commit election fraud?
>
> Well, for one because each CD would have a unique key that identifies it to
> the server, and there will be only as many CDs as there are registered
> voters. But, furthermore, how does the voter know now that the election
> commission worker isn't giving himm or her a fake paper ballot, or even
> counting that ballot rather then just shredding it as soon as the voter
> leaves.
>
>>
>> Certificates include certain identity features, including
>> city of issuance and a parent. This might be construed
>> as a partial solution -- fictitious names are easily
>> registered if the process is not careful.
>>
>>>
>>> 2.) How does the voter know that the program at the other end is
>>> fraud proof. It could easily count your vote and put it in the wrong
>>> column, but return you the vote as you made it. All the problems
>>> associated with electronic voting machines in a polling place still
>>> exist, and you have added a few more.
>
> There is no full proof system, the problem you are describing are as
> possible with paper systems as they are with electronic systems.
>
>>
>> Certificates will not address this problem. I'll admit
>> I see no elegant method by which one can verify that what
>> the tally box counts is what the voter put in. Best I can
>> do is to have Firefox locally hash the vote (this can
>> be done in Javascript) and then bundle the hash along
>> with the vote, digitally encrypt it with the temporary
>> certificate's private key, then send the encrypted packet
>> to the voting box. Ideally, one would send a thumbprint
>> as well, though there are some issues if one tries to look
>> up said thumbprint and find the voter's identity; the vote
>> should be verifiably from a citizen, but private. Of course
>> thumbprints are a hardware problem...
>>
>> Any tampering with the vote values would invalidate the
>> hash. This might be overkill (signing it is a hash anyway).
>>
>> Of course the tally box might have its own ideas on the
>> matter anyway. "Oh, he voted for Smith. I'll count it
>> for Jones instead". Fortunately, gimmicked tally boxes
>> are replaceable if someone asks the right questions (and
>> can detect the tampering somehow; one might sample the
>> vote for checking purposes during the voting interval).
>>
>>>
>>> 3.) What does the voter do when the bad guy uses his Credit Card ID
>>> and so when the good guy tries to vote, the central machine rejects
>>> his vote because it was already used? How does he prove that someone
>>> else hijacked his vote?
>
> What happens in Chicago when you go up to your district to vote but for
> what ever reason they have you down as already voted? Fraud will always be
> part of the system. However, think about it this way, if we use a 2048 bit
> key to identify the valid voters, and we have, at the very most, 200
> million voting (more like 100 actually) the possibility of the "bad guy"
> finding even one correct key is 1 in 1.6E608. Yes that's 1 to 16 with 607
> zeros after it. If you limit a connection try's to one per IP per min there
> is no way any one will be able to guess the correct key.
>
>>
>> Certificates can't really address this problem either.
>> Related issues include "pet/dead guy" voting, ballot
>> box stuffing, and throwing out valid votes -- an extreme
>> case is to throw out every vote for a Democrat, or just
>> a percentage thereof, in certain assembly districts.
>>
>> Not that paper ballots can do much here, either, although
>> it might fix the "pet vote" problem -- can Fido hold a pen?
>> But boxes filled with ballots are "lost" easily enough, even
>> in a paper world.
>>
>> E-voting just make "losing" ballots easier and less obvious.
>>
>
> Here is the way voting works in the City of Chicago:
>
> 1. You register at the voting place and are given a big, placemat looking
> thing and a marker.
>
> 2. You mark the names you are voting for and give that placemat to an
> election admin who then places this exceedingly large paper into a large
> scanner and digitizes it.
>
> 3. The results are stored on a compact flash card, yes, a compact flash
> card!

In our county, one is required to sign a registrar --
preprinted, and based on voter registration rolls.
Our names are listed by address and by name. (I don't
remember whether one is required to show ID or not.
A provisional vote may be possible as well.) One is then
issued a small card -- presumably identical, or similar,
to your "compact flash card" -- which is inserted into a
voting machine (Sequoia, in our case). The machine wakes
up, allows the user to vote (it's touchscreen), eventually
shows a big yellow button on screen "CAST BALLOT", the
user presses it, and the card ejects. One then gives the
card back to an election worker, who sticks it in a funny
little box with a keypad -- the tally box, presumably --
then puts the card back into a pool of such cards, ready
to be reused.

There is a rather useless (for later audit purposes; it's
OK as far as the individual voting goes) printout option,
and I have no idea how Sequoia transmits its vote from the
precinct server upward. It is possible Sequoia also uses
the pager network -- which is OK, as long as the packets
are sufficiently well encrypted. (After all, even a
line network can be gimmicked, somewhere out of sight.)

An alternative, which many people exercise, is an absentee
ballot filled out at the polling place -- or at some
completely different place and mail in. The ballot in this
case is processed by some sort of mark-sense machine later
on; I don't know the details but to indicate a vote one
can draw a dark-colored line between two indicated points.
(Presumably this is slightly easier to process than the
traditional "fill-in-the-bubble".)

>
> 4. Once the card is full they take it out of the scanner and place it into
> a small transmitter box which uses the pager network, yes, I am not joking,
> a pager network, to send the results to the central computer.
>
> Now, you tell me the system I proposed isn't safer! I think there is
> absolutely an easy way to do this, there just is. I agree that the system
> should be centralized as well as decentralized, and should contain safety
> checks. But we really need to get away from a paper system.

Well, if you can guarantee that:

[1] a user casting his ballot will be accurately counted
exactly once,

[2] a user casting his ballot will be able to check his ballot,

[3] a user casting his ballot is at the right precinct,

[4] a user casting his ballot is actually alive and
the right user (an issue for absentee voting),

[5] a vote worker can audit to ensure every user's vote
is accurately transmitted and counted now and later,

[6] a user is not explicitly identified by his vote (such
might be used later by the winning party for blackmail
purposes, in an uncontrolled situation -- fortunately
that's quite illegal in the US )

[7] a non-enfranchized vote ballot (in the US, a non-citizen)
is rejected (or not entered) into the vote,

then maybe one might consider a paperless option. Best I
can do is to identify everyone via a master fingerprint
database, and that of course runs afoul of requirement #6.

(I'll admit to some curiosity as to how San Francisco
enfranchises its homeless citizens -- presumably there
are a few. I don't know how much of a problem that is in
Santa Clara county, though we have a few here as well.
Best I can do is have them give a homeless shelter address
on the registration form.)

>
> - Bogdan
>


--
#191, ewill3.RemoveThis@earthlink.net
"640K ought to be enough for anybody."
- allegedly said by Bill Gates, 1981, but somebody had to make this up!

--
Posted via a free Usenet account from http://www.teranews.com

Peter Köhlmann wrote:
>
> Nedd Ludd wrote:
>
> > "Christopher Hunter" <chrisehunter.TakeThisOut@NOSPAMblueyonder.co.uk> wrote in
> > message news:sWumi.27160$jY5.10338@fe1.news.blueyonder.co.uk...
> > : Hadron wrote:
> > :
> > : > Here's another one : could someone compile their own kernel in Linux
> > : > and do it even easier? Answer: yes.
> > :
> > : Yes, but the code would be open to examination by all...
> > :
> > : C.
> >
> > You'd still don't know if the code being examined is the code that is
> > loaded on the system.
>
> Simple. Compile it yourself. Compare the resultant binaries
> If it is the same source with the same compiler, the result ha to be the
> same. If not, you get easy to follow pointers where it differs

You actually do what they do for things like avionics s/w. You throw
away the binary, inspect the sources (including the makefiles) and place
the entire build, test and install process under some sort of
configuration control process. Once the binaries are installed and
before the machines are released 'into the wild', you can make a
checksum of each object, sign it with a suitable cipher/signature system
and make that available for audits.

--
Paul Hovnanian mailto:Paul@Hovnanian.com
------------------------------------------------------------------
Any sufficiently advanced technology is indistinguishable from a rigged
demo.