Card-Based Cryptographic Protocols with Malicious Players Using Private Operations

This paper shows new card-based cryptographic protocols using private operations that are secure against malicious players. Physical cards are used in card-based cryptographic protocols instead of computers. Operations that a player executes in a place where the other players cannot see are called private operations. Using several private operations, calculations of two variable Boolean functions and copy operations were realized with the minimum number of cards. Though private operations are very powerful in card-based cryptographic protocols, there is a problem that it is very hard to prevent malicious actions during private operations. Though most card-based protocols are discussed in the semi-honest model, there might be cases when the semi-honest model is not enough. Thus, this paper shows new protocols that are secure against malicious players. We show logical XOR, logical AND, n-variable Boolean function, and copy protocols. We can execute any logical computations with a combination of these protocols. We use envelopes as an additional tool that can be easily prepared and used by people.

Operations that a player executes in a place where the other players cannot see are called private operations. These operations are considered to be executed under the table or in the back. Private operations are shown to be the most powerful primitives in card-based cryptographic protocols. They were first introduced to solve millionaires' problem [40]. Using three private operations called private random bisection cuts, private reverse cuts, and private reveals, committed-input and committed-output logical AND, logical XOR, and copy protocols can be achieved with the minimum number of cards [48]. Another class of private operations is private input operations that are used when a player inputs a private value [20,47,65]. These operations are not discussed in this paper since it is impossible to prevent false input from a malicious player. If the input values are honestly given, the players can use the protocols shown in this paper.
The largest problem of protocols using private operations is malicious actions. Most of the card-based protocols assume the semi-honest model, in which the players obey the rule of the protocols but try to obtain private information. However, there are many cases when we must consider the malicious model. When we allow malicious actions, protocols using private operations are not secure. Since private operations are executed where the other player cannot see, any malicious operation is possible during the private operations, for example, watching the marks of face-down cards or changing the positions of cards.
One countermeasure to malicious actions is setting a watch person. When the protocols are executed by more than two players, it is possible to detect malicious actions by the following rule: whenever a player executes a private operation, another player watches the execution and reports incorrect behavior. The XOR, AND, and copy protocols can be executed securely against a malicious player when the protocols are executed by more than two players [48]. However, when the protocols are executed by two players, Alice and Bob, it is impossible to use the above method. If Bob watches Alice's private operations, Bob knows all operations; thus, the relation between input data and output data is known to Bob. When the output card is opened, the secure input data are known to Bob using the relation between the input data and the output data.
Thus we need new protocols for the two-player case. Since Bob cannot watch Alice's private operations, some additional mechanism is necessary to prevent illegally watching the marks of face-down cards during private operations. This paper introduces envelopes to prevent illegally watching the marks of face-down cards. Cards that must not be seen are publicly put into an envelope. If an envelope is illegally opened, it can be detected by anyone. Envelopes are used in [38] to realize cryptographic protocols that do not use physical cards. In card-based cryptographic protocols, envelopes are used in [8,45,58,63] to realize some kind of shuffles that are not easy to be executed by people.
This paper shows new card-based cryptographic protocols that are secure against malicious players using envelopes as an additional tool. Some malicious actions during private operations are prevented by adding extra cards for error correction. We show logical XOR, logical AND, n-variable Boolean function, and copy protocols since any logical functions can be obtained with a combination of these protocols.
As related works, protocols that use additional cards and prevent active attacks while a player executes a shuffle were shown [17]. The private operations used in the protocol are private shuffles; thus, the method does not consider the other types of private operations. This paper considers the other types of malicious actions in the protocols that use private operations. Another type of active attack is inputting a false value that is not 0 or 1. A protocol to detect such injection attacks was discussed in [35]. This paper assumes correct inputs since we need to consider input x instead of correct input x but it is impossible to prevent or detect.
Protocols that prevent revealing face-down cards were discussed in [67]. The protocol uses the technique of secret-sharing to prevent information leakage by opening some numbers of cards. The protocol cannot be applied to the problem discussed in this paper since a malicious player might reveal all cards during a private operation.
Another usage of private operations is realizing a public shuffle by multiple private shuffles [37]. The protocols cannot be used as it is to solve the problem in this paper since a malicious player might not honestly execute a private shuffle. Preventing malicious actions for the protocols that use private random bisection cuts, private reverse cuts, and private reveals are not considered.
A protocol to detect malicious actions by executing two instances of a protocol and comparing the results was shown [60]. The protocol uses cases to prevent revealing face-down cards. The functionality of cases is just the same as envelopes in this paper. The protocol uses twice as many cards as the original protocols and it is impossible to correct some malicious actions. This paper's protocols use a smaller number of cards and can correct some malicious actions.
In Sect. 2, basic notations, the private operations introduced in [48], and notations related to the envelopes are shown. Section 3 shows the security model. Section 4 shows new protocols to prevent or detect malicious operations. Section 5 concludes the paper. The difference from the conference version [22] is as follows: (1) We updated all protocols to clarify the procedure to detect malicious actions. (2) We added a new protocol to calculate any n-variable Boolean functions. (3) We added formal descriptions of the protocols that output multiple copies of the output value and obtain multiple copies of an input value.

