Abstract
Cardbased cryptography is a variety of secure multiparty computation (MPC). Recently, a new technique called private operations was introduced because the protocol can be implemented with fewer cards than that by using the conventional technique called the shuffle. For example, Nakai et al. showed that if the private operations are available, secure computations of AND and OR operations for two inputs can be realized simultaneously by using four cards, and the protocol is applied to a fourcard majority voting protocol with three inputs. This paper shows that only three cards are sufficient to construct a majority voting protocol with three inputs. Specifically, we propose two constructions of threeinput majority voting protocols. One is a protocol assuming that players can announce their output, and the other is not allowed. Compared to Nakai et al.’s protocol, the protocol with the announcement is realized without any additional private operations and communications. On the other hand, the second construction requires two more private operations and communications because it removes the assumption on the announcement from the first construction. More importantly, the idea of the second protocol can be extended to an ninput majority voting protocol with n cards, which is the main result of this paper.
Introduction
Background
Secure multiparty computation (MPC), introduced by Yao [12], allows players, each with input, to compute a function without revealing any information about their inputs other than what leaked from the output. MPC is usually realized using a computer, but den Boer showed that MPC of AND operation could be realized using five cards without using a computer [1]. Such MPC using physical cards like playing cards is called cardbased cryptography.
Most of the existing works of cardbased cryptography, e.g., [2, 6], rely on a technique called a shuffle. In using the shuffle, we assume that cards are permuted in public repeatedly until all players cannot follow their order, for providing security. Note that the randomness in shuffles is assumed to be unknown to all players, including those who shuffle the deck of cards. Furthermore, since all shuffles are executed in public, a player who performs the shuffle cannot cheat. The shuffle is a technique involving such physical assumptions.
Instead of shuffles, Nakai et al. [8] and Marcedone et al. [4] independently introduced private permutations (or private operations), which are operations that a player permutes cards behind the player’s back to conceal the operation from the other players. Private operations allow players to use private randomness and capture local computation in (ordinary) secure multiparty computation. However, instead of removing the physical assumptions on shuffles, private operations are vulnerable to malicious behavior in the private area. Hence, in this paper, we assume that cardbased cryptography with private operations is executed under the semihonest model, i.e., a model in which every player always follows a protocol.^{Footnote 1}
Although we have to assume the semihonest model, private operations are useful because they make existing protocols simpler and more efficient. Hence, several cardbased cryptographic protocols have been developed recently. For instance, the AND operation can be realized with only two or three cards (depending on the physical assumptions, e.g., players are allowed to announce their outputs) by using private operations [4], whereas the most efficient AND protocol using shuffles needs four cards (and relatively complicated procedures) [2]. The XOR and OR operations using private operations can be realized with two and three cards, respectively [7]. Furthermore, Nakai et al. [7] proposed a protocol that simultaneously computes AND and OR with four cards (called the AND/OR protocol) and showed that it could be used to construct a secure threeinput majority voting protocol, which is a secure multiparty computation protocol that takes binary inputs from three players and outputs the result of majority voting.^{Footnote 2}
In the above protocols using private operations, formats of inputs and outputs are not always consistent. The protocols that have the same format of inputs and outputs are called commitment. Usually, a binary input is represented by a commitment using a pair of cards such as and unless an upsidedown card is used. In any protocol with the commitment format, two cards are necessary for each input, so at least four cards are necessary for computing a function with two inputs.^{Footnote 3} We note that when a binary input is represented by a commitment using a card such as and , four cards are still needed to represent all possible inputs \(x \in \{0,1\}^2\). This is a disadvantage of the protocols with committed formats, but it has an advantage that such protocols are easy to be combined securely.
Our Contributions
Proposal of majority voting protocols In this paper, we show that three cards are sufficient to construct a threeinput majority voting protocol by using private operations. Specifically, we first construct a protocol that simultaneously computes logical AND, XOR, and NOR operations (for two binary inputs), called an AND/XOR/NOR protocol, using only three cards.
We then show a threeinput majority voting protocol (Protocol 3: \(\mathrm{MAJ}_{3}\text {wA}\)) using our threecard AND/XOR/NOR protocol, whereas a threeinput majority voting protocol is built on the AND/OR protocol by Nakai et al. [7]. The core idea of this construction is to allow players to announce their outputs to realize the OR operation based on the NOR operation. Namely, a player who gets the result of the NOR operation can announce the result of OR (not NOR), e.g., a player negates the value of NOR in the player’s mind and tells the negated result (the value of OR) to other players by voice. However, such an announcement is not desirable since additional cards or assumptions are required compared to the case where announcements are not used. Fortunately, it is possible to remove the announcement without increasing the number of cards at the cost of two additional private operations. We propose such a protocol (Protocol 4: \(\mathrm{MAJ}_{3}\)). Furthermore, we can extend the threeinput majority voting protocol (\(\mathrm{MAJ}_{3}\)) to ninput majority voting protocols using n cards (\(\mathrm{gMAJ}_{n}\)) shown in Protocols 6 and 7. Based on the observations of \(\mathrm{MAJ}_{3}\), we assume some of the procedures of an ninput majority voting protocol. As a result, we can construct \(\mathrm{gMAJ}_{n}\) by combining cyclic shifts of cards’ sequences.
Efficiency comparisons The proposed protocols in this paper is more efficient than the previous ones. We compare our protocols with those of Nakai et al. [7] in the case of \(n=3\), and with those of Ono and Manabe [10] for general n.
Table 1 compares efficiencies among Nakai et al.’s protocol and the proposed protocols \(\mathrm{MAJ}_{3}\text {wA}\) and \(\mathrm{MAJ}_{3}\). Compared with Nakai et al.’s protocol, the proposed protocols can reduce one card for computing threeinput majority functions. In particular, \(\mathrm{MAJ}_{3}\text {wA}\) (Protocol 3) increases neither the number of private operations nor the number of communications, though we allow Carol to announce the result. On the other hand, \(\mathrm{MAJ}_{3}\) (Protocol 4) realizes threeinput majority voting by only three cards without announcement. Instead, we need two more private operations and communications.
Table 2 shows a comparison among Ono and Manabe’s protocols [10] and proposed protocols \(\mathrm{gMAJ}_{n}\) (Protocols 6 and 7). Note that two Ono and Manabe’s protocols can compute any logical function with n inputs, including ninput majority voting. Compared with the two Ono and Manabe’s protocols, the number of cards and private operations are lower in \(\mathrm{gMAJ}_{n}\). Regarding the number of communications, the second protocol of Ono and Manabe’s protocol is much more efficient than \(\mathrm{gMAJ}_{n}\). However, it requires an exponential number of cards.
Differences from the conference version This paper is the full version of [11]. In this paper, [11] is extended by newly proposing \(\mathrm{gMAJ}_{n}\), ninput majority voting protocol, in Sect. 4 and Appendix A. In Sect. 4, the case where n is odd is mainly described. Since the case where n is even is almost the same as the case where n is odd, the details of the case where n is even are described in Appendix A.
Organization
The rest of this paper is organized as follows: in Sect. 2, we define notations, majority voting, and a left cyclic shift. Two threeinput majority voting protocols are proposed in Sect. 3. The first one is the protocol with the announcement, and the second one is modified so that all operations are executed by cards only. Section 4 is devoted to extending the modified threeinput majority voting protocol to an ninput majority voting protocol. We conclude this paper in Sect. 5. The details on the ninput majority voting protocol for even n, omitted in Sect. 4 due to similarities with the case of odd n, are given in Appendix A.
Preliminaries
Notations
We use two kinds of cards such as and , where we assume that the cards with the same suit are indistinguishable. We also assume that all cards are indistinguishable if they are turned over, and they are denoted by . For simplicity, we omit the frame of cards hereafter, i.e., \(\clubsuit \), \(\heartsuit \), and ? are used instead of using , , and , respectively.
There are two models of card operations: a shuffle model and a private operation model. We adopt the latter model. According to [7, 8], we design the proposed protocols based on the following operations of cards:

