Anonymous wrote:
> Ed Gerck wrote:
> >Did any of you see this
> >http://www.votehere.net/content/Products.asp#InternetVotingSystems
> >
> >that proposes to authenticate the voter by asking for his/her/its SSN#?
>
> It looked like the idea for this part was to prevent double voting,
> plus make sure that only authorized people could vote. It wasn't
> necessarily SSN, it could be name/address/date of birth or whatever.
> Similar to what is done when you go and vote in person.
The disconnect here is that it does not make sure that only authorized *people*
can vote -- but that an authorized he/she/it can vote. Thus, I find that this is
not similar to when I go vote in *person*, when election officials will not allow
bots or dogs to vote ;-) Here, anything can get an authorization, not just anyone.
And, someone could easily have a directory of "voters" (real or made-up) and
automatically proceed to obtain authorization and vote with each one of these
"voters". There is nothing to prevent bulk voting commanded by one person.
> There was also this idea of what they earnestly called a VERN, Voter
> Encrypted Registration Number, which would be distributed in advance
> to people who were authorized to vote. You'd provide your VERN along
> with your authenticating info (DOB/SSN/whatever) to prove that you were
> authorized.
Again, one is mislead by the assumption that it would be distributed to people.
The VERN voting is similar to what we see in majordomo for example, when a nonce
is sent to a *virtual* subscriber and must be mailed back to confirm list subscription,
from the same requesting email address -- ie, similar to casting a vote in VoteHere.
But, bots can also subscribe using majordomo. So, since the VERN is requested by
and provided along with virtual info, there is no verification of the voter's identity
even as a person (ie, not a bot) neither when the VERN is sent to the presumed
voter nor when the VERN is used.
> Any voting system ultimately relies on real world proof like this.
But, there is no real-world proof here, everything happens entirely in the virtual
world.
> The real point of the protocol is to keep people from finding out HOW
> each person voted, while assuring that the vote count is correct. There
> has been a lot of work on crypto protocols for secure voting and this
> appears to be what they have implemented.
I see no protocol, I see a table of names and nonces. Each one can see
their name, but no one can verify if two or more names may (wrongly)
correspond to one person or, if a nonce listed is the correct one for a name.
So, "One Person, One Vote" as declared by VoteHere is more likely
"One Name, One Vote".
And, what is to prevent populating the table with names/nonces? If absentee
ratio is large, there is considerable room to populate the table and still have less
than a given number of voters (assuming that the total number of voters is known,
which is not true for USENET or in the Internet -- we don't even know how
many hosts the Internet has, let alone users, and known host statistics are
only relative to in-addr.arpa registration).
> This looks like a good system although it would be nice to see more
> details. It certainly sounds better than alternatives.
What alternatives do you mean?
> With current
> Usenet votes everyone gets to see how you voted. With this VoteHere
> system you could be assured that your vote was correct (because it would
> match the encryption you sent in),
But, you could not be sure whether any other vote is correct.
> nobody else could see how you voted,
This is not what the site says -- it says: "..decrypted by a simultaneous coordination
of election officials and observers, to obtain and/or audit the election results.",
which
means that such group can decrypt the tally result but does not mean that it cannot
decrypt *one* entry from the name/nonce table. Since the table is public, if voting
nonces can be decrypted one by one then any vote can be identified.
To avoid this, the encryption method used to create the nonces would have to be
one-way with trapdoor for the tally but one-way for any nonce. Let us suppose
that this is true. But, since a tally is the sum of two or more nonces, if I have
*one* known vote (my own) then I can know any other vote in a sum of two nonces.
And, knowing two votes I can know the sum of three votes, and so on. I can
continue the process and eventually learn how everyone voted, starting only from my
own vote -- even under the assumption that the encryption method used to create the
nonces is one-way with trapdoor for the tally but one-way for any nonce.
> and yet you could be sure that the vote total was correct (by running the
> sum operation on the encrypted data, and verifying that the decryption
> of this is the claimed sum).
Given the information in the site, I cannot see how you deducted this. But,
even if what you say is true and I missed it elsewhere, then the argument above
shows that knowing only my vote I could know any vote cast by any other name.
> It certainly doesn't look like snake oil, rather an attempt to bring
> these theoretical crypto protocols into the real world.
Snake-oil is when something claims to do a lot but actually does nothing
it claims. The VoteHere system claims that it affords voter's privacy,
auditing by anyone and non-repudiation. I cannot see these claims in the
system. Just claiming non-repudiation ("prevents voters from later denying
that they cast a ballot") is enough to justify suspicion,as recent PKIX WG
discussions showed.
> It's always
> tough to join theory and practice and so there may be some rough edges
> at the interface. But it looks like the idea has significant potential.
> Otherwise we're going to get "just trust us" electronic voting like some
> areas are using already.
The "just trust us" is a good remark -- "trust me" is a well-known lie, because
if there would be reasons to trust ... then they would have been named ;-)
However, VoteHere just trusts that the voter exists while the voter just trusts
that all other voters are legitimate. At the end, I see nothing but bot against bot ;-)
Cheers,
Ed Gerck
