Punchscan and Scantegrity both fulfill your requirements. The key is that each ballot is printed with a unique correspondence between the symbol marked and the candidate chosen, and the checksums for that mapping (and the ballot serial number) are published before any of the ballots are marked.

I have written up a description of how punchscan works here, if you are interested: http://seedsofgenerality.blogspot.com/

The only piece of cryptography you need to understand is what a hash function is, and how hard it is to reverse a hash. Everything else is about as hard to understand as, say, the quicksort algorithm is the first time you see it.

Now, that means that most people won't bother learning it in detail, but that doesn't mean the average voter should not trust such a system anymore than the fact that most people who use ssh don't understand the RSA algorithm in any depth should mean that they should not have any confidence in ssh.

It only takes a small minority of interested technical people to vet such a system.

The minute the locked tubs leave your sight, you are relying on an army of other people to make sure they aren't unlocked while you aren't looking and the ballots switched, so no, you can't verify the paper trail when you vote.

With an end-to-end verifiable paper ballot protocol like punchscan and integrity, however, you (individually, without relying on an army of eyeballs to preserve chain-of-custody) can verify that the vote count is accurate because throughout the election (from the printing of the ballots to the scanning of the ballots to the final vote tallies) enough information is made public about the ballots and how they are marked that it is impossible for the election authority to steal more than a few votes without being caught. The probability of one vote being stolen without being detected is 1/2, 2 votes 1/4, 3 votes 1/8, and so on. At the same time, the information revealed is not enough to determine how any individual person voted, so anonymity is preserved.

At the heart of such protocols is the concept of a cryptographic commitment. Suppose you and I want to flip a coin fairly via an email exchange. If we were face-to-face, you would call heads or tails, I would then flip the coin, and we would see who won the toss.

How do you prevent cheating in a similar exchange over email?

The key is that I flip the coin first, generate a commitment and email it to you, then you call heads or tails, and then I reveal the key that unlocks the commitment, whereupon we both know who won the toss.

How do I generate a commitment that I can't modify later? Suppose I flip the coin and it comes up heads. I then generate a 128-bit random number, concatenate "heads" to it, and calculate the SHA256 hash of that string. I send you the hash. You call heads or tails. I then send you the 128 bit random number I used, and tell you it was heads. To check me, you take the random number, concatenate heads to it, and calculate the SHA256 hash. If it matches what I originally sent you, then you know I didn't cheat. If it doesn't, then you know I tried to pull a fast one.

How do you build a paper ballot election protocol out of that? That's a longer story. If you are interested, I wrote up my explanation of it here: http://seedsofgenerality.blogspot.com/2010/09/secure-voting-protocols.html

Now I grant you that not very many people will take the time to understand how a complicated protocol like that works. But it would only take a small minority of people to vet such a scheme so that the wider population would have confidence in it. Just as it only takes a small minority of people to understand how RSA works for the rest of us to use ssh with confidence.

What happens when the only provider in your area is one who prioritizes Torrent Traffic over Netflix and Youtube?

And how did your one provider manage to roll out access to your area when no other company could? By using government right-of-way and subsidy.

I think the basis for forcing a monopoly provider to route packets neutrally should be that they accepted right-of-way and subsidies, not just that they are operating a network.

I don't think the phrase 'net-neutrality' captures that concept. It suggests that even if you run a private network that was built without subsidy, you are under some moral obligation to route packets without preference.

Unless I miss my guess, all the legistaion inspired by the phrase 'net-neutrality' will also miss that point, and instead establish the principle that if you operate a network, you can only use government approved routing algorithms. In other words, it will open private networks to arbitrary legistation.

I wonder if the internet as we know it could have grown so useful so fast had the government not been as hands-off as it had. I worry that once the hands-off approach is gone, its further development will greatly slow down, and that the slogan of net-neutrality is doing great damage to society's commitment to the hands-off concept.

However, I've found writing a proper test suite that deals with databases, network communication+++ and not just the application itself is pretty hard

Writing a comprehensive test suite that did all of that would be an enormous undertaking. Writing a single automated test dealing with network comm or with a database interaction, however, is not a huge task, although it does take more time than manually testing for the existence of some bug you are in the middle of fixing. If you only automate a small fraction of the bugs you manually test for, however, those automated tests will grow in their usefulness over time, as some of the bugs they test for will resurface in the future and be found immediately thanks to the test script. This usefulness can be observed by teammates and managers and inspire imitation. At developers meetings, the next time a bug resurfaces in one of your colleagues work, a manager might even ask "Wouldn't you have found that faster if you had written an automated test for it like Steve over there has been doing for his work? Maybe you should spend some time with Steve so he can show you how to write automated tests."

I had the same reaction. If the OP is a developer working on this code, and has to fix some of these bugs when they come up, then he should start writing scripts that detect existence of the bug in the app, then fix the bug like he normally would. The next time one of his colleagues reintroduces the bug, his test script will catch it and he can point it out.

Bugs that go away by themselves, come back by themselves. Automated unit tests let you know exactly when they come back, and why (as long as you run them often, then not much will have changed in the code since the last time the test passed, letting you know that something in the last small change provoked the bug).

You don't need to write a massive suite of tests to demonstrate the usefulness of automated testing. Automated testing pays off in small increments as well. If the OP starts writing automated tests for the work he is doing, then the success of those tests will speak for themselves.

I think the main reason so few developers write automated tests is that it is a non-trivial skill that takes practice and time to learn. So the first task is to get good at doing it yourself. Then you can lead by example.

I found a link to David Bismark's home page here. He is explaining how Pret a Voter works. This is related to the punchscan system, although it works by randomizing the order of the candidate list instead of introducing an indirection symbol like punchscan does.

Odd that the wired article would not give credit where it is due and mention Pret-a-Voter.

BTW, everyone, this is not an electronic voting system, even though it is uses computers if various ways, it is an optical scan paper ballot system.

This sounds a lot like the punchscan voting system. I am at work and not able to see the video right now, but I googled bismark and found this article, which has some details.

Punchscan and its variants do allow you to be able to prove to yourself (with a 50% probability) that your vote was counted as you intended. That might not sound like much comfort (only 50%?), but if the election authority tries to change 2 votes, their probability of getting away with it falls to 1/4, then to 1/8 with 3 votes, and so on. So stealing more than one or two votes becomes infesible pretty quickly.

However, I do believe that in all such schemes, the possibility of large scale vote buying becomes a real threat that has to be managed carefully, since the election authority has the keys that allows the all the ballots to be decoded. So if the Election Authority shares the keys with, say, the autoworkers union, or with GM, then those orgs would be in a position to decrypt the votes and thus coerce their voters. Of course, large scale intimidation of that type would be hard to hide from investigators. For this and other reasons, I think the threat of large scale vote buying is managable, and well worth the accuracy and accountability these systems provide.

The 2 key ideas that makes these schemes work are "cryptographic commitment" and the "cut and choose" protocol. If you are insterested, I've written up a detailed explanation of these concepts, and how punchscan like systems work, here.

I am with the I-don't-like-shiny-computers poster above as far as computer preferences go, but I have to hand it to you, that was a beautiful reply you penned.

The real question here is what are you interested in tinkering with. Some people like to tinker with computers and some people like to tinker with any of a myriad other things. Very few people like to tinker with more than a few things, though, and expect almost everything else they own to "just work".

I don't care how well written my furnace's user manual is, or how well designed the controls are, I haven't the slightest interest in learning its fundamentals. If it stops working, I call an HVAC guy to fix it.