Permutation Permutation of facedown cards in public.

Turn over Facedown or open cards.

Private operation^{Footnote 4} Operations privately executed by a player, and their result is kept secret to the other players.

Announcement Operations which make some information public. The information to be announced can be computed privately by the announcer, but that cannot be represented by the cards running the protocol.
Private operations are assumed to be executed easily, for instance, behind the player’s back. See [4, 8] for details.
Majority Voting with Three Inputs
For three binary inputs \(a,b,c\in \{0,1\}\), we define the majority voting for three inputs by:
which is also represented as [7]
Majority Voting with nInputs
For n binary inputs \(x_0, x_1, \ldots , x_{n1} \in \{0,1\}\), we define the threshold function for n inputs by:
The ordinary majority voting is the case where \(t = \lceil n/2 \rceil \).
Left Cyclic Shift
Suppose that there exists a sequence of n cards, which is represented by
Note that numbers are written in order to specify the order of the cards.
Then, a left cyclic shift over the n cards is defined as an operation such that the leftmost card of the sequence moves to the rightmost position of the sequence. The following shows the sequence of cards before and after a left cyclic shift of 5 cards.
A left cyclic shift can also be performed over a part of the card sequence. For example, if we perform a left cyclic shift over the left three cards out of five, we get the following.
The left cyclic shift has a feature that the order of the cards is restored after m left cyclic shifts over m cards.
ThreeInput Majority Voting Protocol
In this section, we first propose a threeinput majority voting protocol with announcement. This protocol is obtained from reducing a card from Nakai et al.’s fourcard AND/OR protocol. Next, the threeinput majority protocol is modified to be executable without announcement.
\(\mathrm{MAJ}_{3}\text {wA}\): ThreeInput Majority Voting Protocol with Announcement
Previous Work: Fourcard AND/OR Protocol
Assume that Alice, Bob, and Carol possess binary inputs a, b, and c, respectively. Equation (2) implies that \(\mathsf {maj}(a,b,c)\) can be securely computed by Carol if the results of \(a \wedge b\) and \(a \vee b\) are simultaneously computed securely, and she can choose one of them in her back privately depending on her bit c. Specifically, for computing \(\mathsf {maj}(a,b,c)\) securely, Carol chooses \(a \wedge b\) if \(c=0\); otherwise, i.e., \(c=1\), she chooses \(a \vee b\).
Based on this idea, Nakai et al. [7] proposed a fourcard AND/OR protocol, which is described in Protocol 1. We note that this protocol requires four cards for representing all combinations of inputs, although only two cards are used to execute this protocol. Table 3 shows the combinations of cards after step 2) of this protocol for readers’ convenience, where the subscript indicates who has the card. This protocol is obtained by merging a threecard AND protocol [4] and a threecard OR protocol [7].
In Protocol 1, binary inputs are encoded as
which is used throughout this paper.
ThreeCard AND/XOR/NOR Protocol Based on Protocol 1, we propose a new cardbased protocol to compute AND/NOR simultaneously instead of computing AND/OR. The proposed protocol is implemented by three cards, which is a result of reducing one card from Protocol 1. Furthermore, the proposed protocol can compute XOR of two binary inputs simultaneously with AND/NOR. The application of this protocol to majority voting will be discussed in Sect. 3.1.
Idea behind the protocol To see our idea, we try to construct a new AND/OR protocol by reducing a card from Protocol 1 at first. In Protocol 1, Alice has \(\heartsuit \) and \(\clubsuit \) in the setup. It seems hard to reduce the number of her cards because she has to securely input her bit by a facedown card. Hence, if we can reduce the number of cards in Protocol 1, the only way is to reduce one card from Bob. Which one of \(\clubsuit \) or \(\heartsuit \) should Bob have? To answer this question, observe the following properties (see also Fig. 1):
 Case of \(b=0\)::

 (a):

It holds that \(a \wedge b =b ~(=0)\) regardless of the value of a.
 (b):

It holds that \(a \vee b =a\).
 Case of \(b=1\): :

 (c):

It holds that \(a \wedge b =a\).
 (d):

It holds that \(a \vee b =b ~(=1)\) regardless of the value of a.
The properties (a)–(c) suggest Bob having \(\clubsuit \), and placing it to the leftmost of the cards he received from Alice if \(b=0\); otherwise, to the right. However, this approach obviously fails to realize (d) because \(a \vee b =1\) holds, whereas \(\clubsuit \) is placed on the right.
Considering the above discussion of the difficulty in realizing the AND/OR protocol with three cards, we alternatively show that a secure AND/NOR protocol is realizable with three cards as follows (see also Fig. 2): rewrite (b) and (d) as the equivalent statements such that:

(b’)
It holds that \(\lnot (a \vee b) = \lnot a\), and

