Lately? The Canadian govt is always trying to catch up the the US govt's bad habits. Tis always been true, and is true regardless of which political party is winning on either side of the border.

There are practical problems with the scheme. But note that they don't need to keep track of which key goes with who, because they can calculate the hash for every possible vote for each key, and just check how many matches there are. No need to know which key to use on which hash. A good way to do it might be to individually seal the copies of secret keys that go to voters, before randomly distributing them. You could even have the randomization done by an organization that's independent of the organization that generated the keys. Of course, unless their randomization is done within the plain sight of voters, it would have to be taken on some level of trust that it was done randomly. If it requires being done within the plain sight of voters, well might as well do paper voting anyway. Still though, if you could trust they were being randomly distributed, it could be fine.

Strong cryptographic hashes couldn't realistically be reversed, and believe it or not, rather advanced ones can be done on paper. Many strong cryptographic hashes can be done on not-hugely-daunting amounts of paper, provided the input data to the hash is not too huge, and it's not like it's a large file being hashed. So long as a proper cryptographic hash is in use, it *cannot* be reversed without doing a blind search of all possible inputs to the hash. Make the number of bits of inputs large and random enough (i.e. good "secret keys" of say... 256 bits or so), and that cannot be done within the lifetime of civilization. So... no... attackers reversing hashes is not feasible if the system is done right. Doing it right does make what voters would have to do on paper a little tedious, but manageable.

And that last part? That's what the public record aspect prevents. Even if there was a MITM-ish attack, the user can verify via other computers/connections at other times, whether their hash got inserted into the public record correctly. Ideally, this public record would be highly distributed. It seems highly unlikely a MITM could prevent a user who cares from finding out their vote was in the public record in the long run.


In any case, none of this matters, because even though cryptographic hashes and public records could hypothetically solve many issues and make a technically robust system, they don't solve the "talking about the guy with the gun pointing at his head telling him how to vote" type issue.

Actually... voting is much simpler than bank transactions in that the number of choices is small, and because of that, there *is* a way. It could even be made so that votes are 100% verifiable! Well, so long as the government can securely get information to the citizen via non-electronic means anyway.

What you do, is have the government send all citizens a "secret key" via non-electronic means, and keep a paper record of which "secret key" corresponds to which citizens. Also, when the "secret key" is sent to citizens, include instructions on how the citizen can do a hash of their vote and the secret key, on PAPER!

The citizen then anonymously submits their hash, to a public record. Because it's a hash, their ballot is still secret except to the organization that has kept paper records of the "secret keys". Because the hash is in the public, their vote *cannot* be silently tampered with prior to counting (It can be tampered with during counting, but so can paper votes). Then to count the votes, the organization holding the secret keys computes all the possible hashes for each citizen and counts the matches up, ideally using a single-purpose tabulation system based on hard-wired hash-and-count logic rather than a programmable device (Since the hash is being done by citizens on paper, it can't be *that* hard to implement the hash with hard-wired logic).

Under this system, because the computers doing the communication are not treated as a trusted devices (hashes done on paper), there really isn't any way this could be compromised any easier than paper voting.

That said, there are three problems with the no-worse-than-paper-votes system I propose:
1) People would whine about having to do *math* on paper to vote
2) The government still needs to somehow get a "secret key" to people via non-electronic and secure means. That's hard.
3) No government would actually bother to implement a secure system, when they can just pay a contractor for an insecure system which the contractor claims is secure.

Rsync would do this very nicely, except that it requires manual initiation. So what you do is hack up a quick python/perl/etc script to do the following:
1) When it regains connection with the server, run a full rsync
2) When inotify tells the script that a file has changed, rsync that one file. Perhaps buffer changes for set amounts of time so fewer rsyncs need to be run

This should be possible to accomplish in less than a day of hacking in a language of one's choice.