Basic Notations
This section gives the notations and basic definitions of card-based protocols. This paper is based on a standard two-color card model. In the two-color card model, there are two kinds of marks, and . Cards of the same marks cannot be distinguished. In addition, the back of both types of cards is . It is impossible to determine the mark on the back of a given card of .
One-bit data are represented by two cards as follows: = 0 and = 1. One pair of cards that represents one bit x ∈ {0, 1} , whose face is down, is called a commitment of x , and denoted as commit(x ). It is written as . For a pair of cards, exchanging the position of the left card and the right card is called a swap. Note that when two cards of commit(x ) are swapped, commit(x) can be obtained. Thus, logical negation can be calculated without private operations. A set of cards placed in a row is called a sequence of cards. A sequence of cards S whose length is n is denoted as S = s 1 , s 2 , … , s n , where s i is i-th card of the sequence.
. A sequence whose length is even is called an even sequence. S 1 ||S 2 is a concatenation of sequence S 1 and S 2 . For two sequences of cards S 1 and S 2 ( |S 1 | = |S 2 | ) that are put left and right, swapping S 1 and S 2 means exchanging the position of the two sequences. All protocols are executed by two players, Alice and Bob. The players might be malicious, that is, they might not obey the rule of the protocol. There is no collusion between Alice and Bob, otherwise private input data can be easily revealed.
Throughout this paper, we assume that each input is given as a committed value. The output must also be given as a committed value so that the output can be used as an input to further computations. Though some multi-party secure calculation protocols assume that each player knows his/her private input, there are some cases when we cannot assume that. For example, suppose that x 1 , x 2 are Alice's private input values and y 1 , y 2 are Bob's private input values and they want to securely calculate (x 1 ∨ y 1 ) ∧ (x 2 ∨ y 2 ) . After commit(x 1 ∨ y 1 ) and commit(x 2 ∨ y 2 ) are calculated, they need to calculate logical AND of two secret values. Thus, we need to calculate the logical functions of two committed inputs. Note that committed-input protocols can be used even when a player knows some inputs. For example, if Alice knows input value x , she first commits her input as commit(x ). Then the committed-input protocol can be executed.

Private Operations
We show three private operations introduced in [48]: private random bisection cuts, private reverse cuts, and private reveals.
Primitive 1 (Private random bisection cut) A private random bisection cut is the following operation on an even sequence S 0 = s 1 , s 2 , … , s 2m . A player selects a random bit b ∈ {0, 1} and outputs The player executes this operation in a place where the other players cannot see. The player must not disclose the bit b.
Note that if the private random cut is executed when m = 1 and S 0 = commit(x) ,

