[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200409290312.i8T3CBX17490@panix5.panix.com>
Date: Tue, 28 Sep 2004 23:12:11 -0400 (EDT)
From: Seth Breidbart <sethb@...ix.com>
To: bugtraq@...urityfocus.com
Subject: Re: Diebold Global Election Management System (GEMS) Backdoor Account Allows Authenticated Users to Modify Votes
"David Schwartz" <davids@...master.com> wrote:
>> Second, to those of us as above, they provide confidence only to
>> the extent that we trust the code being run (which at the least
>> requires it to run on our own computers, and preferably is written
>> by us; I'd trust code I wrote, even though it might have bugs; I'd
>> trust code Bruce wrote, because I know and trust him. I'd trust,
>> to a lesser degree, code that Bruce vetted, because I know how hard
>> it is to examine code and how easy it is to slip something in
>> that's very hard to find.)
>
> This criticism is not correct. The whole point of
>cryptographically-secure voting systems is that you *don't* have to
>trust the code being run. If your vote wasn't counted, you can
>trivially demontrate this.
I disagree. If you _think_ you're running a secure protocol, but
(unbeknownst to you) I've cracked your computer and substituted my own
code, then all of your checks (even if made using another computer
with correct code) will show that your vote was correctly counted,
despite it not having been.
Of course, if you get together N people who voted the same way, and
there are <N such votes, that's proof that either (1) their votes
weren't all correctly counted, or (2) some of them are lying.
You see, the security of the cryptographic protocol involves *actually
running* that cryptographic protocol, and putting blind trust in
someone else's code means you are NOT assured of that.
Seth
Powered by blists - more mailing lists