Crypto codes #1

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Thu May 19 2005 - 12:59:44 CDT

I had some off-list discussion of cryptography on paper ballots with
David Webber. Incidentally, David (W)'s a great guy, he works on OASIS
EML (which is complementary w/ OVC), is helping us with the GAO report,
and has recently joined the OVC mailing list.

I disagree with David slightly on some edge issues about the paper
ballot, but this is minor. Below, and I think in two notes to follow
shortly, you can see the comments I made on the paper/crypto stuff.
Sent with David W's permission (since I quote him in my responses).

> From: David Mertz <>
> Date: May 14, 2005 4:11:51 PM EDT
> To: "David Webber \(XML\)" <>

> Hi David,
>> "And cryptographic marks on electronically printed ballots can make
>> box
>> stuffing more difficult.19"
> I'll defend that sentence, since I wrote it :-). (Ron may have changed
> the wording slightly, but close enough)
> It's not a statement that crypto marks *must* be used in an OVC-style
> system, it's for the context of a particular point Shamos makes. I.e.
> in the narrow context, crypto is just as applicable to paper as it is
> to hidden HDDs (contra Shamos).
> But more broadly, I would generally advocate the use of such marks as
> a general matter. Not dogmatically, and not to say I couldn't be
> swayed. But my opinion is loosely "pro-crypto marks."
> Here's what I imagine the crypto marks having (and nothing else).
> (1) Voting machine generates secret key at initialization (k). I
> think a symmetrical key is simpler and adequate, though some people
> have advocated public-key systems.
> (2) Each ballot contains (as printed strings or in a barcode):
> for bv = ballot-id + vote-string:
> e = encrypt(k, hash(bv))
> print bv + hash(bv) + e
> (3) At finalization, k is publicly revealed by the voting machine (and
> published to the world). As a security check, any auditor can compute
> (from bv on the ballot):
> hash(bv)
> decrypt(k, e) (== hash(bv))
> There's nothing in this system that is not HUMANLY analyzable.
> Nothing here depends on some other piece of information that is only
> in electronic records. k is held by the machine during the voting
> day, but become public and printed thereafter. If the machine catches
> fire during the day, and k can't be revealed, then the audit check is
> weaker--you can check hash(bv), but not decrypt(k, hash(bv))--but that
> fact can itself be documented, and does not per se invalidate the
> human readable votes. Yeah, humans who compute MD5 or SHA or AES will
> probably use computers to help them, but it doesn't depend on our
> particular implementation or software.
> There is also NOTHING leaked in this process that is not leaked by the
> votes themselves. There is no information added in these crypto
> codes, only a computation on the votes themselves, which anyone can
> perform. Well, there is the ballot-id mentioned; but that's
> independent of the crypto part. I'm not really as big on the
> ballot-id as some people are. It -does- make correlation with the
> electronic version easier, but I worry about leakage. In any case,
> the above system works just as well absent the ballot-id, recognizing
> that w/o ballot-id, two ballots with the same votes will also have
> identical crypto codes. This is not a complete reductio, but it does
> mean that someone can vote early in the day, photograph their ballot,
> then go home to forge identical ones. With ballot-id included--and
> since Mallory does not yet know k before poll closing--you cannot
> forge a ballot with correct encrypt(k,hash(bv)) value.
> However, while HUMANS can completely analyze the crypto codes w/o
> access to our machines and software, only some humans have the
> technical knowledge to do so. I quite confess that most voters don't
> have the requisite knowledge. So transparency is weakened by the
> inclusion of crypto.

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Tue May 31 23:17:42 2005

This archive was generated by hypermail 2.1.8 : Tue May 31 2005 - 23:17:52 CDT