given
, the player's output , which is or .
We sometimes write the result of the private random bisection cut using a bit b to a sequence Primitive 2 (Private reverse cut, Private reverse selection) A private reverse cut is the following operation on an even sequence S 2 = s 1 , s 2 , … , s 2m and a bit b ∈ {0, 1} . A player outputs The player executes this operation in a place where the other players cannot see. The player must not disclose b.
Note that the bit b is not newly selected by the player. This is the difference between the primitive in Primitive 1, where a random bit must be newly selected by the player.
Note that in some protocols below, selecting left m cards is executed after a private reverse cut. The sequence of these two operations is called a private reverse selection. A private reverse selection is the following procedure on an even sequence S 2 = s 1 , s 2 , … , s 2m and a bit b ∈ {0, 1} . A player outputs Primitive 3 (Private reveal) A player privately opens a given committed bit. The player must not disclose the obtained value.
Using the obtained value, the player privately sets a sequence of cards. Consider the case when Alice executes a private random bisection cut on commit (x ) and Bob executes a private reveal on the bit. Since the committed bit is randomized by the bit b selected by Alice, the opened bit is x ⊕ b . Even if Bob privately opens the cards, Bob obtains no information about x if b is randomly selected and not disclosed by Alice. Bob must not disclose the obtained value. If Bob discloses the obtained value to Alice, Alice knows the value of the committed bit.

Space and Time Complexities
The space complexity of card-based protocols is evaluated by the number of cards. Minimizing the number of cards is discussed in many works.
The number of rounds was proposed as a criterion to evaluate the time complexity of card-based protocols using private operations [49]. The first round begins from the initial state. The first round is (possibly parallel) local executions by each player using the cards initially given to each player. It ends at the instant when no further local execution is possible without receiving cards from another player. The local executions in each round include sending cards to some other players but do not include receiving cards. The result of every private execution is known to the player. For example, shuffling whose result is unknown to the player him/herself is not executed. Since the private operations are executed in a place where the other players cannot see, it is hard to force the player to execute such operations whose result is unknown to the player. The i(> 1)-th round begins with receiving all the cards sent during the (i − 1)-th round. Each player executes local executions using the received cards and the cards left to the player at the end of the (i − 1)-th round. Each player executes local executions until no further local execution is possible without receiving cards from another player. The number of rounds of a protocol is the maximum number of rounds necessary to output the result among all possible inputs and random values.
Let us show an example of a protocol execution and its space complexity and time complexity.
1. Alice executes a private random bisection cut on commit(x ). Let the output be commit(x � ) . Alice sends commit(x � ) and commit(y ) to Bob. 2. Bob executes a private reveal on commit(x � ) . Bob sets and sends S 2 to Alice.
3. Alice executes a private reverse selection on S 2 using the bit b generated in the private random bisection cut. Let the obtained sequence be S 3 . Alice outputs S 3 .
The correctness of the protocol is shown in [48]. The number of cards is four, since the cards of commit(x � ) are re-used to set commit(0).
The first round ends at the instant when Alice sends commit(x � ) and commit(y ) to Bob. The second round begins at receiving the cards by Bob. The second round ends at the instant when Bob sends S 2 to Alice. The third round begins at receiving the cards by Alice. The number of rounds of this protocol is three.
Since each operation is relatively simple, the dominating time to execute protocols with private operations is the time to send cards between players and set up so that the cards are not seen by the other players. Thus, the number of rounds is the criterion to evaluate the time complexity of card-based protocols with private operations.

Malicious Actions During Private Operations
We show examples of cheats by a malicious player for the AND protocol shown in Protocol 1. In the first round, Alice may reveal the cards of commit(x ) (and/or commit(y )) and read the secret input value x (and/or y , respectively). Alice might swap the two cards of commit(x ) (and/or commit(y )) and use x (and/or ȳ , respectively) as the input value. In the second round, Bob might reveal the cards of commit (y ) and read the secret input value y . Bob might set the cards incorrectly, for example, set then the result becomes x ∨ y instead of x ∧ y . Bob can set any other card sequences to obtain other incorrect results. In the third round, Alice might execute a private reverse selection using a value b � (≠ b) . Alice might reveal all the cards and see the values. To make the protocol secure against malicious players, all of the above cheats must be prohibited or detected.

