Re: Auditing subcommittee meeting at clerk convention in Colorado

[Neal McBurnett <neal@xxxxxxxxxxxxxxxxx>]

On Sun, Jan 11, 2009 at 10:52:31AM -0700, Paul E Condon wrote:
> On Sat, Jan 10, 2009 at 12:30:25PM -0700, Neal McBurnett wrote:
> > Attached is the final version of the "Colorado Law Improvements"
> > document we've come up with and will present shortly.
> I read your document using OpenOffice, the numbering/lettering of the
> sections were not bound to any particular convention that OOW
> understood, so I can't refer to seciton by their numbering.

Thanks for your response, Paul.

I thought it worked for me in Open Office, with what I took to be cute
statistical numbering for some points (alpha, beta etc), but I didn't
look closely.  Can you say more?

More below....

> Under "Implement batch reporting:", first sub-section:
> 
> "Batch reports must be machine-readable."
> 
> You should expand to:
> "Batch reports must be machine-readable in a computer file format that
> is open, and non-proprietary, e.g. CSV."
> 
> HTML with cascading style sheets (CSS) is 'machine-readable', but
> hardly audit analyst friendly. But it is also 'open', so my wording
> needs some tweeking.
> 
> Again, under "Aggregate state-wide unofficial data:"
> 
> "Such reports must be machine-readable."
> 
> What is needed, IMO, is a separate section discussing
> 'machine-readable'.  Maybe words about character-based vs. image-based
> are needed. And, yes. HTML is character based. This work is not yet
> done.

This is all too true.  Some other folks are preparing a separate
document on that that I'll forward.

> re. the footnote:
> "If a computer pseudo-random number generator is used to help select
> the audit units, initial values or "seeds" for the generator should be
> chosen using a publicly observed, physical source of randomness, such
> as rolls of fair dice; also, the generator's algorithm must be
> published so that the public can verify that a valid algorithm was
> used."

Re: your suggestion to use timestamps for randomness: if you read the
references cited for the procedure we used in Boulder's audit:

 http://bcn.boulder.co.us/~neal/elections/boulder-audit-08-11/procedure/

you'll see that we really do want more than timestamps in order to get
secure, publically verifiable random numbers.  And it is important to
have evidence that folks from different parties, etc generate the
numbers privately and unveil them at the same time as described there,
so email won't do.

And the PRNG that we used (Rivest's SSR) is less complicated and can
easily be verified by calculator which again makes it well suited to
what we need.

Neal McBurnett                 http://neal.mcburnett.org/

> Consider also a computer based seed: 
> Use the number of seconds since the Unix Epoch at the time of
> initiation of the post-election audit process, or some other
> convenient public event. The seed doesn't need to be truly random,
> just beyond the power to scam by any participant.  Seconds since Unix
> Epoch (SSUE) is surely the most available, ever-changing, non-repeatable
> number in the world. And record this seed, so that calculations that
> are based on it can be repeated precisely for software verification.
> This verification is important for checking any corrections to
> software bugs. 
> 
> But I wonder, is it practical to have only one PRNG process for the
> whole body of work. Maybe just use, and record the SSUE each time a
> seed in used. If someone tries to scam the system by repeatedly
> running an analysis, the record of too many seeds in a short time,
> could be used by auditors-of-the-auditors to catch the cheat.
> Computers are good at keeping records of their operations
> automatically, so this could work, IMO.
> 
> Another suggestion for seed: 
> By prior arrangement with election managers of the two major parties,
> they will each send email to the audit manager after the polls are
> closed. Each email time-stamp is a value of SSUE. Use the product of
> these two different SSUEs as a 64bit seed. 
> 
> My preferred PRNG is the one published by Press, et. al., "Numerical
> Recipes ,,, ". Read this book when it comes time to make a selection.
> 
> Hope this helps.
> -- 
> Paul E Condon           
> pecondon@xxxxxxxxxxxxxxxx