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

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Mon Nov 27 2006 - 15:46:40 CST

Ways to design collions is MD5 and SHA-X have been show. These require some excess space where random numbers can be inserted. So to do so requires some conspiracy by the person making the original software to include a scratch area that can be modified to induce the collision. In some algorithms it requires a conspiracy to modify the scratch areas of both the "original" and forgery simultaneously.

In any event hashes for the purpose of voting machine authentication only have limited utility. What is more important in my mind is physical control over the mutability of the code and data.

If the running code can be altered then when do you take the HASH? if you take the hash after the election then you have to remove the parts of the code that chaged (variable counters, allocated memory, loaded modules, and so forth) before taking the hash in order to compare it to expected code. But then you lost all the state info. Moreover, if there is any mutable portion of the code itself then the hash proves nothing about what was actually run. Conversely if you take the hash before the code is actually run, it's tricky to know when to do this and to provide any proof that that was the code that was run.

Thus there is an argument to be made that the code and then initialization data be both stored on immutable media (CD-roms) and that these frozen states be preserved. You can at any time after the fact compute their hash or compare them bitwise as you please.

Now of course one can suppose that we don't know that an altered CD-rom might have been swapped in, then swapped back out at the end. True. but By keeping the data and code in physical form, one has a chance to have some sort of chain of custody on it. One has a single immutable object not a panolpoly of ways code injection can occur. Additionally, one can build in other software safeguards such as challenge response specific to every CD-rom that can be attached to the (mutable) vote records to increase the evidence that the correct CD-rom was executed. Not perfect protection but an onion layer requiring very sophisticated attacks at both the central and local precint levels to carry out.

-----Original Message-----
>From: "Edmund R. Kennedy" <ekennedyx@yahoo.com>
>Sent: Nov 27, 2006 4:24 PM
>To: Open Voting Consortium discussion list <ovc-discuss@listman.sonic.net>
>Subject: [OVC-discuss] hash functions Re: OVC - I "really" need your help with "public disclosure" legislative suggestion
>
>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
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= 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