Re: internet voting -- ICANN, SmartInitiatives, etc.

Kai Henningsen wrote:

> egerck(_at_)nma(_dot_)com (Ed Gerck)  wrote on 12.01.01 in 
> <3A5FDB7A(_dot_)2F4B4D58(_at_)nma(_dot_)com>:
>
> > No. Digital signatures such as X.509/PKIX do violate voter privacy, but
> > never ballot secrecy.
> >
> > In all fairness to you, maybe there is a confusion with the word "privacy".
> > In this case, maybe you write "secrecy" above but you mean "privacy". BIG
> > DIFFERENCE, though.
> Indeed. The way you have it defined, both are one half of what must be
> achieved (impossible to identify voters, and impossible to identify
> votes), with both halves completely meaningless in isolation (which is why
> a traditional paper vote does achieve the combination, but neither half in
> isolation). Whereas the way most people define this, the two terms are two
> names for the same thing, which is the whole (it must be impossible to
> determine who voted what). The correlation is the problem, not the
> isolated facts.
>
> There is more obfuscation like that in your "16 requirements". Not what
> I'd consider a recommendation.
Unless we define and isolate the concepts used, it is nearly impossible to 
meaningfully
deal with them. This is basic scientific method.  Thus, making a clear 
distinction
between "secrecy" and "privacy", as well as between "identification" and
"authentication" and "non-repudiation" is at the heart of the matter here. Doing
otherwise is obfuscation -- "to make obscure."

> > Safevote's open attack test described at www.safevote.com/tech.htm showed
> > that the following attacks were 100% forestalled during the entire test for
> > 24 hours a day in 5 days: (1) Denial-of-Service; (2)  Large Packet Ping; (3)
> > Buffer Overrun; (4) TCP SYN Flood; (5) IP Spoofing; (6) TCP Sequence Number;
> > (7) IP Fragmentation; (8) Network Penetration; and other network-based
> > attacks.
> Grand. It withstood network level attacks. That's about the most
> meaningless test possible - all it proves is the quality of the TCP stack,
> it tells absolutely bloody nothing about the voting system itself.
Forestalling  Denial-of-Service attacks was unheard of and called "impossible"
in Internet voting until we showed how it could be done in one specific network
configuration useful for elections in precincts.  There are other configurations
where it can be done as well, as we shall show in the future.  This was one
Holy Grail in Internet elections, and we got it.

The same applies to other 7 attack types mentioned -- so this was no easy feat
for 5 days, 24 hours/day attacks, with full disclosure and a help line.

Conclusion of the test: "Internet" does not mean "insecurity".  Just because
it uses the Internet it does not mean it MUST be insecure.  Contrary to lore,
Internet communications can be made arbitrarily safe and reliable
(Shannon) if you take into account all the systems connected to it.

The first step is to recognize that any communication channel has a boundary,
which is quite arbitrary. By properly recognizing the sub-communication channels
inside a boundary and by properly placing such boundaries, the point I make is
that it is possible to have the communication system (roughly):

registration --> voter --> ballot box -- > tally --> report

as error-free, anonymous and secret as anyone else may wish (Shannon).
Here, the systems connected to an Internet-base channel are not ignored.
They are taken into account and with adequate error-correction channel(s)
(Shannon).

Again, this is a lot easier in the praxis for precinct-based Internet voting.
Which is all we are talking about at this time.  Home/office-based Internet
voting is IMO too political to be meaningfully discussed at this time. Even
though we do have the technological answer for remote voting as well, we
would lose too much time in discussing it now.  Rather, we prefer to focus on
precinct-based solutions, at a fraction of the price of DREs (electronic
voting) and with better assurances.

Cheers,

Ed Gerck