blockchain voting?

https://pdfaiw.uspto.gov/.aiw?docid=20200258338&PageNum=32&IDKey=7A4F4EA40D1F&HomeUrl=http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1%2526Sect2=HITOFF%2526d=PG01%2526p=1%2526u=/netahtml/PTO/srchnum.html%2526r=1%2526f=G%2526l=50%2526s1=20200258338.PGNR.%2526OS=%2526RS=

This sounds a little too clever to come from the USPS, but I like it... Many won't.

Won't come in time for this years election, like the sundry other proposed changes.

JR

I have an idea about electronic voting that goes like this:

When you vote you get a little ticket with a very long random number printed on it. If you vote by mail, the number is already listed on the ballot that you get by mail. The number does not indicate anything about the voter or votes cast. It's just a completely random ID like a UUID. After the election is declared, anyone can download the complete list of votes for your county. Each entry the long random number followed by the corresponding vote information. Voters can search for their long random number and see if it matches what they recall voting for and they can tally the votes to see that it matches the reported result for that county [1]. If large numbers of voters report inconsistencies, that would indicate that an interloper changed voting data. It's a sort of distributed checksum. The results are verifiable independent of anything that happens between the moment you voted and after downloading the complete list. The list is shared by all voters so it cannot be generated to specific individuals. It would not detect the injection of small numbers of fabricated votes however.

[1] In practice, trusted entities like news organizations or voter rights groups would verify the tally and provide a simple interface for each voter to search for their vote information without downloading a many GiB file and then trying to figure out how to search it.

squarewave said:

I have an idea about electronic voting that goes like this:

When you vote you get a little ticket with a very long random number printed on it. If you vote by mail, the number is already listed on the ballot that you get by mail. The number does not indicate anything about the voter or votes cast. It's just a completely random ID like a UUID. After the election is declared, anyone can download the complete list of votes for your county. Each entry the long random number followed by the corresponding vote information. Voters can search for their long random number and see if it matches what they recall voting for and they can tally the votes to see that it matches the reported result for that county [1]. If large numbers of voters report inconsistencies, that would indicate that an interloper changed voting data. It's a sort of distributed checksum. The results are verifiable independent of anything that happens between the moment you voted and after downloading the complete list. The list is shared by all voters so it cannot be generated to specific individuals. It would not detect the injection of small numbers of fabricated votes however.

[1] In practice, trusted entities like news organizations or voter rights groups would verify the tally and provide a simple interface for each voter to search for their vote information without downloading a many GiB file and then trying to figure out how to search it.

Click to expand...

I guess this comes down to who "don't" you trust?

I proposed before that we allow all walk in voters who claim to be citizens to vote, BUT they must provide a finger print, and get their picture taken. If the election is not contested these finger prints and photos go into the bit bucket. If the election needs to be vetted their bonafides must be verified. If they vote more than once, they can be caught with computer database searches

Of course if you don't trust your own government to honestly count the votes we have a larger problem. I recall last election there were some suspicious districts reporting not even one vote for a major party's candidate.  :  My neighbors will vote pretty consistently the same way but not 100%.

JR

PS: Blockchain government ID sounds a little like old science fiction where babies get issued serial numbers at birth (I don't remember which SciFi book did that). I think they took the babies footprint... wait maybe that wasn't fiction.  ;D

electronic voting that goes like this:

Click to expand...

Hashtag keys as a stopgap would be nice, square if they can't be tampered with (use a blockchain).

Also got to get past  'Digital voting machines can be hacked' vs 'decentralized ledgers will faithfully cast your vote'.

boji said:

Hashtag keys as a stopgap would be nice, square if they can't be tampered with (use a blockchain).

Click to expand...

The random number would not be a hash. A hash is generated from some data such that if you run the hash algorithm again with the same data you get the same hash. The random number I speak of would be just that - a completely random number. It's just a key to lookup your voting record but large and random enough that no one can trace it to the voter or discern any information about the corresponding vote information. There's nothing to tamper with.

BlockChain has been floated as possibility for secure voting for years. Almost everyone who actually works in the area thinks it's a bad idea, enough that it was worth an XKCD comic:



Tom Scott had a great video on the issues with balancing anonymity and security in voting:
https://www.youtube.com/watch?v=LkH2r-sNjQs

I know you don't usually click on videos, but it's minimally political (he's British, too, so it's not going to have much to do with American politics) and he and the people he consults for technical information on his channel do understand the technology very well.

I'm not suggesting that it's impossible to secure online voting but I am skeptical that the convenience for a relatively small number of people outweighs the risks of everyone's vote being invalidated. I do think it would be cheaper, but then again, so would universal mail-in voting. (Our primary ballots, which I can't vote in, were auto mailed, because the state recognized the pandemic risks. Our general ballots are not being automatically mailed, as they have been in several other states for all elections in recent years, and have to be explicitly requested, for whatever reason.)