(d’)
It holds that \(\lnot (a \vee b) =\lnot b ~(=0)\) regardless of the value of a,
respectively. Recalling that \(\clubsuit \) indicates 0, properties (b’) and (d’) imply that it is possible to output \(\lnot (a\vee b)\) at the left of the cards if Alice prepares two cards in step 1) instead of one card in Fig. 1 and Bob places \(\clubsuit \) to the left if \(b=0\); otherwise, to the right.
Threecard AND/XOR/NOR protocol Observing Fig. 2, we find that the center of three cards is a in the case of \(b=0,\) whereas it is \(\lnot a\) in the case of \(b=1\). Noticing that \(a= a \oplus 0\) and \(\lnot a = a\oplus 1\), the center of three cards indicates \(a \oplus b\), where \(\oplus \) denotes the XOR operation. Therefore, surprisingly, the AND/NOR protocol discussed in Fig. 2 also succeeds in computing XOR simultaneously. Hence, we call this protocol as a cardbased AND/XOR/NOR protocol. The cardbased AND/XOR/NOR protocol can be described in Protocol 2. We show the combinations of cards after the Step 2) in Table 4 for readers’ convenience.
\(\mathrm{MAJ}_{3}\text {wA}\): ThreeCard Majority Voting with Announcement
Although we failed to construct a threecard AND/OR protocol, we succeeded to construct the threecard AND/XOR/NOR protocol (Protocol 2). Even if the AND/XOR/NOR protocol is used instead of a AND/OR protocol, threeinput majority voting can be easily constructed by allowing Carol to announce.
If Carol inputs \(c=1\), she shall choose the card indicating \(\lnot (a \vee b)\) behind her back, and makes \(a \vee b\) public by negating \(\lnot (a \vee b)\) in her mind. Making \(a \vee b\) public is possible for Carol if she is allowed, for instance, to announce her output.^{Footnote 5} It is obvious that she can obtain no information other than \(a \vee b\) in this process.
One might wonder if this announcement leaks important information since Carol can see \(a \wedge b\) (resp., \(a \vee b\)) if \(c=0\) (resp., \(c=1\)). We would like to note that it does not violate security since Carol eventually obtains the information from the output of the majority voting.
In summary, the proposed protocol \(\mathrm{MAJ}_{3}\text {wA}\) is described in Protocol 3. For readers’ convenience, we show in Table 5 all combinations of cards after the step 2) of Protocol 3, where the underline indicates the card that Carol opens behind her back. In the case of \(c=1\), we can see that the bit represented by the card she opens and the output she announces are flipped.
\(\mathrm{MAJ}_{3}\): ThreeInput Majority Voting Protocol Without Announcement
In this subsection, we show how we modify \(\mathrm{MAJ}_{3}\text {wA}\) in the previous subsection so that all the operations (including the output) are represented by cards without increasing the number of cards.
Construction Idea
To construct a cardbased majority voting protocol with three inputs without announcement, we take another look at Eq. (1) from the viewpoint of \(a=b\) or not.
If \(a=b\), it holds that either \((a,b)=(0,0)\) or \((a,b)=(1,1)\). In the case of \((a,b)=(0,0)\), \(\mathsf {maj}(a,b,c)=0=a \wedge b\) regardless of the value of \(c \in \{0,1\}\). Similarly, we have \(\mathsf {maj}(a,b,c)=1=a \wedge b\), in the case of \((a,b)=(1,1)\) regardless of the value of \(c \in \{0,1\}\).
On the other hand, if \(a\ne b\), it holds that \((a,b)=(1,0)\) or \((a,b)=(0,1)\), i.e., \(a+b=1\), which leads to \(\mathsf {maj}(a,b,c)=c\) from the definition of \(\mathsf {maj}(\cdot ,\cdot ,\cdot )\) given by (1).
In summary, (1) is equivalent to
Suppose that Step 2) of \(\mathrm{MAJ}_{3}\text {wA}\) has been completed. Then, the leftmost card represents \(a \wedge b\) (see also Protocol 2 and Fig. 2), which is equivalent to the output of \(\mathsf {maj}(a,b,c)\) in the case where \(a=b\). Therefore, we additionally require the procedure that, the leftmost card is replaced by the card representing c if \(a \ne b\), or otherwise it is untouched. The following two steps are sufficient so as to realize this requirement:
 Step A):

Keeping the leftmost card representing \(a \wedge b\), let the center card represent c if \(a\ne b\).
 Step B):

Swap the leftmost and the center cards if \(a\ne b\).
For realizing step A), observe that \(a \oplus b =1\) and \(\lnot (a \vee b)=0\) hold in the case of \(a \ne b\), and, after the Step 2) of Protocol 3, the center and the rightmost cards represent \(a \oplus b\) and \(\lnot (a \vee b)\), respectively, (see Protocol 2 and Fig. 2). Hence, Carol can realize Step A) without knowing the actual values of a and b by swapping the center card for the right one (behind her back) if \(c=0\), or does nothing otherwise.
Realization of Step B) is easy: it is sufficient that Alice and Bob successively swap the left card for the center card if and only if his/her input is 0, since the swap is done only once if and only if \(a \ne b\) under this rule.
\(\mathrm{MAJ}_{3}\): ThreeCard Majority Voting for Three Inputs Without Announcement
Based on the construction idea, we construct \(\mathrm{MAJ}_{3}\), a threeinput majority voting protocol with three cards without any announce operations, which is described in Protocol 4. See also Fig. 3, where the question marks denote the facedown cards a player received from the previous player.
\(\mathrm{gMAJ}_{n}\): nInput Majority Voting Protocol
In this section, we consider a more general setting, i.e., majority voting protocols with arbitrarynumber inputs. However, unfortunately, the construction of \(\mathrm{MAJ}_{3}\) is specific to the threeinput setting, so it seems hard to extend \(\mathrm{MAJ}_{3}\) itself to the arbitrarynumber input setting. Nevertheless, we construct an ninput majority voting protocol, called \(\mathrm{gMAJ}_{n}\), for any \(n \ge 4\) based on the construction approach of \(\mathrm{MAJ}_{3}\). Note that \(\mathrm{gMAJ}_{n}\) does not include \(\mathrm{MAJ}_{3}\) as a special case; indeed, \(\mathrm{gMAJ}_{n}\) for \(n=3\) does not work well.
The outline of our construction approach is as follows. First, based on the procedure of \(\mathrm{MAJ}_{3}\), we assume \(\mathrm{gMAJ}_{n}\) has three phases (called placement, permutation, and output). In addition, we also assume the operations in the permutation phase and the output phase. Then, we deduce the card sequence in the placement phase based on the assumed permutation and output phase.
Our Construction Approach
First, we divide the procedures of our threeinput protocol \(\mathrm{MAJ}_{3}\) into three phases as follows.

Placement phase: Alice and Bob place all of three cards face down and perform private operations to generate a card sequence depending on the value of a and b (cf., Steps 1)–2)).

Permutation phase: Each player performs private operations to permute a part of the card sequence (cf., Steps 3)–5)). More concretely, these procedures can be organized into the following two subphases.

Permutation phase 1: At Step 3), Carol swaps the center card for the rightmost one if \(c=0\).

