bugtraq - RE: Diebold Global Election Management System (GEMS) Backdoor Account Allows Authenticated Users to Modify Votes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <MDEHLPKNGKAHNMBLJOLKIEEBOKAA.davids@webmaster.com>
Date: Tue, 28 Sep 2004 23:55:08 -0700
From: "David Schwartz" <davids@...master.com>
To: <adam@...eport.org>
Cc: <bugtraq@...urityfocus.com>
Subject: RE: Diebold Global Election Management System (GEMS) Backdoor Account    Allows Authenticated Users to Modify Votes



> On Tue, Sep 28, 2004 at 12:01:41PM -0700, David Schwartz 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

> Of course you have to trust code being run.  The code could be telling
> you that it's running some Chaumian scheme for vote counting, and
> actually be running Diebold code underneath.  What?  Your
> visually-crypted reciept didn't verify?  Some sort of bug, sorry.

	Perhaps you have some odd definition of "trust". My definition of not
having to trust the code is that if it doesn't do what it's supposed to do,
you can prove it conclusively to anyone who will take the time to observe
your proof.

> In other schemes, other code needs trusting to handle private keys, to
> distribute the results, etc.  And in the end, are people who can't
> handle a butterfly ballot going to understand and trust crypto?

	Perhaps we're talking past each other because we're talking about different
schemes, but there are schemes where anyone who chooses to can 100% confirm
that there vote was correctly counted, nobody can be coerced into
demonstrating that they voted a particular way, and if any unauthorized
votes are counted or authorized votes are not, this can be conclusively
demonstrated.

	You don't have to trust the code at all because the code could not
conceivably produce incorrect results. It can only produce correct results
or no results. (Or trivially demonstrably incorrect results.)

	DS