Envelopes
We need to prevent malicious reveal of committed input values. In the following protocols, we use envelopes as an additional tool. The cards can be put into an envelope and sealed. Opening the sealed envelope can be easily detected by anyone. Thus, a malicious player cannot irregularly open envelopes during private operations because it is detected by the other player. It is impossible to distinguish between two envelopes. No player can prepare the same envelopes in his/her pocket and exchange them for the envelopes used in the protocol. Such envelopes are used in some cardbased protocols [8,45,58,63].
We show some basic operations and notations related to the envelopes. The order of the cards put into an envelope is preserved when the cards are removed. For example, a card sequence S is put into an envelope, the output card sequence from the envelope must also be S . In the following protocols, two envelopes, the left and the right envelope are used. Swapping the right and left envelopes is exchanging the positions of the two envelopes. We use the following notation [⋅] for the representation of the state of two envelopes.
[⋅] means the sequence of cards when the cards are removed from the two envelopes by the same order of insertion. Note that in any case, the numbers of cards in the left and the right envelopes are the same. There are two types of insertion of cards. The first type is each one card from the two cards representing one bit is stored to the left and right envelope. One bit data is represented by two cards, for example, suppose that the card sequence s 1 , s 2 is commit(x ). s 1 is put into the left envelope and s 2 is put into the right envelope. When the cards are removed from the two envelopes by the same order of insertion, we can obtain commit(x ). The status of the two envelopes is represented as [ commit(x)], since commit(x ) is obtained when the cards are removed. Now, consider the case that the left and the right envelopes are swapped. When the cards are removed from the two envelopes by the same order of the insertion, the card sequence becomes s 2 , s 1 , thus commit(x) is obtained, as shown in Fig. 1. The status of the swapped two envelopes is written as The other type of insertion is putting a pair of cards to each of the envelopes. When we insert S = t 1 , t 2 to the left envelope and S � = t 3 , t 4 to the right envelope, the status of the two envelopes is written as [S||S � ] , since we can obtain S||S ′ when we remove the cards from the envelopes. When we swap the two envelopes, the status of the two envelopes is changed as [S � ||S] , because we obtain S ′ ||S when the cards are removed from the envelopes by the same order of the insertion, as shown in Fig. 2.
The above two types of insertions can be executed to a single pair of envelopes. Such combination is represented using a comma in [⋅] . For example, the left (right) cards of commit(x ) and commit(y ) are inserted to the left (right) envelope, respectively, and then S(S � ) is inserted to the left (right) envelope, respectively. The status of the two envelopes is written as [ commit(x), commit(y), S||S � ] . When we swap the two envelopes, the status is changed to [commit(x), commit(ȳ), S � ||S].
In this paper, private random bisection cuts are executed to these two envelopes. When Alice executes a private random bisection cut to the two enve- is the random bit selected by Alice. When Alice executes a private random bisection cut to the two envelopes that have [commit(x), A private reveal by a player on an envelope means that the player opens the envelope, obtains a sequence of face-down cards, turns the face-down cards, and sees the marks of the cards.

Security Model
This section first shows the possible malicious actions during protocol executions. Then, we show some additional assumptions related to security.
With the envelopes, the activities by a malicious player are as follows when the private primitives are private random bisection cuts, private reverse cuts, and private reveals on the envelopes.  -When a malicious player executes a private random bisection cut to two sets of envelopes A and B using the same random bit, he/she can use different bits to A and B. -When a malicious player executes a private reveal on envelope A , he/she can open another envelope B . Also, he/she might not place envelopes according to the opened cards. -When a malicious player executes a private reverse cut using a bit b , he/she Since there is no collusion of the two players, the public operations executed by both players together are correctly executed even if both players are malicious.
During the execution of a protocol, a player might find the other player's misbehavior. We need to define the malicious player's action about the detection of the other player's misbehavior.
Assumption 2 (Misbehavior detection). A malicious player does not suppress to claim the other player's misbehavior.
As shown in the next section, an incorrect result might be obtained if a malicious player does not claim the other malicious player's misbehavior.
We add an assumption that for at least one input, say, x multiple copies of commit(x ) are given as input. The reason for this assumption is as follows. When a player, say, Alice is given commit(x ) and executes a private operation, there is no way for the other player to detect whether Alice maliciously executed swapping two cards of commit(x ) and made commit(x) . Since Bob does not know x , Bob cannot claim that x is used instead of x . To detect this type of malicious operation, another copy of commit(x ) must be given. Using the copy of commit (x ), Bob can detect that Alice irregularly swapped commit(x ), as shown in the protocols in this paper. Note that a method to obtain multiple copies of inputs using envelopes is shown in Sect. 4.4.

Secure Protocols Under Malicious Model
This section shows our new protocols that are secure against malicious behavior.

XOR Protocol
First, we show an XOR protocol. Note that two copies of one input, commit(x ), are necessary to prevent malicious actions.

Protocol 2 (XOR protocol)
Input: two copies of commit(x ) and one copy of commit(y). Output: commit(x ⊕ y) .
is the output of the protocol. If S � 2 = 1 , swap the left and the right card of S ′′ 2 and the result is the output of the protocol (Fig. 3d).
The protocol is three rounds. The first round is the public execution by Alice and Bob. Note that the public operations can be executed by a player say, Alice, in front of the other player, Bob.
The second round is executed by Alice. The third round is executed by Bob. The last public executions at Step 4 by Alice and Bob do not need sending envelopes. Bob just makes the envelopes public and Bob can execute the operations in front of Alice. Thus no overhead is necessary for the public execution. Therefore, the number of rounds is considered to be three. The number of cards used in the protocol is six.
From Assumption 1, the malicious activities in this protocol are the follows.
Since S � 2 = commit(0) , S ′′ 2 is not swapped and the output is commit(x ⊕ y) . Therefore, the output is correct. The protocol is secure since Alice sees S � 2 = 0 and Bob sees S � 2 = 0 and S 1 = x ⊕ b but b is an unknown random value for Bob.
Next, consider the case when Alice is malicious and Bob is honest. If Alice opens an envelope during the private operation, Bob can detect misbehavior. Next, consider the case when Alice does not execute the private random bisection cut correctly. Since the numbers of cards The result is correct regardless of the selection of b and b ′ . The protocol is secure in this case since Alice sees S � 2 = b ⊕ b � and Bob sees S � 2 = b ⊕ b � and S 1 = x ⊕ b but b is an unknown random value for Bob.
Next, consider the case when Alice is honest or malicious and Bob is malicious. Alice might incorrectly execute the private random bisection cuts using b and b ′ as in the above case. The other cheats such as irregularly opening envelopes and making incorrect pairs of envelopes are detected by Bob as shown above.
In this case, the result is and the result is correct. The protocol is secure in this case since Alice sees S � 2 = b ⊕ b � ⊕ 1 and Bob sees S � Note that the protocol achieves an error correction. Even if Alice and/or Bob make mistakes in swapping the left and the right of paired envelopes, the mistakes are automatically corrected. Consider a mistake by Alice when she executes a private random bisection cut on [ commit(

x )] and [ commit(x), commit(y)], that is, she swapped [ commit(x )] but did not swap [ commit(x), commit(y )] (or did not swap [ commit(x )] but swapped [ commit(x), commit(y)]).
The situation is just the same when malicious Alice used different b and b ′ to swap the pairs. The other mistake by Bob is at Step 3, Bob did not swap the two envelopes of [S � 1 , S �� 1 ] when x � = 1 (or swapped [S � 1 , S �� 1 ] when x � = 0 ). The situation is just the same when malicious Bob executed a false swap. Since the result is correct even with the malicious actions, these errors are corrected.
Note that a malicious player can output a false misbehavior detection even if the other player is honest. For example, at Step Step 3, Bob does not claim that Alice opened the envelopes and continues the protocol. Then the output of the protocol is commit(x ⊕ȳ) . This case is just the same as the case when Alice and Bob collude. Thus, Assumption 2 is necessary.
Note that there can be cases when both of the players are independently malicious. Let us consider the following case. Alice knows the secret value x and y by some irregular means in advance. Bob does not know the fact. Malicious Alice knows the correct value of x ⊕ y and wants Bob to obtain a false result. On the other hand, Bob independently knows the secret value x and y by some other irregular means in advance. Alice dose not know the fact. Malicious Bob wants Alice to obtain a false result. Even in this case, when the protocol is terminated, the result is correct, that is, the two independent malicious actions become void.

AND Protocol
Next, we show an AND protocol that uses envelopes.

Protocol 3 (AND protocol)
Input: two copies of commit(x ) and one copy of commit(x). Output: commit(x ∧ y) . Step 3 and terminates the protocol. Otherwise, they obtain S ′ 2 and S ′′ 2 . They turn (that is, face-up) S ′ 2 . If S � 2 = 0 , the left two cards of S ′′ 2 are the output of the protocol. If S � 2 = 1 , the right two cards of S ′′ 2 are the output of the protocol (Fig. 4d).
The protocol is three rounds. The protocol uses eight cards since two new cards are used to set commit(0).
From Assumption 1, the malicious activities in this protocol are the follows. ). All of these malicious activities must be prevented or detected.