Permutation phase 2: At Steps 4) and 5), Bob and Alice swap the center card for the leftmost one if \(b=0\) and \(a=0\), respectively.


Output phase: The protocol outputs the leftmost card of the card sequence.
Toward realizing ninput protocol \(\mathrm{gMAJ}_{n}\), we abstract the above procedures as follows. Suppose there are two groups (or two sets) of players, \(\mathcal {P}_{\textsc {l}}\) and \(\mathcal {P}_{\textsc {s}}\), such that \(\mathcal {P}_{\textsc {l}} = \mathcal {P}_{\textsc {s}} + 1\).^{Footnote 6} Let \(\mathsf {op}_{\textsc {l}}\) and \(\mathsf {op}_{\textsc {s}}\) be two distinct private operations. Then, the procedures of \(\mathrm{MAJ}_{3}\) can be abstracted as follows.

Placement phase: All players in \(\mathcal {P}_{\textsc {l}}\) place all of three cards face down and perform private operations to generate a card sequence depending on their inputs.

Permutation phase:

Permutation phase 1: Each player in \(\mathcal {P}_{\textsc {s}}\) performs the private operation \(\mathsf {op}_{\textsc {s}}\) if the player’s input is zero.

Permutation phase 2: Each player in \(\mathcal {P}_{\textsc {l}}\) performs the private operation \(\mathsf {op}_{\textsc {l}}\) if the player’s input is zero.


Output phase: The protocol outputs the leftmost card of the card sequence.
In the case of \(\mathrm{MAJ}_{3}\), Alice and Bob belong to the large group \(\mathcal {P}_{\textsc {l}}\) and Carol belongs to the small group \(\mathcal {P}_{\textsc {s}}\). \(\mathsf {op}_{\textsc {l}}\) is the replacement of the center card with the leftmost one, and \(\mathsf {op}_{\textsc {s}}\) is the replacement of the center card with the rightmost one.
We take the above constructing approach based on \(\mathrm{MAJ}_{3}\): during the placement phase, all players in \(\mathcal {P}_{\textsc {l}}\) place all cards face down in the some order; during the permutation phase, each player performs private operations (i.e., \(\mathsf {op}_{\textsc {l}}\) or \(\mathsf {op}_{\textsc {s}}\)) if the player’s input is zero; and during the output phase, the protocol outputs the leftmost card of the card sequence. Note that players belonging to the same group perform the same operation in the permutation phases 1 and 2. Therefore, what we need to determine to realize \(\mathrm{gMAJ}_{n}\) is threefold:

The concrete card sequence at the end of the placement phase.

How the players in \(\mathcal {P}_{\textsc {l}}\) generate the card sequence during the placement phase.

The concrete procedures of \(\mathsf {op}_{\textsc {l}}\) and \(\mathsf {op}_{\textsc {s}}\) in the permutation phase.
To determine the above three for \(\mathrm{gMAJ}_{n}\), particularly for the first one (i.e., to figure out the concrete card sequence), we take a closer look at \(\mathrm{MAJ}_{3}\) in the next subsection. We here describe the overview. First, we analyze how the private operations in \(\mathrm{MAJ}_{3}\) affect the output of the protocol. Namely, we analyze where the output card (i.e., the leftmost card at the output phase) is placed at each step in \(\mathrm{MAJ}_{3}\). The analysis clarifies the minimum requirement of the card sequence at the end of the placement phase; it determines the suits and positions of some cards in the card sequence. In the subsection after that, we then extend the minimum requirement to the arbitrarynumber input setting, and determines the suits of the rest of cards as well as the concrete procedures during the placement and permutation phases, respectively.
Observation About \(\mathrm{MAJ}_{3}\)
For simplicity, we describe card sequences in \(\mathrm{MAJ}_{3}\) by and , where denotes the output card of \(\mathrm{MAJ}_{3}\), i.e., the leftmost card at the output phase. Namely, the card sequence at the output phase (or the output sequence) is represented as “ .” Note that the output sequence (hence the output card) is always the above one for any \(a,b,c\in \{0,1\}\).
We begin with the analysis of the card sequences for any fixed \(a,b,c\in \{0,1\}\) during the permutation phase. It is obvious that the card sequence after the permutation phase 2 (i.e., before the output phase) is “ ” for any \(a,b,c\in \{0,1\}\).
How about the card sequence after Step 3), i.e., after the permutation phase 1? At Steps 4) and 5) (i.e., during the permutation phase 2), the leftmost card is swapped with the center one depending on the value of b and a, respectively. Therefore, we can summarize the card sequence after the permutation phase 1 in Table 6. If \(a+b=1\), the center card at the end of the permutation phase 1 will be used for the output of the protocol since the left and center cards are swapped once during the permutation phase 2; otherwise, the cards are swapped twice or not swapped at all during the permutation phase 2, so the leftmost card at the end of the permutation phase 1 will be used as the output card.
Next, to determine the card sequence at the beginning of the permutation phase, we look at the procedure at the permutation phase 1. If \(c=0\), the center card is swapped with the rightmost one. As can be seen in Table 6, the swap affects the position of the output card only when \(a+b=1\), and the position of the output card varies depending on the value of c. Therefore, we can summarize the card sequences at the beginning of the permutation phase in Table 7.
Due to the correctness of \(\mathrm{MAJ}_{3}\), the suits of in Table 7 are uniquely determined; Table 8 shows the minimum requirement for the suits and positions of some cards in the card sequences at the beginning of the permutation phase, i.e., before Step 3). Table 9 shows the concrete card sequences in \(\mathrm{MAJ}_{3}\), and one can see that the sequences meet the minimum requirement in Table 8. Moreover, one can also check that the placement phase of \(\mathrm{MAJ}_{3}\), i.e., Steps 1) and 2), correctly generates the card sequences in Table 9 for any \(a,b\in \{0,1\}\) by manually inputting all combinations of \(a,b \in \{0,1\}\).
Toy Example: the Case of \(n=5\)
Based on the above observation, let us consider how to construct a fiveinput majority voting protocol \(\mathrm{gMAJ}_{5}\) as an example. Suppose that each player \(P_i\) has a binary input \(x_i \in \{0,1\}\) for \(i \in \{0,1,\ldots ,4\}\), and let \(\mathcal {P}_{\textsc {l}}:= \{P_0, P_1, P_2\}\) and \(\mathcal {P}_{\textsc {s}}:= \{ P_3,P_4\}\). We assume \(\mathrm{gMAJ}_{5}\)’s procedure as follows based on that of \(\mathrm{MAJ}_{3}\). Note that, just as three cards are used in the case where \(n=3\), we also assume that five cards are used in the case where \(n=5\). The suit of each of the five cards is specified later.