Even without blockchain, all of the necessary technological pieces for electronic voting are already in place (a combination of mail-in registration where a passphrase is supplied, coupled with public key cryptography for the actual exchange of votes).  Votes would only be accepted if all of the parameters match:  vote came from device's private key (digital signature), matches the hash of the passphrase that was supplied by mail, etc.

The common block that is thrown up is 100% absolute anonymity, which isn't even guaranteed today with a paper ballot that contains a signature.  Another one is distributed attacks on voting infrastructure, which is already handled today by having distributed server endpoints that can be redirected.

The random number would not be a hash.

Click to expand...

I guess we're disagreeing over terminology. I thought the fact that hashes could be reversed is what made the need for random  (pseudo-random?) hashing which Ruby and Perl adopted.  I defer to your coding experience, however.

boji said:

I guess we're disagreeing over terminology. I thought the fact that hashes could be reversed is what made the need for random  (pseudo-random?) hashing which Ruby and Perl adopted.  I defer to your coding experience, however.

Click to expand...

One way hashes can not be reversed.  They are not encryption algorithms. That's the point. There are an infinite number of inputs that output the same hash. Therein lies the security.

But at the very least I would think you would want very long, random UNIQUE numbers so there are no collisions in that field AT ALL.

Ricardus said:

One way hashes can not be reversed.  They are not encryption algorithms. That's the point. There are an infinite number of inputs that output the same hash. Therein lies the security.

But at the very least I would think you would want very long, random UNIQUE numbers so there are no collisions in that field AT ALL.

Click to expand...

Hashes can have collisions which is to say there can be different inputs that produce the same hash. But again, my scheme does NOT use hashes. That's just some confusion on boji's part.

My scheme uses plain o'l random numbers. Random numbers can also have collisions of course but if the bit width is large enough, collisions become unlikely to the point of no concern. A UUID for example has 128 bits. Just to give you an idea of how bit 128bits is, consider this python output:

>>> 0xffffffffffffffffffffffffffffffff
340282366920938463463374607431768211455L

That's pretty big. If everyone in a world with 10 billion people voted, the chances of a collision would be 1 in:

>>> 0xffffffffffffffffffffffffffffffff / 10000000000
34028236692093846346337460743L

So a UUID could be printed on each ballot would a little cut-away corner that has the same exact number on it. You cut that out or take a picture with your phone. Or maybe it's a QR codes (one of those square barcodes).

A UUID looks like this:

>>> import uuid
>>> print(uuid.uuid1())
08e28d3e-e482-11ea-921e-18dbf21e410a

After the election, you punch in this number somewhere and it looks up your vote in the DVD of votes released to the public. This does not rely on any central authority and can be independently verified by any individual.

squarewave said:

After the election, you punch in this number somewhere and it looks up your vote in the DVD of votes released to the public. This does not rely on any central authority and can be independently verified by any individual.

Click to expand...

If someone obtains my UUID, they can look up my vote.

midwayfair said:

If someone obtains my UUID, they can look up my vote.

Click to expand...

But how would they get it? It's a random number. That's the point. So unless you give it to someone, there's no way for them to get it. That's like saying, if someone obtains my ballot, they can see my vote.

Mr Nobody: " Hey darlin'what's your uuid again? Nevermind, i'll just take your phone and take a look..."

Later:  "How could you vote for these bloody socialists democrats! Come here and get your spankin'!"

Sorry about the caricature. Just wanted to point that most of the time, stranger aren't interseted.in your votes, but the person closest to you might. And not always with the best intentions. Voting should be left to anonymous paper. At least in my opinion .

Cheers,

Thomas

squarewave said:

Hashes can have collisions which is to say there can be different inputs that produce the same hash.

Click to expand...

Yes. I said that. In fact there are an infinite number of inputs that produce the same hash.

totoxraymond said:

Mr Nobody: " Hey darlin'what's your uuid again? Nevermind, i'll just take your phone and take a look..."

Later:  "How could you vote for these bloody socialists democrats! Come here and get your spankin'!"

Sorry about the caricature. Just wanted to point that most of the time, stranger aren't interseted.in your votes, but the person closest to you might. And not always with the best intentions. Voting should be left to anonymous paper. At least in my opinion .

Click to expand...

True. Someone could demand that they see your UUID to confirm that you voted a certain way. That is a wrinkle in the scheme. But they could do that now with a mail in ballot and look over your shoulder while you fill it out. Using the UUID scheme they could go to in-person voting and then "forget" to get the UUID. It's not a show-stopper of a problem.

Ricardus said:

Yes. I said that. In fact there are an infinite number of inputs that produce the same hash.

