There would be a digital paper trail.
for all practical intents and purposes even as metaphor this is an oxymoron. Punching literal holes in an 1950s era paper tape would be an ideal paper trail though, especially if it were pre-marked so the voter could see that their paper vote corresponds to what buttons they've punched.
notice I keep going back to low tech stuff. it's simpler and easier to concern.
And we don't have to secure every last aspect of it. From the side of the server we just need to ensure that it doesn't respond to anything except what it's supposed to, and in a secured physical environment. That is human manageable.
(1) has to be done by trusted and secure humans; this is very hard;
(2) locking down the server
completely except for a series of basic unidirectional commands "increment total
x by 1" (shielded behind cryptography), ideally; the server being
physically incapable of responding to
anything even on a hardware level except for acknowledgment (which could be segregated from the actual database so as to minimize the amount of leakage but more importantly the possibility of tampering) -- if this is to be feasible, it's all about the KISS principle.
but what exactly are we talking about at this stage? voting machines keeping their own tallies? a set of voting machines at a precinct that tallies at a server like we mention here? or remote network voting, which I would absolutely never consider to OK.
If you take away all the possible ways for arbitrary input to be processed in any unknown way, you take away that entire vector as a risk. And as I said, we don't have to make it impossible for one vote to be tampered with, just for it to be impossible to tamper with lots of them.
this needless to say is the essential. in this sort of unique system I actually think a small, bespoke system would be better than modern highly secured operating systems, because the task is very, very simple (there's only one "operation" the computer is asked by a client to do, essentially), and the larger the attack surface, the riskier a situation we are in.
thinking of a setup like the second one mentioned, imagine a wheel-and-hub system, voting machines: very stripped-down systems, running bespoke software running basically on bare metal, with no task other than to make vote selection. as needed you can put in a touch screen, audio output for the b/vi, etc. the only thing that this system is capable of doing is (a) taking the vote; (b) transmitting through a phyically unidirectional cable the vote; (c) printing on running paper tape the same vote; perhaps (d) offering some kind of other paper receipt for the user, cryptographically signed. authentication of voters and preventing of double-voters would still rely on physical security, because none of the public-key systems are really scalable unless you are willing to sacrifice anonymity in which case it becomes fairly trivial but you have also created a
de facto national ID card via the medium of the national voting PKI. So that's really it for the stripped-down machine. It also gets some kind of "ACK" from the hub, if it doesn't, raises the appropriate red flag for technical assistance.
the hub would also be a bespoke system: takes in unidirectional input, only valid instruction being 'increment column
N by 1,' this is done, and through a different, hardware-separated system that does not have physical level access to the database, sends the "ACK."
at the end, the paper tape is saved and sealed (which in and of itself is a big problem, there is a great chapter on this in Anderson's
Security Engineering, which has a lot to say on all these subjects), the computer is sealed, it burns the database to a CD, cryptographically signed, maybe with some kind of mechanism to reliably allow the private key in question to be used only once (practically impossible, but possible to make it
difficult to use twice); the public key being kept by the authority tabulating the votes
some sample of the paper tests are statistically tested against the computer results, if the index of suspicion of a discrepancy is low, then the precinct can report by digitally signed burned CD, and as long as all seems well, go ahead; if there's any problem, fall back on the physical recount and comparison to the computer; if all's well, for some length of time official takes office, everything keeps under lock and seal and then all destroyed when that interval expires, we don't want to keep it around forever because it's keeping it secure on and ongoing basis difficult and someone could attack it by altering the results
post facto and then making enough noise and examples of allegations of election fraud, and then fuck him over.
this is a back of a napkin idea of what I would do if I had to design electronic voting. with an extreme emphasis on absolute simplicity; the biggest problem in computer security these days IMO is that things are so complex that no individual really can understand all of them, and there is no possible reason why half of the things running in your computer needs to be. anyway I found this an interesting back of napkin exercise, it might even be fun to bring out some old hardware and create a toy implementation (yes I am that much of a geek that I will do stuff like this just for shits and giggles, see the extended and customized phonetic name-sorting and comparison script I wrote in
sed(1), I enjoy using time-tested tools

about two weeks ago just because I was working on yet another project that involved dealing with census data (
this is a tiny, although using a much smaller database (2
20 possible combinations, my current application has something more like 2
64 and can be extended arbitrarily and has some additional features for one-time authentication using a shared secret over a possibly unsecure channel, like starting an OTR conversation) and more trivial implementation, piece of it, it makes up a name, but i'm actually looking to apply it to certain computer security applications, basically as a way to encode bits in a way that is very easy for the human brain to remember, basically I'm working on a way to memorize use random 128/256-bit keys without having to deal with passphrases, which are problematic but I digress; if you like this stuff PM you I'd love to chat about it) and didn't want to deal with the 30 ways people spell "Caitlin," but I still think it's a bad idea, but I think that something along the lines of this would approach the margin of safety.