Placement phase: \(P_0, P_1, P_2 \in \mathcal {P}_{\textsc {l}}\) place all of five cards face down and perform private operations to generate a card sequence depending on their inputs.

Permutation phase:

Permutation phase 1: Each of \(P_3, P_4 \in \mathcal {P}_{\textsc {s}}\) performs the private operation \(\mathsf {op}_{\textsc {s}}\) if the player’s input is zero.

Permutation phase 2: Each of \(P_0, P_1, P_2 \in \mathcal {P}_{\textsc {l}}\) performs the private operation \(\mathsf {op}_{\textsc {l}}\) if the player’s input is zero.


Output phase: The protocol outputs the leftmost card of the card sequence.
As in the observation on \(\mathrm{MAJ}_{3}\), we construct \(\mathrm{gMAJ}_{5}\) based on the above assumptions. Concretely, we first consider the card sequence during the permutation phase. Then, the requirement of card sequences at the beginning of the permutation phase is specified. Finally, we determine the suits of cards and the operations in the placement phase.
Table 10, which is extended from Table 6 in the fiveinput setting, shows the expected card sequences after the permutation phase 1. Note that swapping two cards and a left cyclic shift over two cards are equivalent. Therefore, we consider the swapping in the permutation phase 2 in \(\mathrm{MAJ}_{3}\) as a left cyclic shift and extend it to the case of five inputs. That is, we assume that \(\mathsf {op}_{\textsc {l}}\) is the left cyclic shift over three cards on the left. As a result, the output card is placed at the leftmost position after the permutation phase 1 if \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i = 0\) or \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i = 3 ~(=\mathcal {P}_{\textsc {l}})\). Note that this is the same as we can see in \(\mathrm{MAJ}_{3}\) if \(a+b=0\) or \(a+b=2\). Then, at the end of the permutation phase 1 in \(\mathrm{gMAJ}_{5}\), the output card is placed at the center of the sequence if the inputs of two players in \(\mathcal {P}_{\textsc {l}}\) will be zero (i.e., \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i = 1\)). Similarly, the output card is placed the second one from the left if only one player in \(\mathcal {P}_{\textsc {l}}\) will be zero, i.e., \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i = 2\).
Now, recall the private operation \(\mathsf {op}_{\textsc {s}}\) in \(\mathrm{MAJ}_{3}\), i.e., the replacement of the center and rightmost cards, during the permutation phase 1; it can be also regarded as the left cyclic shift over two cards on the right. By extending it, we consider the following private operation as \(\mathsf {op}_{\textsc {s}}\) during the permutation phase 1 in \(\mathrm{gMAJ}_{5}\): the left cyclic shift over four cards on the right.
By fixing \(\mathsf {op}_{\textsc {l}}\) and \(\mathsf {op}_{\textsc {s}}\) as above, we can find out the card sequences and the minimum requirement of card sequences at the beginning of the permutation phase (see Tables 11, 12, respectively).
The last issue we have to resolve is how the players place cards and perform private operations so that the resulting card sequence is consistent with the minimum requirement, \(\mathsf {op}_{\textsc {l}}\), and \(\mathsf {op}_{\textsc {s}}\). Through the second and third card sequences in Table 12, let us assume that the three cards on the right are the same regardless of any input of \(\mathcal {P}_{\textsc {l}}\), i.e., \(x_0\), \(x_1\), and \(x_2\). From Table 12, the leftmost card should be \(\clubsuit \) if \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i = 0\), whereas it should be \(\heartsuit \) if \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i = 3\). Moreover, the second card from the left should be \(\heartsuit \) if \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i = 2\). It means we need a certain private operation to make the protocol consistent. Hence, we set the private operation during the placement phase is the left cyclic shift over the two cards \(\clubsuit \, \heartsuit \) on the left, and each player in \(\mathcal {P}_{\textsc {l}}\) performs it if their input is one. Then, the cards \(\clubsuit \, \heartsuit \) are shifted left (swapped) \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i\) times, which satisfies the requirements shown in Table 12 because if \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i\) is even, the two cards result in \(\clubsuit \, \heartsuit \), and if \(\sum _{P_i \in \mathcal {P}_{\textsc {l}}} x_i\) is odd, the two cards result in \(\heartsuit \, \clubsuit \). Consequently, an initial card sequence (i.e., a card sequence at the beginning of the placement protocol) should be \(\clubsuit \, \heartsuit \, \heartsuit \, \clubsuit \, \clubsuit \). Table 13 summarizes the concrete card sequences at the beginning of the permutation phase, and our fiveinput majority voting protocol \(\mathrm{gMAJ}_{5}\) is formally given in Protocol 5.
We note that we may construct different protocols if we make different assumptions about the number of cards, the procedure of the protocol (i.e., placement, permutation, and output phases), the operations \(\mathsf {op}_{\textsc {l}}\) and \(\mathsf {op}_{\textsc {s}}\) in the permutation phase, and the suits of three cards on the right (assumed for determining the placement phase).
Construction Idea for Arbitrary n
We generalize the above construction for \(n=5\) and construct \(\mathrm{gMAJ}_{n}\), a majority voting protocol with n inputs. We assume \(\mathrm {gMAJ}_{n}\)’s generalized procedure for odd \(n=2m+1\) and extend it to even n later. Suppose that each player \(P_i\) has a binary input \(x_i \in \{0,1\}\) for \(i \in \{0,1,\ldots ,n\}\), and let \(\mathcal {P}_{\textsc {l}}:= \{P_0, \ldots , P_{m}\}\) and \(\mathcal {P}_{\textsc {s}}:= \{ P_{m+1}, \ldots , P_{2m}\}\). In the generalized procedure, the operations \(\mathsf {op}_{\textsc {s}}\) and \(\mathsf {op}_{\textsc {l}}\) in the permutation phases 1 and 2 are assumed to be a left cyclic shift refer to the case where \(n=5\). In addition, we assume to use \(n~(=2m+1)\) cards, although the suit of each card is determined later.

Placement phase: All of n cards are (publicly) placed face down in some order (will be determined as in \(\mathrm{gMAJ}_{5}\)), and players \(P_i \in \mathcal {P}_{\textsc {l}}\) perform private operations to generate a sequence of cards depending on their inputs.

Permutation phase:

Permutation phase 1: Each player \(P_i \in \mathcal {P}_{\textsc {s}}\ (i \in \{m+1,\ldots , 2m\})\) performs the left cyclic shift over \(n1 \ (= 2m)\) cards on the right as the private operation \(\mathsf {op}_{\textsc {s}}\) if \(x_i = 0\).

