Re: Re: electronically detecting tampering

From: Clay Lenhart <clay_at_lenharts_dot_net>
Date: Wed Nov 26 2003 - 13:54:43 CST

> All this talk of complex crypto I think is just using the wrong hammer on the problem. I'm not against simple cryto like signed md5 hashes and such but I'm afraid we're obfuscating the true issues by worrying about key-control.

I'm glad you find signed md5 hashes simple. :) Signing with public/private key pairs is really a small next step. Instead of having one key for encryption, there are two, one public and the other is private. When one key encrypts, the other key decrypts. Encrypting with the public key can only be decrypted with the private key, and encrypting with the private key can only be decrypted with the public key. Signing is taking a hash of the message and encrypt it with the private key. To check a signature, you perform the same hash function on the message and decrypt the signature (ie you decrypt the hash). You verify that the two hashes are the same.

The advantage with public/private keys is that you can verify a message's signature without access to the private key.

> As I see it the number one issue is transparency. this means three things to me besides voter-verifiable hard copy ballots.
> 1) open source
> 2) A method to know what binary code the machine is actually running
> 3) human observable chain of custody of all modification to and output from the machine.

There is no doubt that transparency is very important, but it addresses a different problem. I see transparency as a "Does the code perform the voters' intentions" issue and signing as a "Was the data modified in route to the counting authority" issue.

> Data going out of the machine must also be observable so again it gets written to an unerasable media like a cd-rom which can be copied (on dumb non-computerized machines) at will in the presence of election officials. The disks could even be physically signed by all election judges with a pen if desired.

They could sign (with a pen) their own CDs and throw your CD away. (delete and insert ballots).

> suppose that every time a machine printed out a voter-verifable ballot it also added a bar-code then contained the content of, say, some ten previous ballot chosen at random. If some evil doer were to try to dump some of the ballots in the dumpster you could still recover the entire record from the remaider. The missing ballots would be very obvious. Moreover any attempt to add additional ballots would be foiled unless these were added at the end. And as long as one can keep track of the total number of true ballots one can weed out ones added at the end.

Creating a web of interlocking ballots is a novel idea. This could prevent deleted ballots. It also could show the order in which the ballots were done, which may be used to identify voters. This idea is worth bouncing around some more.

> If you want to argue this point I'll trump the issue by saying that there is always the possibility someone could place an easter egg in the software used to compile the source that would inject an evil program into the binary. adding yet another layer to this dicsussion.

The easter egg is a serious problem. For many reasons, we need to know what software is *actually* running in the voting booth. For example, is the software monitoring our votes?

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Nov 30 23:17:09 2003

This archive was generated by hypermail 2.1.8 : Sun Nov 30 2003 - 23:17:13 CST