Theorem 2 The output of the AND protocol is correct if the protocol is not terminated during execution even if Alice and/or Bob are malicious. The protocol does not reveal the input values to the players if the protocol is not terminated during execution.
Proof The desired output can be represented as follows.
First, we show the correctness when both Alice and Bob are honest. swap(x, commit(0)||commit(y))] . Thus the players select the left pair of swap(x, commit(0)||commit(y)) . The selected cards are if x = 1 and commit(0) if x = 0 . Thus, the output is correct.
The protocol is secure since Alice sees S � 2 = 0 and Bob sees S � 2 = 0 and S 1 = x ⊕ b but b is an unknown random value for Bob.
Next, consider the case when Alice is malicious and Bob is honest. If Alice opens an envelope during the private operation, Bob can detect misbehavior. Next, consider the case when Alice does not execute the private random bisection cut correctly. Since the numbers of cards 2 ) and select the left pair. Since (0)||commit(y))) = swap (x, commit(0)||commit(y)) , the output is commit(0 ) if x = 0 , otherwise the output is commit(y ). Therefore, the output is correct regardless of the selection of b and b ′ .
The protocol is secure in this case since Alice sees S � 2 = b ⊕ b � and Bob sees S � 2 = b ⊕ b � and S 1 = x ⊕ b but b is an unknown random value for Bob. Next, consider the case when Alice is honest or malicious and Bob is malicious. Alice might incorrectly execute the private random bisection cuts using b and b ′ as in the above case. If Bob opens an envelope of [S � 1 , S �� 1 ] , the cheat can be detected by Alice. If Bob makes an incorrect pair of envelopes (for example, the left envelope of

commit(y)
= swap(x, commit(0)||commit(y)) , the output is commit(0) if x = 0 , otherwise the output is commit(y). Therefore, the output is correct regardless of the selection of b and b ′ . The protocol is secure in this case since Alice sees S � 2 = b ⊕ b � ⊕ 1 and Bob sees is an unknown random value for Bob. ◻ Note that even if Alice and/or Bob make mistakes in swapping the left and the right of paired envelopes, the mistakes are automatically corrected. The reason is just the same as the one for the XOR protocol.
Note that using an argument similar to the one in [48], any 2-variable Boolean function can be calculated by a protocol similar to the XOR protocol or the AND protocol.

n-variable Boolean Functions
We show a protocol that calculates any n-variable Boolean function f (x 1 , x 2 , … , x n ).
From Assumption 1, the malicious activities in this protocol are the follows. At Step 1, Step 2 (a), and Step 2 (d), there are no malicious activities because the operations are publicly executed by the two players. At Step 2  ). All of these malicious activities must be prevented or detected.
The correctness of the protocol is shown as follows.

