[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Auditing subcommittee meeting at clerk convention in Colorado
On Thu, Jan 15, 2009 at 07:17:28AM -0700, Neal McBurnett wrote:
> On Tue, Jan 13, 2009 at 09:56:55PM -0700, Paul E Condon wrote:
> > On Tue, Jan 13, 2009 at 05:10:34PM -0700, Neal McBurnett wrote:
> > > 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 section 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?
> >
> > I run OO on a Debian Lenny box, using OO package from Debian repository.
> > It opens the document fine. There is no problem with the arrangement of
> > the paragraphs, but where the paragraph numbers (or letters?) should be
> > there is only a little rectangular box. I take this to indicate that
> > the document actually does not have bound values for the heading numbers,
> > but only some indication of what rule should be computed to bind them.
>
> I'm guessing you just need some fonts installed - that is a typical symptom.
>
> > It is an inconvienence, only because one can't refer to sections by the
> > short designation. But it is indicative of what happens with proprietary
> > file formats.
>
> ...and the proprietary nature of so many fonts....
>
> > >
> > > 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 times stamps for randomness: if you read the
> > > references cited for the procedure we used in Boulder's audit:
> >
> > SSUE is, of course, not random. But it is unfudgable, which is good
> > for fending off conspiracy theorists. But there are other ideas. OK. I
>
> But anything predictable is very unsuitable, since the person choosing
> exactly when the times stamp is generated can thus choose a possibly
> significant aspect of the outcome, like "this batch won't be audited".
>
But the attacher is not free to choose any 32bit number. He is
limited to a small selection of numbers centered around the one when
the work was purported to be done. And consider my suggestion of using
the product of time stamps from emails from two independent senders. In
this case the range of values for each number is small but to
precalculate all possible outcomes in order to choose a desired one is
a very big computational problem. If the two emails calculation is not
big enough, choose to require three emails, or four.
If part of the process of choosing were to assign a random number to
each precinct and then choosing among these random numbers to choose
which precincts to audit, I think the task of precomputing a preferred
choice of time would be enormous. If there is a requirement that the
actual SSEU values be published soon after the close of polls, there
would be no possibility of post-election fudging.
Other countermeasures to your objection abound, this are just two.
But the issue of civil ceremony remains. If civil ceremony is needed,
the dice throwing ceremony is, IMHO, quite appropriate.
And it might be appropriate, as part of the public discourse, to
assert that it is logically required to combat fraud. But count me an
honest skeptic.
On further thought: I wonder what would be the goal of the attacker. I
suppose there in no point in biasing the selection unless the attacker
has also arranged to have had ordinary detectable fraud perpetrated
in several precincts. Presumably enough precincts to swing the
election. If this is the situation, then he wants to bias the
selection so that none of the precincts that were fraudulently
reported are selected for audit. It does seem to me that it is
possible to add sufficient tweaks to the SSUE idea to make the
probability of attacker vanishingly small. The attacker works under
his own set of constraints. We only need to make his problem
impossibly hard, in the same way that public key cracking is believed
to be impossibly hard. But comments on civil ceremony still apply.
> > read Rivest's paper. I think the suggestion that using hand
> > calculators for the actual selection of precincts is --- crazy.
> >
> > It is nice to have a calculation that can be repeated by a paranoid
> > person, but to do the actual work that way is only OK when the process
> > is still highly experimental and provisional. Later it should be
> > reduced to computer code. There exist suitable software emulations of
> > eight digit calculators.
>
> No one suggests doing the actual calculations that way. My open source
> ElectionAudits code does it in python. The calculator description is
> indeed only for folks to be able to check it, which reduces the
> "magic" aura of the randomness.
>
OK. But I got a serious impression that Rivest was suggesting this.
Such an authority contradicting you, worries me. You are right, but
you may not be heard.
> > The use of ten sided dice is peculiar. How does one make a fair ten
> > face die? The die cannot be one of the Platonic solids, which have
> > face counts of 4, 6, 8, 12, and 20.
>
> They are all over. Just two 5-sided pyramids back-to-back. Quite fair.
OK. And Rivest does have me convinced that even one or two dice throwers
cheating will not bias the selection in a detectable way.
>
> > > http://bcn.boulder.co.us/~neal/elections/boulder-audit-08-11/procedure/
> > >
> >
> > With real people doing the work, and suspicious people watching, there is
> > a lot of room to misunderstanding. The people who have influence over
> > what key gets generated are all in one room. The procedure is complicated
> > by human standards, An observer has no chance of watching every participant
> > with undivided attention. It is easy for an observer who is unhappy with
> > the result to believe that the participants pulled some trickery.
> >
> > But it might work. It has some possibility of becoming a public ceremony
> > with photographs of participants published in the news paper and whatnot.
> > Ceremonies are good for the community.
>
> Exactly. And the point is that the way this one is designed, you
> can't and don't have to watch everyone do their individual throws.
> You just have to trust someone to do a good throw, and observe that
> their result was unveiled along with the others. Other options
> involve relying on a state lottery or something but they are hard to
> order up to spec.
There are only a very few organizations charged with running a State
Lottery. None of they have the time and budget constraints under
which election officials work. Only one has the quality of volunteer
help that Boulder has. I worry about the other places having adequate
competence.
>
> > > you'll see that we really do want more than time stamps 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.
> >
> > Random numbers for statistical analysis are very different from random
> > numbers for generating secure encryption keys.
> >
> > Rivest has some hand waving about how to get the right total number of
> > precincts chosen to properly use the total level of effort that has
...
> > The code for this sort of thing can be written in C++ and published.
> > The seeds that are used are also published. The whole thing can be
> > checked by the paranoids. Things that involve humans keeping paper
> > records of what they did, or merely think they did, can't be checked
> > so well.
>
> I wouldn't call it hand waving - it is quite specific, and varies for
> PPEBWR vs NEGEXP in terms of whether you have to pick again or not.
>
> Your description is is pretty similar to my code for choosing which
> contests to audit. It uses the python "bisect" module. It is
> published as open source in ElectionAudits - the
> electionaudits/erandom.py file. Check it out.
I was thinking on the basis of my understanding of Rivest's paper.
>
>
>
> > > 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
...
> > > > My preferred PRNG is the one published by Press, et. al., "Numerical
> > > > Recipes ,,, ". Read this book when it comes time to make a selection.
> > > >
> >
> > I don't see the need to make the audit decision at the precinct, as
> > Rivest seems to want. Workers at the precinct are unlikely to be able
> > to do an audit after a 14 hour day supervising the conduct of the
> > vote. But maybe this is something that is really important to someone.
>
> I don't know where you get that impression. This mostly happens days
> later at the state level or the county level, after all the
> preliminary results are published for the entire contest.
Again, from the Rivest paper.
...
--
Paul E Condon
pecondon@xxxxxxxxxxxxxxxx