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]
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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