I'm glad that you have now given even us more information, Ed. And my apoligies once
more to Gunnar Sjödin, who in the haste of my translation and postings got the name of
John.
For all on our Swedish list who think this might be all too technical, I would like to
reiterate Gunnar's argumentation that these technical issues around internet voting
are and should be of more than just a technical interest. I, at least, have never
been involved in IT development before where just the techniques are so related to the
success and even the validity of testing and so wrapped up in belief that the "right"
technique is being used.
My hope is that we can get the other approach to security - election.com and/or Living
Questions- and even the newly started "European standard" development project,
CyberVote, also to respond to Gunnar Sjödin's /the Swedish government's internet
election security study committee concerns. Info on VoteHere's security techniques -
and how they differ from SafeVote - has also been requested.
häls
Gail
>>> Ed Gerck <[EMAIL PROTECTED]> 00-11-05 22:51 >>>
Gail Watt wrote:
> Thanks Ed for your response. I have forwarded it to John Sjödin. Do hope he
>responds shortly via the swedish list or directly to you. Think I'll wait a day or
>two for a little more reaction from the Swedish list. So far it is only Vivirto
>people (your Swedish partners?) who have commented.
Gail:
It is well-known in cryptography (Shannon's work) that when all options are equally
possible,
there is no information gained from knowing all the options. So, even more effective
than
keeping information secret (which secret can be broken by collusion, for example) is
to keep
information as a list of equally probable choices. This is the principle behind the
"One Time
Pad" encryption scheme, which is unconditionally secure (if perfectly random).
Safevote's protocols
use this principle in several different ways , together with symmetric and asymmetric
encryption
techniques as disclosed in http://www.safevote.com/tech.htm.
In the case of the IP numbers of the Contra Costa Internet voting network defined by
Safevote,
the range of IP numbers of the two election machines EM1.safevote.com and
EM2.safevote.com were
given in http://www.safevote.com/tech.htm, as well as the IP range of the most
probable public IP address
of the router/hub used by these machines to connect to the Internet. However, the
public IP address
of the router/hub is dynamic. It is randomly assigned by whatever ISP is being used,
from a list of possible
12 phone numbers. So, even we at Safevote did not know what IP address was being used
at each time
because the IP address was assigned dynamically in different dial-up events to
different phone numbers and
different ISPs around the country (long-distance calls notwithstanding).
So, even though an attacker knowns all the public IP addresses on the Internet, and
can even reduce
that list of IP addresses to those of ISPs physically located in the US (we declared
we would use ISP
servers in the US), all such IP addresses are equally probable and the list is
extremely large (many
millions even if just ISPs in California are considered). Thus, there is no
information gained by knowing
this list of IP addresses -- which is our design goal and illustrates the principle
mentioned in the
first paragraph.
Now, even though standard Internet behavior requires port connection attempts to be
answered with a
success or refusal response, Safevote's hub/router responds to an attempt to connect
to itself, to EM1 or to
EM2 as a if it were a nonexistent port -- resulting in no response of either kind --
unless such attempt
corresponds to a pending request from EM1 or EM2 within a pre-specified time window.
Thus, EM1
and EM2 are "stealth" in the Internet. They have full bi-directional connectivity to
the Internet and can
both send and receive data but they cannot be "seen".
To reduce the work facing attackers, we biased the system so that the most probable IP
number started with
"206" -- and provided this tip to attackers. We would certainly NOT do this in a real
election, and we would
certainly NOT create such a bias among the IP address ranges that could be
dynamically assigned -- all 12
address ranges would be equally probable in a real election. To bias the IP
addresses and reveal this bias
in a real election would be akin to revealing the secret key used in a "One Time Pad"
encryption, by giving
away some of its values. In a real election, all possible options must be equally
probable under best efforts
-- and this must be auditable.
Therefore, it is surprising that someone who wishes to provide technical counsel on
computer securitry
would ignore these principles and publicly claim that because in a real election
Safevote would refuse to reveal
some values of secret keys used in the system, Safevote would be playing lightly with
security. The opposite
is true. In testing, however, we may on purpose weaken the system as we did and
introduce some bias in an
otherwise equally probable list of choices. We may even create an "attack hotline" to
help attackers, as we did,
and dialogue with the attackers to help them attack our system -- certainly, Mr.
Sjödin does not expect us
to do the same in a real election ;-)
In fact, since attackers had no success, we are discussing with the expert and hacker
community
(some of this exchange is public, at http://www.safevote.com/tech.htm) how we could
further
bias and reduce choices so that attackers could also test the "stealth" properties of
Safevote's
voting network.
Regarding Vivarto, it is our pleasure to have them as business partners in Europe, as
announced in
our website.
Cheers,
Ed Gerck
