if you believe you can write robust C programs, you shouldn't use Perl programs.

It's not that it's impossible to write robust C programs, but that it's difficult. Just by using Perl (or another higher-level language), you eliminate an entire class of possible attacks: buffer overflows.

Sidestepping the fact that 99% of the voting population won't have the skills to understand the program . . .

I don't have the mathmatical background to anaylize the security of any given cryptographic algorithm. I still want the algorithms to be made public as a way of keeping the orginaters honest.

. . . don't have the garantee that the program you have been given is the actual program that's running the voting machines.

And that's the ultimate problem.

There's no way to know that if you press the button for candidate A your vote is actually counted for candidate A, and only once.

There are many cryptographic voting systems, where the voter can verify that their vote went to the choice they want. However, most of them rely on a central, trusted authority. The decentralized ones I've seen are unscalable to more than a handful of people.

> Well, if you believe you can write robust C programs

Just to be clear, that was a quote from a "news" reporter, not a personal opinion. But, for the record, you can write robust C programs.

> you shouldn't use Perl programs. After all, a Perl program can only be stable if perl is stable.

By that logic, you shouldn't use Perl for anything. Yes, you can write stable programs in C, but C takes more work to maintain and keep secure than Perl does.

> And perl is written in C.

Yes, I know. And that means that Larry Wall et al have already taken care of many potential issues and maintainance difficulties, leaving me with a language that is easier to maintain and secure. As I've said in another thread, nowhere did I try to start a "Perl is better than C" war. They're tools, and they have their uses.

Hearing the reporter mention voting machines written in "robust C" merely got me thinking about what could be done with some robust Perl. And, after all, this is PerlMonks, and suggesting that we all work to write a voting machine in C would be somewhat daft.

> And don't think that making the software available gives you any security at all. Sidestepping the fact that 99% of the voting population won't have the skills to understand the program, do don't have the garantee that the program you have been given is the actual program that's running the voting machines - or the tally machines.

Open code in voting machines isn't intended for review of 99% of the population. But, it would be nice if Universities and other non-partisan non-commercial organizations could review the code. More eyes tend to find more problems. Also, the fact that someone concerned about the security of the machine could analyze the code is, IMO, a good thing.

As far as guarantees of code version, at some point you have to trust election officials, who should be verifying the code signatures and MD5 sums on election-day startup. We might need to provide them with the training, but doing that isn't particularly hard, once you've been shown how.

> There's no way to know that if you press the button for candidate A your vote is actually counted for candidate A, and only once.

Sure there is. Visible paper reciepts:

• Touch your selection
• Confirm your list of votes
• A punched or printed ballot is popped into an enclosed, transparent box, clearly showing the choices you confirmed.
• Choose "cast these votes" or "destroy card and restart"
• If cast, the ballot card drops into a hopper.
• If "destroyed", the ballot card is stamped with red ink and shredded in view of the voter.