Multiple Output Protocol
Multiple copies of output data of computation might be needed in some cases. For example, consider the case when we calculate w = (x ⊕ y) ∧ (x � ⊕ y � ) . We calculate z = x ⊕ y , z � = x � ⊕ y � , and then w = z ∧ z � . To calculate w , two copies of output value z are necessary at calculating z = x ⊕ y . Thus, multiple output protocols are necessary. A method to obtain m(> 1) copies of the output is preparing m copies of commit(y ). We show XOR and AND protocols that output multiple copies of the result.

Protocol 5 (multiple output XOR protocol)
Input: two copies of commit(x ) and m(> 1) copies of commit(y). Output: m copies of commit(x ⊕ y). The differences from Protocol 2 are as follows: Step 1: Alice and Bob publicly put cards of one commit(x ) and m commit(y ) into two envelopes. The left (right) cards of commit(x ) and m copies of commit (y ) are put into the left (right) envelope, respectively. The two envelopes have [commit(x), commit(y), commit(y), … , commit(y)] . The remaining commit(x ) is put into two new envelopes as in Protocol 2.
The proof of correctness and security is just the same as the one for Protocol 2.

Protocol 6 (multiple output AND protocol)
Input: two copies of commit ( x ) and m(> 1) copies of commit(y). Output: m copies of commit(x ∧ y). The differences from Protocol 3 are as follows: Step 1: Alice and Bob publicly put cards of one commit(x ) and m commit (y ) and commit(0 ) into two envelopes. The left card of commit(x ) and m copies of commit(0 ) are put into the left envelope. The right card of commit(x ) and m copies of commit(y ) are put into the right envelope. The two envelopes have [commit(x), commit(0)||commit(0)|| … ||commit(0)||commit(y)||commit(y)|| … ||commit(y)] . The remaining commit(x ) is put into two new envelopes as in Protocol 3.
The proof of correctness and security is just the same as the one for Protocol 3.
We can obtain an n-variable Boolean function calculation protocol that outputs m copies using the same idea using 4n + 2 n+1 m cards.
There might be some cases when the number of necessary copies of some value is changed during execution. For example, the players securely calculate Boolean function z, f 0 , and f 1 . The intermediate result z is opened, which is 0 or 1. Next, the players need to calculate f z ∧ y i (i = 1, … , n) . Since many copies of f 0 (f 1 ) are necessary only if z = 0(z = 1) respectively, preparing many copies of f 0 and f 1 in advance is wasteful. In such cases, a copy protocol is used during execution. We show another protocol that directly increases the number of copies of input data using the XOR protocol.

