hash functions Re: OVC - I "really" need your help with "public disclosure" legislative suggestion

From: Edmund R. Kennedy <ekennedyx_at_yahoo_dot_com>
Date: Mon Nov 27 2006 - 15:24:12 CST

Hello All: Crypographic hash functions are said to be a pretty effective way to detect tampering with program code. Once the code is complete, a hash function of the code is ran and published. Any fiddling with the code afterwards will yield a different hash function result when an idential hash function of the current code is ran and compared to the original published one. While Wikipedia says that there are questions about collisions in even SHA-256 (collisions=different data sets yielding identical hash function results) it still seems like a pretty useful tool even for lay people like me. However, I don't know if it would detect hardware based hacks. What's the current state of the art on hash function? -- 10777 Bendigo Cove San Diego, CA 92126-2510 858-578-8842 Work for the common good. My profile: I blog now and then at: ----- Original Message ---- From: Ron Crane <voting@lastland.net> To: Open Voting Consortium discussion list <ovc-discuss@listman.sonic.net> Sent: Monday, November 27, 2006 12:26:16 PM Subject: Re: [OVC-discuss] OVC - I "really" need your help with "public disclosure" legislative suggestion Cameron L. Spitzer wrote: When I was "logic and accuracy" observer for our county elections in '94, the same question came up: regardless of where this code came from, how do we know what we're looking at/auditing/testing is the same code that was used to run the election.... Of all the objections the paper-and-pencil people raise to computer-assisted tabulation, this is the one I can't swat down. It takes an airtight chain of custody to be sure the tabulation code, and the signature-checking code we use against it, isn't a big fake, and that chain is awfully long and convoluted. Frankly I don't see how it can be airtight if there are private vendors involved. They only have to be confident that they could evade detection until after their fake election gets certified. It's bad even if the Secretary and the registrars own the whole process, and that isn't even on the table. Another defect in the chain is, as Mr. Strauss implied, that an attacker can use firmware or hardware to corrupt even a pristine voting application. Routine random forensic audits can discourage this attack. However, they are expensive, difficult to conduct, time-consuming, and destructive. And they require employing highly-skilled experts, probably very few of whom actually are available (how many people can tell whether the "Z80" CPU in the box is an authentic part and not an emulator that cheats?) Because of these drawbacks, I suspect that officials would almost never conduct proper forensic audits, even were they legally mandated. Also, the forensic auditors themselves would be in an ideal position to attack the systems they audit, a la the Ron Harris e-slot machine fraud (http://www.americancasinoguide.com/Tips/slot-cheat.shtml). End to end auditability isn't enough. The audits have to actually happen, and right away, and it has to be so easy that everyone expects it to happen. Fraud detectability isn't enough, it has to be fast and easy. And it has to be fully open and simple enough so that most citizens could, if they wished, effectively supervise it. Citizen audits should be the primary layer of protection, with open software/firmware/hardware and expert audits being a secondary layer. Even though both layers will, in practice, have holes, maybe the combination is secure enough? -R _______________________________________________ OVC-discuss mailing list OVC-discuss@listman.sonic.net http://lists.sonic.net/mailman/listinfo/ovc-discuss

OVC-discuss mailing list

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

This archive was generated by hypermail 2.1.8 : Thu Nov 30 2006 - 23:17:19 CST