Permutation phase 2: Each player \(P_i \in \mathcal {P}_{\textsc {l}}\ (i \in \{0,\ldots , m\}\) performs the left cyclic shift over \(m+1\) cards on the left as the private operation \(\mathsf {op}_{\textsc {l}}\) if \(x_i = 0\).


Output phase: The protocol outputs the leftmost card of the card sequence.
By assuming the above procedure, all we have to do to construct an ninput majority voting protocol becomes to figure out the operations in the placement phase. As we constructed \(\mathrm{gMAJ}_{5}\), we specify the placement phase by following steps:

(1)
Specify the position of the output card depending on players’ inputs.

(2)
Specify the requirement of card sequences which has to be satisfied at the beginning of the permutation phase.

(3)
Specify the suits of cards and operations in the placement phase to generate the card sequence satisfying the requirement.
Indeed, Tables 14, 15, and 16 support these steps, respectively, as in the case of \(\mathrm{gMAJ}_{5}\) in the previous subsection.
Odd Case: Majority Voting Protocol with \(2m+1\) Inputs Where \(m \ge 2\)
Based on the construction idea in Sect. 4.4, we construct an ninput majority voting protocol for \(n = 2m+1, ~m \ge 2\) called \(\mathrm{gMAJ}_{2m+1}\). By tracing the output card during the assumed permutation phase, the card sequence at the end of the placement phase can be represented as shown in Table 14. Note that the numbers \(0, 1, \ldots , 2m\) in the table’s heading row indicate the index of the order in the sequence of cards. Then, from the values of \(\sum _{i=0}^{m} x_i\) and \(X ~(= \sum _{i=m+1}^{2m})\), we can specify the suits of the output cards shown in Table 14 to compute the majority voting correctly. The specified result, which indicates the minimum requirement for the correctness of \(\mathrm{gMAJ}_{2m+1}\), is represented in Table 15.
To specify the cards at the nonoutput positions in the sequences of cards after the placement phase, let us assume that \(m+1\) cards from the right are the same regardless of any input of \(\mathcal {P}_{\textsc {l}}\), i.e., \(P_0, P_1,\ldots , P_{m}\). Then, the m cards from the left can be considered to sequences of cards obtained by \(\sum _{i=0}^{m} x_i\) times left cyclic shift over the m cards \(\clubsuit \overbrace{\heartsuit \cdots \heartsuit }^{m1}\). Actually, by performing these operations, \(\clubsuit \) appears at the \(((m\sum _{i=0}^{m} x_i) \bmod m)\)th leftmost place of the sequence and other places are filled by \(\heartsuit \). We can see that such a sequence satisfies the requirement shown in Table 15. Therefore, the specified sequences of cards and constructed protocol become as shown in Table 16 and Protocol 6, respectively.
Number of Cards, Private Operations, and Communication Required in \(\mathrm{gMAJ}_{2m+1}\) (Protocol 6).
\(\mathrm{gMAJ}_{2m+1}\) is executable with \(m+1\) cards and m cards, i.e., \((m+1)+m = n\) cards. Then, \(m+1\), m, and \(m+1\) players perform a private operation in Step 1), 2), and 3), respectively. Therefore, the number of private operations is \((m+1) + m + (m+1) = n + \lfloor n/2 \rfloor + 1\).
The sequence of cards is sent to
in this order. Thus, a total of \((m+1)+m+m = n+\lfloor n/2 \rfloor \) communications are performed.
Even Case: Majority Voting Protocol with 2m Inputs Where \(m \ge 2\)
Next, for \(n=2m, ~m \ge 2\), we consider to construct an ninput majority voting protocol, called \(\mathrm{gMAJ}_{2m}\), in the same way as for \(n=2m+1\). In this case, we consider two types of majority voting protocols, one computes \(\mathsf {maj}^{m}_{2m}\), and the other computes \(\mathsf {maj}^{m+1}_{2m}\).^{Footnote 7} Suppose that each player \(P_i\) has a binary input \(x_i \in \{0,1\}\) for \(i \in \{0,1, \ldots , 2m1\}\). Basically, we can construct \(\mathrm{gMAJ}_{2m}\) in the same way as for \(\mathrm{gMAJ}_{2m+1}\) in Sect. 4.5, but we need to be careful about how to divide the players into two groups \(\mathcal {P}_{\textsc {l}}\) and \(\mathcal {P}_{\textsc {s}}\). Our construction framework works well if 2m players are divided into \(m+1\) players and \(m1\) players, i.e., \(\mathcal {P}_{\textsc {l}} = m+1\) and \(\mathcal {P}_{\textsc {s}} = m1\). (See Appendix A for details.)
However, suppose that 2m players are divided into two groups so that \(\mathcal {P}_{\textsc {l}} = \mathcal {P}_{\textsc {s}} = m\) holds, i.e., \(P_0,P_1, \ldots , P_{m1} \in \mathcal {P}_{\textsc {l}}\) and \(P_m, P_{m+1}, \ldots ,P_{2m1} \in \mathcal {P}_{\textsc {s}}\). Then, our approach to construct a majority voting protocol does not work well because the minimum requirement for the correctness of \(\mathrm{gMAJ}_{2m}\) cannot be satisfied.
Let us consider the computation of \(\mathsf {maj}^{m}_{2m}\) at first. In this case, the leftmost card of the card sequence cannot be determined uniquely when \(\sum _{i=0}^{m1} x_i = 0\). Concretely, if there exists at least one of players in \(\mathcal {P}_{\textsc {s}}\) inputs 0, i.e., \(\sum _{i=m}^{2m1} x_i < m\), then the leftmost card has to be \(\clubsuit \) (because \(\sum _{i=0}^{2m1} x_i < 0+m = m\)); otherwise, it has to be \(\heartsuit \) (because \(\sum _{i=0}^{2m1} x_i = 0+m = m\)). Since choosing one of \(\clubsuit \) or \(\heartsuit \) does not allow the other condition to be satisfied at the same time, the approach of dividing the players into two groups of equal numbers does not work. Table 17 shows the situation.
Analogously, in the computation of \(\mathsf {maj}^{m+1}_{2m}\), the leftmost card cannot be uniquely determined when \(\sum _{i=0}^{m1} x_i = m\). If all players in \(\mathcal {P}_{\textsc {s}}\) input 0, i.e., \(\sum _{i=m}^{2m1} x_i = 0\), then the leftmost card when \(\sum _{i=0}^{m1} x_i = m\) has to be \(\clubsuit \), otherwise, it has to be \(\heartsuit \). Thus, we cannot achieve both requirements, which results in our construction approach not working well for the case where \(\mathcal {P}_{\textsc {l}} = \mathcal {P}_{\textsc {s}} = m\).
Conclusion
We showed efficient cardbased majority voting protocols under the assumption of private operations. Our threeinput majority voting protocols (called \(\mathrm{MAJ}_{3}\text {wA}\) and \(\mathrm{MAJ}_{3}\)) are implemented by only three cards, whereas previous work requires four cards [7]. \(\mathrm{MAJ}_{3}\text {wA}\) (Protocol 3) uses an AND/XOR/NOR hybrid protocol (Protocol 2) obtained by modifying the AND/OR protocol proposed by Nakai et al. [7]. Our idea of transforming the AND/XOR/NOR protocol to \(\mathrm{MAJ}_{3}\text {wA}\) is to allow Carol to announce her output. To get rid of this extra condition, we proposed \(\mathrm{MAJ}_{3}\) (Protocol 4) that enables us to output the result of majority voting by a card without announcement. In addition, ninput majority voting protocols using n cards (Protocols 6 and 7: called \(\mathrm{gMAJ}_{n}\)) were constructed with combinations of cyclic shifts by deciding a part of the protocol procedures based on the observations of \(\mathrm{MAJ}_{3}\).
Recalling that eight cards are sufficient for realizing threeinput majority voting protocols using shuffle operations [9], the proposed protocols (and Nakai et al.’s protocols [7]) are very efficient thanks to the power of private operations [8]. Proving the optimality of \(\mathrm{MAJ}_{3}\text {wA}\) and \(\mathrm{MAJ}_{3}\) for threeinput majority voting or that of \(\mathrm{gMAJ}_{n}\) for ninput majority voting is important future work. Note that since a (natural) lower bound of the number of cards required to a protocol seems to be the number of bits required for encoding the result (e.g., for the majority voting, the sum of all inputs, i.e., \(\lceil \log _2(n+1) \rceil \)), there also seems to be room for improvements. On the other hand, it is easy to see that the proposed AND/XOR/NOR protocol (Protocol 2) is optimal in terms of the number of cards since three cards are obviously necessary for representing three respective outputs (AND/XOR/NOR) simultaneously.
In this paper, we assume that players are semihonest, and we did not use the announcement, which was used in \(\mathrm{MAJ}_{3}\text {wA}\), in the extended protocol \(\mathrm{gMAJ}_{n}\). However, it could be future work to consider protocols that allow other operations such as the announcement or those in other security settings, e.g., there are malicious players who do not follow the protocol. Furthermore, it is also challenging to propose a method to construct a protocol for any given application by generalizing existing studies’ methods that construct a protocol for a given application.
Notes
In [10], it is shown that any twoinput logical functions can be computed with four cards, which means that four cards are optimal for computing twoinput logical functions using commitmentformat protocols.
In [7, 8], this operation is called private permutation. Private operation is named with nonpermutation operations in mind (e.g., adding/removing cards), but operations that can be realized by private operations can also be realized by private permutations, so they can be considered the same. In the example of adding/removing cards, we can think of the addition/removal as increasing/decreasing the number of cards to be permuted in preputted cards.
Instead of announcing \(a \vee b\), for instance, Carol can show the card indicating \(a \vee b\) from extra cards.
Although this formalization implicitly means that we will consider the case that \(n = \mathcal {P}_{\textsc {l}}+\mathcal {P}_{\textsc {s}}\) is always odd, we finally show a construction for even n by extending the construction for odd n in Sect. 4.6.
\(\mathsf {maj}^{m}_{2m}\) and \(\mathsf {maj}^{m+1}_{2m}\) output different values only when the number of inputs of 0 and that of 1 are equal. The former outputs 1, and the latter outputs 0.
References
den Boer, B.: More efficient matchmaking and satisfiability: the five card trick. In: J. Quisquater, J. Vandewalle (eds.) Proceedings, Lecture Notes in Computer Science, Advances in CryptologyEUROCRYPT ’89, Workshop on the Theory and Application of of Cryptographic Techniques, Houthalen, Belgium, April 10–13, vol. 434, pp. 208–217. Springer (1989). https://doi.org/10.1007/3540468854_23
Koch, A., Walzer, S., Härtel, K.: Cardbased cryptographic protocols using a minimal number of cards. In: T. Iwata, J.H. Cheon (eds.) Proceedings, Part I. Lecture Notes in Computer Science, Advances in CryptologyASIACRYPT 2015–21st International Conference on the Theory and Application of Cryptology and Information Security, Auckland, New Zealand, November 29–December 3, 2015, vol. 9452, pp. 783–807. Springer (2015). https://doi.org/10.1007/9783662487976_32
Manabe, Y., Ono, H.: Secure cardbased cryptographic protocols using private operations against malicious players. In: D. Maimut, A. Oprina, D. Sauveron (eds.) Revised Selected Papers, Lecture Notes in Computer Science, Innovative Security Solutions for Information Technology and Communications13th International Conference, SecITC 2020, Bucharest, Romania, November 19–20, 2020, vol. 12596, pp. 55–70. Springer (2020). https://doi.org/10.1007/9783030692551_5
Marcedone, A., Wen, Z., Shi, E.: Secure dating with four or fewer cards. IACR Cryptol. ePrint Arch. 2015, 1031 (2015). http://eprint.iacr.org/2015/1031
Mizuki, T., Asiedu, I.K., Sone, H.: Voting with a logarithmic number of cards. In: G. Mauri, A. Dennunzio, L. Manzoni, A.E. Porreca (eds.) Proceedings, Lecture Notes in Computer Science, Unconventional Computation and Natural Computation12th International Conference, UCNC 2013, Milan, Italy, July 1–5, 2013. vol. 7956, pp. 162–173. Springer (2013). https://doi.org/10.1007/9783642390746_16
Mizuki, T., Sone, H.: Sixcard secure AND and fourcard secure XOR. In: X. Deng, J.E. Hopcroft, J. Xue (eds.) Proceedings, Lecture Notes in Computer Science, Frontiers in Algorithmic, Third International Workshop, FAW 2009, Hefei, China, June 20–23, 2009, vol. 5598, pp. 358–369. Springer (2009). https://doi.org/10.1007/9783642022708_36
Nakai, T., Shirouchi, S., Iwamoto, M., Ohta, K.: Four cards are sufficient for a cardbased threeinput voting protocol utilizing private permutations. In: J. Shikata (ed.) Proceedings, Lecture Notes in Computer Science, Information Theoretic Security10th International Conference, ICITS 2017, Hong Kong, China, November 29–December 2, 2017, vol. 10681, pp. 153–165. Springer (2017). https://doi.org/10.1007/9783319720890_9
Nakai, T., Tokushige, Y., Misawa, Y., Iwamoto, M., Ohta, K.: Efficient cardbased cryptographic protocols for millionaires’ problem utilizing private permutations. In: S. Foresti, G. Persiano (eds.) Proceedings, Lecture Notes in Computer Science, Cryptology and Network Security15th International Conference, CANS 2016, Milan, Italy, November 14–16, 2016, vol. 10052, pp. 500–517 (2016). https://doi.org/10.1007/9783319489650_30
Nishida, T., Mizuki, T., Sone, H.: Securely computing the threeinput majority function with eight cards. In: A. Dediu, C. MartínVide, B. Truthe, M.A. VegaRodríguez (eds.) Proceedings, Lecture Notes in Computer Science, Theory and Practice of Natural ComputingSecond International Conference, TPNC 2013, Cáceres, Spain, December 3–5, 2013, vol. 8273, pp. 193–204. Springer (2013). https://doi.org/10.1007/9783642450082_16
Ono, H., Manabe, Y.: Cardbased cryptographic logical computations using private operations. New Gener. Comput. 39(1), 19–40 (2021). https://doi.org/10.1007/s0035402000113z
Watanabe, Y., Kuroki, Y., Suzuki, S., Koga, Y., Iwamoto, M., Ohta, K.: Cardbased majority voting protocols with three inputs using three cards. In: International Symposium on Information Theory and Its Applications, ISITA 2018, Singapore, October 28–31, 2018, pp. 218–222. IEEE (2018). https://doi.org/10.23919/ISITA.2018.8664324
Yao, A.C.: Protocols for secure computations (extended abstract). In: 23rd Annual Symposium on Foundations of Computer Science, Chicago, Illinois, USA, 3–5 November 1982, pp. 160–164. IEEE Computer Society (1982). https://doi.org/10.1109/SFCS.1982.38
Author information
Authors and Affiliations
Corresponding author
Additional information
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
A part of this work was done when Yohei Watanabe was at the National Institute of Information and Communications Technology, Japan. This work was supported by JSPS KAKENHI Grant Numbers JP17H01752, JP18H03238, JP18H05289, JP18K11293, JP18K19780, JP20J21248, and JP21H03395.
An Even Case: Majority Voting Protocol with 2m Inputs Where \(m \ge 2\)
An Even Case: Majority Voting Protocol with 2m Inputs Where \(m \ge 2\)
For \(n=2m, ~m \ge 2\), we construct a ninput majority voting protocol in the same way as for \(n=2m+1\). In this case, we propose two types of majority voting protocol, one computes \(\mathsf {maj}^{m}_{2m}\), and the other computes \(\mathsf {maj}^{m+1}_{2m}\). Suppose that each player \(P_i\) has a binary input \(x_i \in \{0,1\}\) for \(i \in \{0,1, \ldots , 2m1\}\) and let \(\mathcal {P}_{\textsc {l}}:= \{P_0, P_1,\ldots , P_{m}\}\) and \(\mathcal {P}_{\textsc {s}}:= \{P_{m+1},P_{m+2},\ldots , P_{2m1}\}\).
We assume \(\mathrm{gMAJ}_{2m}\)’s procedure as follows. Moreover, we assume that \(n~(=2m)\) cards are used.