Protocol 7 (copy protocol)
Input: two copies of commit(x). Output: m(> 2) copies of commit(x). Execute Protocol 5 with input x and m copies of y = 0.
Since x ⊕ 0 = x , m copies of x are obtained. Last, we show a method to obtain multiple copies of input x using envelopes.

Protocol 8 (multiple input protocol)
Input: m(> 1) cards and m cards. Output: m copies of commit(x ).
1. The players publicly put m face-down ( ) cards into the left (right) envelope, respectively.
2. The input player who has the private input value x privately swaps the two envelopes if x = 1 , otherwise, does nothing. The input player makes the two envelopes public. 3. A player claims that the input player misbehaved and terminates the protocol if an envelope is opened. The players open the envelopes together. Two piles of face-down cards are obtained. When the players select one card from each of the piles, a copy of commit(x ) can be obtained, thus m copies of commit(x ) can be obtained.
Note that a malicious input player might input x instead of x , but it is impossible to prevent such a cheat since no other player knows the secret value x.
When we calculate general logical functions using XOR, AND, and copy protocols, we need to prepare two copies of each input. Any number of copies of a value can be obtained by using the copy protocol at any time, if there are two copies of each value. Obtaining two copies of an intermediate output value can be realized by the above protocols; thus, any logical functions can be calculated securely using these protocols.

Conclusion
This paper proposed new protocols using private operations that are secure against malicious players. We show logical XOR, logical AND, copy, and n-variable Boolean function calculation protocols that use envelopes as an additional tool. Since the envelopes are a very powerful tool to restrict swap executions, some malicious executions are corrected in the protocols.
We can consider weak tools for preventing the illegal opening of face-down cards, for example, seals on the marks of the cards. They cannot restrict swap executions.
One of the open problems is considering secure protocols with such weak tools.