Page 243 - Towards Trustworthy Elections New Directions in Electronic Voting by Ed Gerck (auth.), David Chaum, Markus Jakobsson, Ronald L. Rivest, Peter Y. A. Ryan, Josh Benaloh, Miroslaw Kutylowski, Ben Adida ( (z-lib.org (1)
P. 243

Anonymous One-Time Broadcast Using Non-interactive Dining Cryptographer Nets
                          2.4 Some Subtle Issues
                          Ideally this would be the end of it, but there are three problems to be resolved:
                          A) collisions;                                                    235
                          B) disrupters;
                          C) voters that don’t show up (participated in the preliminary phase but did not submit
                             a sequence).
                          Ad A: The collision probability must be kept very low since it would imply that two
                          (random) votes get lost. However, there exist various straightforward techniques to keep
                          the collision probability low. They basically consist of increasing the length of the bit
                          sequence, or of sending the same message various times, through a different channel or
                          through the same one. See Section 4.1 for discussion.
                          Ad B: Disrupters: this is truly an annoying problem because in the traditional (inter-
                          active) DC setting catching disrupters is already problematic: all participants have to
                          engage in an on-line protocol to identify and drive out the disrupter(s). In our case we
                          cannot catch disrupters afterwards, so we must catch them when they submit. This can
                          be done by having the parties commit on their random bits exchanged. To preserve
                          privacy we will need a Bit Commitment Scheme that is computationally binding and
                          unconditionally hiding. Then we will use a cut-and-choose protocol in which the sender
                          shows that he is following the protocol. In particular he needs to show that for the whole
                          sequence, except the part that contains the message (vote), the bits are truly the result
                          of xors of bits already committed to. Whether he follows the protocol for the bits dedi-
                          cated to the message we could check but don’t have to; he could sent in garbage, but at
                          least he won’t be disrupting the channel.
                          Ad C: A no-shower is someone who went through the initial phase of the protocol,
                          has shared their random bits with other parties, but did not submit any sequence. Their
                          identity will become known, and the best solution is to have people who have inter-
                          acted with them recalculate their submissions. Alternatively, in a setting of a small set
                          of authorities who exchange random bits with each voter, the authorities can simply
                          disregard the random bits of the no-shower(s).
                            Note that in a situation where there is a relatively large amount of trust between the
                          participants, items B) and C) are of no concern.


                          3 A Detailed Description of the Non-interactive Anonymous
                             Broadcast Protocol

                          In this section we describe a Non-Interactive version of the Dining Cryptographers
                          protocol. Though the motivation for this protocol is voting, we describe the protocol in
                          a general setting, i.e. we do not use voting-specific terminology. But we do assume a
                          the same message size for all participants.
                            Some parts of the protocols are of a challenge-response nature, in which the re-
                          sponses are always either random bits or random permutations (which, of course, can
                          be obtained from random bits). In the protocol description we will write that a party
                          commits, and then receives a challenge from a trusted random source. However, it will
   238   239   240   241   242   243   244   245   246   247   248