Placement phase: All of n cards are (publicly) placed face down in some order, and players \(P_i \in \mathcal {P}_{\textsc {l}}\) perform private operations to generate a sequence of cards depending on their inputs.

Permutation phase:

Permutation phase 1: Each player \(P_i \in \mathcal {P}_{\textsc {s}}\ (i \in \{m+1,\ldots , 2m1\})\) performs the left cyclic shift over \(n1 \ (= 2m1)\) cards on the right as the private operation \(\mathsf {op}_{\textsc {s}}\) if \(x_i = 0\).

Permutation phase 2: Each player \(P_i \in \mathcal {P}_{\textsc {l}}\ (i \in \{0,\ldots , m+1\}\) performs the left cyclic shift over \(m+1\) cards on the left as the private operation \(\mathsf {op}_{\textsc {l}}\) if \(x_i = 0\).


Output phase: The protocol outputs the leftmost card of the card sequence.
Then, based on the construction idea in Sect. 4.4, the card sequences after the placement phase and the minimum requirement for computing \(\mathsf {maj}^{m}_{2m}\) (or \(\mathsf {maj}^{m+1}_{2m}\)) correctly can be represented as shown in Tables 18 and 19, respectively.
To specify the cards at the nonoutput positions in the sequences of cards after the placement phase, let us assume that m cards from the right are the same regardless of \(\mathcal {P}_{\textsc {l}}\). Then, m cards from the left can be considered to sequences of cards obtained by \(\sum _{i=0}^{m} x_i\) times left cyclic shift over the m cards \(\clubsuit \overbrace{\heartsuit \cdots \heartsuit }^{m1}\). Actually, by performing the operations, \(\clubsuit \) appears at the \(((m\sum _{i=0}^{m} x_i) \bmod m)\)th leftmost place in the sequence and other places are filled by \(\heartsuit \). We can see that such a sequence satisfies the requirement shown in Table 19. Therefore, the specified sequences of cards and constructed protocol become as shown in Table 20 and Protocol 7, respectively.
A.1 Number of Cards, Private Operations, and Communication Required in \(\mathrm{gMAJ}_{2m}\) (Protocol 7).
\(\mathrm{gMAJ}_{2m}\) is executable with m cards and m cards for computing \(\mathsf {maj}^{m}_{2m}\), or \(m+1\) cards and \(m1\) cards for computing \(\mathsf {maj}^{m+1}_{2m}\). In either case, \(m+m = (m+1) + (m1) = n\) cards are required.
Then, \(m+1\), \(m1\), and \(m+1\) players perform a private operation in Step 1), 2), and 3), respectively. Therefore, the number of private operations is \((m+1) + (m1) + (m+1) = n + \lfloor n/2 \rfloor + 1\).
The sequence of cards is sent to
in this order. Thus, a total of \((m+1)+(m1)+m = n+\lfloor n/2 \rfloor \) communications are performed.
Rights and permissions
This article is published under an open access license. Please check the 'Copyright Information' section either on this page or in the PDF for details of this license and what reuse is permitted. If your intended use exceeds what is permitted by the license or if you are unable to locate the licence and reuse information, please contact the Rights and Permissions team.
About this article
Cite this article
Abe, Y., Nakai, T., Kuroki, Y. et al. Efficient CardBased Majority Voting Protocols. New Gener. Comput. 40, 173–198 (2022). https://doi.org/10.1007/s00354022001617
Received:
Accepted:
Published:
Issue Date:
DOI: https://doi.org/10.1007/s00354022001617
Keywords
 Multiparty computation
 Cardbased cryptography
 Private operation
 Majority voting protocol
Mathematics Subject Classification
 94A60