Click to expand...

Huh? A good hash algorithm should have no collisions. In practice there can be some but I don't understand how there could be in "infinite" number of inputs that produce the same hash. Can you provide a reference?

squarewave said:

But how would they get it?

Click to expand...

Because I had to keep it, to verify my vote.

With in-person or mail-in voting, the knowledge of who I voted for exists only in my skull. You can't necessarily stop someone from physically looking over your shoulder while you fill out the ballot, but once your vote has been cast you are the sole possessor of that knowledge. There is no record of who you cast your vote for that anyone can access. Your system requires such a system. You said yourself that a benefit of your system is that it can be verified by any individual.

But regardless of the anonymity holes in your scheme, I'm convinced that the mechanics of allowing people to safely submit their vote is beside the point, we've had over a hundred years of sufficiently powerful mathematical solutions for that, and you certainly aren't the first person to suggest unique ids. The biggest problem is that electronic voting produces a single breakpoint instead of thousands or millions of individual breakpoints with physical voting, and you can't fix that by making the single breakpoint more secure.

>A good hash algorithm should have no collisions. In practice there can be some but I don't understand how there could be in "infinite" number of inputs that produce the same hash.

Pigeonhole principle, pick your favorite hash and calculate the holes and number of pigeons. But they're speaking theoretically, because if you're feeding a computer input you don't have an infinite number of inputs to generate infinite collisions. I know there are a huge number of possible collisions for SHA (like "some large exponent more"). I'm not a crypto person, though, so I'd hesitate to post a source beyond basically any intro textbook. EDIT: Perfect hashes exist, there's a wiki page for them, https://en.wikipedia.org/wiki/Perfect_hash_function. I don't know any that are in actual use.

midwayfair said:

Because I had to keep it, to verify my vote.

Click to expand...

But you don't have to keep it. Not everyone has to verify their vote to detect an irregularity. In practice it would be a very small number of people.

midwayfair said:

>A good hash algorithm should have no collisions. In practice there can be some but I don't understand how there could be in "infinite" number of inputs that produce the same hash.
Pigeonhole principle, pick your favorite hash and calculate the holes and number of pigeons. But they're speaking theoretically, because if you're feeding a computer input you don't have an infinite number of inputs to generate infinite collisions.

Click to expand...

I see. So if you just keep feeding in data changing one bit at a time until you land on a specific value, then you could keep generating different inputs and landing on one value indefinitely. Fortunately that's just not how hashing is used such that it's not a practical matter. Same thing with how randomly generated UUIDs are not guaranteed to be unique but the chances of a collision are just so ridiculously small it doesn't matter.

squarewave said:

I see. So if you just keep feeding in data changing one bit at a time until you land on a specific value, then you could keep generating different inputs and landing on one value indefinitely.

Click to expand...

Uhhh ... not unless it's a terrible hash. Hashes are designed to be "hard" to find collisions, so you can't write a generator for collisions simply by finding a collision. I said that the other poster was only speaking theoretically when they said there were an infinite number of collisions. An infinite domain mapped to a finite range means (mathematically) that there are infinite number of inputs that produce the same output. (The proof is fairly easy.) There are no infinite domains for functions that are evaluated on real-world computers. I don't know enough about perfect hashes to tell you why they aren't used but I suspect the reason is related to timely evaluation.

I looked it up just now and SHA-512 is limited to 2^128 input digits, producing 2^2^128 possible inputs for only 2^512 outputs. There are a gigantic number of collisions for such a widely used algorithm.

Again, though, all of this is beside the point, I'm not aware of any serious argument against electronic voting whose crux is the ability to encrypt a person's vote. I'd highly recommend watching the Tom Scott video I linked to if you haven't already. He does a good job of explaining the important arguments against it.

Not everyone has to verify their vote to detect an irregularity.  In practice it would be a very small number of people.

Click to expand...

Why?

Ask yourself if you're assuming things have gone right or things have gone wrong.

midwayfair said:

Not everyone has to verify their vote to detect an irregularity.  In practice it would be a very small number of people.

Click to expand...

Why?

Ask yourself if you're assuming things have gone right or things have gone wrong.

Click to expand...

I think we're talking around each other a little bit. The topic of hashes was not in relation to voting at all. And my scheme is not a method of voting. My scheme is simply a sort of distributed checksum where each person that verifies there vote is one bit in the checksum. In a perfect world, it would only take one bit (person) to detect an error (vote tampering). In practice people being people will misremember or make a mistake when voting or lie or whatever. But if 10,000 people say "whoa, the info associated with my UUID doesn't match", then you know there's some kind of problem. 10,000 people would only be ~0.01% of the votes. So it's not a voting scheme, it's a very simple but robust stop-gap measure to detect a failure. That is all.