Abstract
In an st-price auction, all bidders submit their bids simultaneously, and the highest bidders purchase identical goods at the st bidding price. Previous research is constructed based on trusted managers such as a trusted third party (TTP), trusted mix servers, and honest managers. All of the previous auctions are not fit for edge-assisted IoT since they need TTP. In this paper, we formalize a notion of commutative bi-homomorphic multiparty encryption and achieve no-TTP -st auction based on blockchain with public verifiability. Our st auction guarantees financial fairness, robustness, and correctness without TTP and is secure under a malicious model for the first time. Our st auction can be executed over a distributed network and is thus fit for edge-assisted IoT. Furthermore, our formalized commutative bi-homomorphic multiparty encryption can be used in various applications for edge-assisted IoT, which needs to protect privacy and correctness.
1. Introduction
Since the introduction of Ethereum [1], a smart contract has become a robust decentralized execution environment for many applications. A variety of applications have been built on Ethereum. For example, cryptocurrency wallets, decentralized markets, and games are just a few examples. In this paper, we study secure auctions as an example of smart contracts.
Vickrey auction is also called second-price auction. In a second-price auction, the bidder who placed the highest bid only needs to pay the second-highest bidding price for the goods. Except for the identity of the highest bidder and the second-highest price, all other information is kept a secret. A 2nd-price auction is a type of sealed-bid auction. In a sealed-bid auction, bidders submit written bids without knowing other bidders’ bids.
st-price auction is an extension of second-price auction. In st-price auction, there are identical goods. The bidders who placed top bids only need to pay the st bidding price for the goods. Ideally, all information except the st price and the bidders who placed the highest bids are kept as a secret. Figure 1 shows an example of st auction for goods. The top two bidders and can buy the goods by . Except the boxed information, all other information is kept as a secret. Table 1 shows the public and secret information in a st-price auction.
There are many applications using IoT devices such as smart agriculture [2], smart grid [3], and raw materials [4], all of which will use price decision procedures. In the price decision procedures, the second-price auction is said to be a method that reflects market prices and is used in various situations. The st auction is the second-price auction that deals with products. This is why st auctions are exactly one of the important applications since they can use products at once.
To achieve a secure M + 1st auction, there are two main issues: correctness and public verifiability. Usually, correctness and public verifiability are realized by using trusted third party (TTP) as an auctioneer and mix and match [5]. Abe and Suzuki [6] introduced one of the first auction protocols based on homomorphic encryption. The bidding price is a bounded range. Bidders can only choose one bid from this pricing list. Many related research studies [7, 8] have a similar design such that the time or communication complexity is related to the length of the bidding price list . To solve this problem, Mitsunaga et al. [9] proposed a scheme that uses a binary format to represent bidding vectors. This improvement reduced the time complexity to . In this research, instead of further improving complexity, we focus on removing the trusted parties, such as manager and mix servers. Based on Abe and Suzuki’s scheme [6], we removed TTP by letting bidders collaboratively act as managers and mix servers. This strategy can also be used in follow-up research studies [7–9]. In our preliminary version of [10], we construct a verifiable st-price auction without manager. In the journal version, we implement the smart contract and reduce the computation cost by using elliptic curve cryptography.
Auctioneer in a sealed-bid auction is usually a trusted person since he can see the secret information. To construct a scheme that no party, such as manager, bidder, smart contract, and trusted third party (TTP), knows secret information, a typical method is to divide a function of manager into two independent parties as in [7]. In their scheme, no single managers or bidders know this secret information. However, this scheme is based on the th root problem, which causes high time complexity and requires massive memory usage by public parameters and bid values.
Mix and match [5] is widely used in auction protocols such as bit-slice-based auction [9, 11, 12] as well as [6] to verify if each encrypted bit is either or . Mix and match can be divided into mix phase and match phase. The mix phase is based on mix net [13, 14] to shuffle a set of encrypted messages. The match phase is usually based on zero-knowledge proofs to prove that the encrypted message is in the shuffled set. Mix net not only relied on TTP but also increased communication costs. In summary, previous schemes need TTP.
1.1. Our Contribution
We proposed a secure st auction, which satisfies the following features:(1)Multiparty encryption: our multiparty encryption is asynchronous. The order of decryption does not depend on the order of encryption, which makes the decryption asynchronous for the decryptors. So, decryptors do not need to wait for each other.(2)Publicly verifiablest auction: our st auction does not use mix and match in bid verification phase and does not use TTP in the whole protocol.(a)No mix and match protocol in bid verification: our protocol does not rely on mix and match unlike [6, 9, 11, 12]. Our new approach can also be used on bit-slice-based auction protocols [9, 11, 12] and all other auction protocols, which is based on encrypted bits.(b)No TTP: in the st-price decision phase, we modify mix and match by letting bidders act as mix servers, and thus no trusted mix server is used. Our st-price auction is secure under a malicious model that guarantees financial fairness, robustness, and correctness without any other party such as manager and TTP. We remark that our scheme can be operated without TTP, and thus any bidder can start auction freely by using their IoT devices. Our decentralized auction exactly fits for IoT environment.
This paper is organized as follows. We introduce the related studies on smart contract auction protocols in Section 2 and explain cryptographic backgrounds in Section 3. We propose an efficient and secure M + 1st-price auction protocol in Section 4 and compare our work with the related works in Section 6. Finally, we conclude our work in Section 7.
2. Related Work
This section reviews previous auction protocols which use a smart contract.
2.1. Overview of Auction
We define necessary features for auction protocol(i)Bid binding: bidders cannot change their bidding price after the bid submission phase is closed.(ii)Bid secrecy: all bidding prices except the st-price should be kept secret.(iii)Bidder anonymity: except for the winning bidder, the identity of other bidders, including the bidder who placed the st-price, is kept secret.(iv)Manager-based secrecy and anonymity: except those explained above, all secrets are also disclosed to the manager.(v)Posterior secrecy and anonymity: all secrets can be a secret even after the auction.(vi)Robustness: malicious behaviors in each phase can be found immediately. Timeouts are set to make sure the auction ends within a determined time.(vii)Public verifiability: all procedures can be publicly verified.(viii)Correctness: the auction has correctly proceeded as defined in the auction protocol.(ix)Financial fairness: malicious parties need to compensate other parties. Usually, all parties need to deposit some Ether in the smart contract as a stake.
2.2. Hawk
Hawk executes smart contracts while keeping secrets [15] when a bidder and a manager exchange data in the following way. (1) When the protocol starts, the bidders and the manager deposit some Ether to the smart contract as a stake. (2) Zero-knowledge proof (zk-SNARK) is attached with all messages sent by the manager and bidders. (3) Smart contract verifies the zero-knowledge proof and the time limit in each phase. In the Hawk protocol, since the bid amount of all bidders is leaked to the manager by design, it is necessary to assume that the manager does not leak any information inappropriately or collude with any party. In other words, the manager has to be a trusted third party. The Hawk protocol achieves bid binding, bid secrecy, bidder anonymity, manager-based secrecy and anonymity, posterior secrecy and anonymity, robustness, correctness, public verifiability, and financial fairness.
2.3. Verifiable Sealed-Bid Auction Protocol
Another verifiable sealed-bid auction protocol [8] was proposed by using a smart contract and Pedersen commitment scheme [16]. In this protocol, there are bidders and managers, just as in Hawk. The manager and a bidder pay a deposit to the smart contract, and the bidder simultaneously sends a bid commitment to the smart contract. Next, the bidder encrypts the value by the manager’s public key and opens the commitment to the smart contract. The manager determines the winning bid and winner, sends the commitment of the winning bid to the smart contract, and proves to the smart contract that the winning bid is higher than any other bid. This scheme achieves bid binding, bid secrecy, manager-based secrecy, posterior secrecy, robustness, correctness, and financial fairness.
2.4. Other Related Works
Wu et al. proposed a smart contract-enabled collusion-resistant e-auction [17], which is well organized and provides many experimental data. However, bidder anonymity is revealed when commitments have been opened. Blockchain-based smart contract for bidding system [18] has the same problem as [17] although they used a blockchain called MinerGate. It also reveals secrets at the end of the auction. Galal also proposed a full privacy-preserving Vickrey auction on top of Ethereum [19], whose design is similar to Hawk. All bidders encrypt their bids by managers of public key. The manager uses Intel SGX to decrypt each bids and determine a winner. Thus, it only satisfies manager-based secrecy and anonymity.
3. Preliminaries
Definition 1 (DDH assumption). Let be a security parameter. A decisional Diffie–Hellman (DDH) parameter generator is a probabilistic polynomial time (PPT) algorithm that takes an input and outputs the description of a finite field and a basepoint with the prime order . We say that satisfies the DDH assumption if is negligible (in ) for all PPT algorithms , where and .
Definition 2 (ElGamal encryption [20]). Let and be large primes. Let denote a prime subgroup of generated by whose order is . Given a message , we define ElGamal [20] encryption as , where is the public key and . Given a ciphertext , decryption is defined as , where is the private key.
Theorem 1 (plaintext equivalence proof of ElGamal ciphertext). Given an ElGamal ciphertext and a plaintext , the encryptor can prove the value of without revealing . This type of proof is based on the proof of equality of two discrete logarithms. i.e., and share the same discrete logarithm .
Theorem 2 (proof of knowledge of a discrete logarithm). Given and , the knowledge of ’s discrete logarithm can be proved without revealing .
Theorem 3 (proof of equality of two discrete logarithms). Given and , the proof of and has same discrete logarithm that can be proved without revealing and . This type of proof is a variation of the proof of knowledge of a discrete logarithm (Theorem 2).
Protocol 1 (mix and match). Mix and match [5] is a technique used to examine whether the decryption of a ciphertext belongs to a set of plaintexts. It is based on mix net, which can perform verifiable secret shuffle. The mix server only knows their own permutation, and they do not know the plaintext. : Input: ciphertext and a set of plaintexts . Output: true if . Otherwise, output false.(1)Construct ciphertext by .(2)For each mix server(a)Calculate where is a secret random value.(b)Generate a random permutation .(c)Shuffle these ciphertexts: .(d)Send to next mix server and publish .(3)Use a publicly verifiable way to decrypt the output of the last mix server.(4)If there exists one plaintext 1, then output true. Otherwise, output false.
Protocol 2 (verifiable secret shuffle). Verifiable secret shuffle is a technique for mix and match, which is designed to use multiple mix servers (TTP) to secretly shuffle ciphertexts. : Input: ciphertexts . Output: shuffled ciphertexts and the proof , where is a secret permutation.
Protocol 3 (bit-slice). Bit-slice is a common technique used in many auction protocols. Assume that the maximum bidding price is 8 dollars. If bidder wants to buy the goods by 6 dollars, the bidder can compose a bidding vector by and . Figure 2 gives an example of a bit-slice bidding vector. The bidding vector can also be presented by a binary format [9, 12] to reduce its size. Figure 3 gives an example of a binary format bidding vector.
Algorithm 1 (binary search). Binary search [21] is an algorithm used to search an ordered list; it can reduce the time complexity to , where is the number of elements; : Input: given an ordered list of elements and a compare function . Output: the index of the target element . If there is no element that satisfies the condition, output the largest where .
4. Our Scheme
Mix servers in mix and match perform verifiable secret shuffle. However, the mix servers can leak the secret permutation to the bidder or the manager. In an auction, let bidder act as mix server that can still be secure because each bidder can only know their permutation. As bidders are counterparties, they have no incentives to leak their secret permutation to others. The design of this protocol is simple, and no additional parties such as manager and TTP are needed.
A notion of commutative encryption is extended to multiparty encryption, which is fit for encryption schemes in smart contract protocol. During decryption, each secret key holder can send their decryption message to the smart contract concurrently. Without this, if the ciphertext is not decrypted before timeout, the responsibility of failure is hard to define. The last honest decryptor might be punished simply because the previous decryptor takes too much time. Also, transaction settlement takes time. It can be time costly for decryptors to decrypt things one by one.
4.1. Multiparty Encryption
A concept of commutative encryption was introduced in [22]. However, to better fit the asynchronous nature of smart contract protocol, we re-formalize it as multiparty encryption here. Without losing generality, we use case to explain.
Definition 3 (multiparty encryption). Let the public and private key pairs of the public key cryptosystem of the party be and , respectively. The ciphertext of plaintext using the public key is , and the decryption is . When public key cryptosystem satisfies the following, the public key cryptosystem is called a multiparty encryption cryptosystem.(i)Full Encryption. We define the encryption using the public key for the ciphertext encrypted with public key for a plaintextthrough the following operation.(ii)Partial Decryption. We define the decryption performed by each party for the ciphertextencrypted with the public keysfor the plaintextthrough the following operation.(iii)Full Decryption. We define the decryption performed by both parties for the ciphertextencrypted with the public keysfor the plaintextthrough the following operation.
Definition 4 (commutative). For a given encryption , ifis satisfied, then the encryption is a commutative.
Definition 5 (bi-homomorphic). When a encryption satisfies the following properties, we say that the encryption is bi-homomorphic.(i)(ii)(iii)(iv)The multiparty encryption based on the ElGamal encryption is defined as follows, which will be proved to be bi-homomorphism.(i)Full Encryption. The encryption using the public keys and is as follows.(ii)Partial Decryption. The partial decryption for a ciphertext by each party or is as follows.(iii)Full Decryption. The decryption performed by both parties for the ElGamal ciphertext encrypted with the public keys and for the plaintext is defined as follows.Thus, the multiparty ElGamal encryption scheme satisfies partial decryption, full decryption, and commutative encryption. We also show that the multiparty ElGamal encryption satisfies the commutative encryption with bi-homomorphism as follows.
Theorem 4. The multiparty ElGamal encryption satisfies the commutative encryption with bi-homomorphism.
Proof. For two given ciphertexts and with , the multiplication of the ciphertexts is as follows.For two given ciphertexts and with , the multiplication of the ciphertexts is as follows.For two given ciphertexts and with , the multiplication of the ciphertexts is as follows.For a given ciphertext with , the exponentiation of the ciphertext is as follows.By using Theorem 1, we can make the verifiable partial decryption as follows.
Theorem 5 (verifiable partial decryption). A decryptor (party 2) can prove that a decrypted ciphertext is a partial decryption of without revealing by showing a same discrete logarithm proof that and has same discrete log .
4.2. Our Auction Protocol
Our protocol consists of a seller, who sells goods at a fixed set of prices , and bidders, who bid a price for the goods. The top bidders can buy the goods by the st price. Remark that no other party except the seller of bidders is required in our protocol.
Our protocol consists of 7 phases as follows.(1)Smart contract deployment: the seller sets necessary parameters and initialization.(2)Bidder initialization: bidders who are interested in the auction submit their stake and join the auction.(3)Submission of bids by bidders: bidders decide their bid and submit it to the smart contract.(4)Bid verification: verify all bidders’ bid.(5)st-price decision: find out the st bidding price.(6)Winner decision: find out the highest bidders who are winners of the auction.(7)Payment: the winning bidders pay the seller the st price to buy the goods.
The protocol is described in detail as follows.
4.2.1. Smart Contract Deployment
The seller decides the following parameter and deploys the smart contract to start the auction.(i)Cryptographic parameters: large prime , a basepoint with prime order , and an auction base .(ii)Seller initialization:(1)Bidding price list .(2)Timeouts for each phase : if a bidder failed to submit valid messages to smart contract within the timeout, the bidder will be treated as a malicious bidder and be financially penalized.(3)Stake requirement : bidders are required to submit amount of Ether as stake to join the auction.
4.2.2. Phase 1: Bidder Initialization
Bidders submit to within time as follows. We assume that there are more than bidders.(i)Each bidder computes the following and submits it to :(1)Compute a public key for the ElGamal encryption, where is a randomly chosen secret key.(2)Compute a proof of as a conventional way of a proof of knowledge of ’s discrete logarithm described in Section 3 and amount of Ether as stake.(ii)After this phase ends, an aggregated public key can be calculated by .
4.2.3. Phase 2: Submission of Bids by Bidders
All bidders submit to within time as follows: see Figure 4 for and . Bidders and win the auction and pay for the goods.(i), computes the below and submits it to :(1)Bidding vector .(2)Shuffled bidding vector .(3)A proof of secure shuffle .
A bidder first chooses a bidding point corresponding to bidding price , constructs a bidding vector , and shuffles to , while making a proof of the secure shuffle:where is a secret permutation generated by . This is used for the verification of . In phase 3, we can decrypt to verify without leaking .(i) calculates the following array for and for bidding price after receiving all (see Figure 4 for and ).(1)Compute array for each bidder : For any , a value of is equal to if , where is ’s bidding point. Otherwise, . The time complexity is , by computing .(2)Compute array for each bidding price :
The value of is the number of bidders whose bid is larger than or equal to .
4.2.4. Phase 3: Bid Verification
A bidder can only bid on one price. So, correct bidding vectors consists of times of and one . Since bidder also submitted , a shuffled , we can simply decrypt to verify if it consists of times of and one within time . The decryption will not leak any secret since the shuffled bidding vector does not contain any secret.(i) verifies all bidder ’s bid :(1)Decrypt the shuffled bidding vector :(2)Verify if there is exactly times of and one in .
4.2.5. Phase 4: st-Price Decision
By using mix and match, and all determine the st price within . In array , the value of is the number of bidders whose bid is larger than or equal to bidding point . Thus, we can use mix and match to find out the bidding point where , but . This is the st price’s bidding point. Since the array is a decrementing array, binary search can speed up the search. We use as a symbol to this .(i)By all bidders’ help, finds the bidding point that but . Assume is the compare function of binary search (Algorithm 1). will return the where but . This is the st price.
4.2.6. Phase 5: Winner Decision
In this phase, by decrypting all bidders’ within time , the winners can be easily found. In this phase, bid secrecy holds because the bid can be any number between and .(i)By all bidders’ help, decrypts for all .
Bidder with wins the auction.
4.2.7. Phase 6: Payment
The bidders who win the auction send amount of Ether (in Wei) to the seller through .(i)All winning bidders send amount of Ether (in Wei) to .(ii) sends amount of Ether (in Wei) to the seller and refunds the stakes to all bidders.
4.3. Features and Security
In this section, we discuss the features and security of our protocol.(i)Bid binding: according to our implementation, the functions in will not allow bidders to change their bidding point after the bid submission phase is closed.(ii)Bid secrecy: the bidding vectors are encrypted by all bidders’ public keys . Without all bidders’ collaboration, the bid is kept a secret. Even though is decrypted, it is a permutation of . Thus, decrypting will not leak any secret. The secrecy of top bids is protected in phase 5. If is an encrypted , all bids from to can contain . Unless all bidders collude, the bid secrecy will be satisfied in the mix and match used in Phase 4. In the mix part, ciphertexts are re-randomized and secretly shuffled by all bidders. Without all bidders colluding, the permutation of shuffled ciphertexts cannot be identified. In the match part, the shuffled ciphertexts can be decrypted by only all bidders’ collaboration.(iii)Bidder anonymity: since are products of ciphertexts generated by all bidders, i.e., . The proof of will not leak . Thus, the identity of the st bidder is still a secret.(iv)Posterior secrecy and anonymity: the bidding points and bidding vectors are still secrets even after the auction. Thus, posterior secrecy and anonymity still hold.(v)Robustness: since all messages sent to the smart contract are attached with a proof, malicious behaviors in each phase can be found immediately. The timeouts are also set for each phase to ensure that the auction ends within a determined time. Therefore, this protocol provides robustness even in malicious models.(vi)Public verifiability: all messages sent to are attached with a publicly verifiable non-interactive proof, which can be verified by smart contract immediately. Therefore, the correctness of the protocol is publicly verifiable.(1)Phase 1: Bidder Initialization. A public key is submitted by each bidder to , . The proof of knowledge of is publicly verifiable. Thus, the correctness of the public key is publicly verifiable.(2)Phase 2: Submission of Bids by Bidders. A secure shuffled bidding vector is submitted by each bidder to , . The proof that is a secure shuffle of is publicly verifiable.(3)Phase 3: Bid Verification. Let . decryption messages are submitted by each bidder . The proof of the same discrete logarithm that and public key have the same discrete logarithm is publicly verifiable. If is valid, then is a valid bidding vector. Thus, the verification on bidding vectors is publicly verifiable.(4)Phase 4:st-Bid Decision. A verifiable mix and match [5] is performed in this phase. The validity of the st bidding point where but is publicly verifiable. Thus, the st bidding price is publicly verifiable.(5)Phase 5: Winner Decision. Let . decryption messages are submitted by each bidder . Therefore, the decryption on is verifiable. The decision of winners is publicly verifiable.(vii)Correctness:(1)Phase 1: Bidder Initialization. All public keys are publicly verified. Thus, the correctness holds.(2)Phase 2: Submission of Bids by Bidders. All secure shuffled bidding vectors are publicly verified. is a secure shuffle of . The correctness holds.(3)Phase 3: Bid Verification. A correct bidding vector should contain amount of and one . Since is a secure shuffle of , is correct if and only if also contains amount of and one . Thus, the correctness holds.(4)Phase 4:st-Bid Decision. The bidding point is correct since , but . There are less than bidders’ bids that are larger than or equal to , but there are more than bidders’ bids that are larger than or equal to . Thus, is the st bidding point. The correctness holds.(5)Phase 5: Winner Decision. If , then the bidder ’s bidding point is larger than or equal to . Thus, this bidder is a winning bidder. The correctness holds.(viii)Financial fairness: all bidders deposit amount Ether (in Wei) in the smart contract as a stake in phase 1. In the failure condition part, malicious bidders will compensate other bidders by their stake.
5. Implementation and Optimization
In this section, we introduce our implementation, optimization, and benchmarks. This protocol consists of smart contract (https://github.com/tonypottera24/m-1st_auction_dlp_sol) and web3 clients (https://github.com/tonypottera24/m-1st_auction_dlp_py). The smart contract is implemented by Solidity 0.7.x with experimental ABIEncoderV2. We also used the “solidity-BigNumber” library (https://github.com/zcoinofficial/solidity-BigNumber) for big number computation. In the client part, we use Python library web3.py (https://github.com/ethereum/web3.py) for better big number support. In terms of the simulation environment, we use Ganache (https://www.trufflesuite.com/ganache), a testnet built by Truffle, to execute and estimate the gas usage.
The computational costs of discrete logarithm problem (DLP) based algorithms are usually significantly affected by the key size. Figure 5 shows the gas usage by using 1024-, 2048-, and 3072-bit DLP and ECC P256. A common way to solve this problem is to use elliptic curve cryptography (ECC). Our ECC contract used the “elliptic-curve-solidity” (https://github.com/witnet/elliptic-curve-solidity) library, which is well tested and provides common NIST series curves such as secp256r1 (P256). As an Ethereum virtual machine always uses 256-bit integers, the gas consumption should not have significant differences between P192, P224, and P256. The ECC P256 version can save gas on average compared with 3072-bit DLP. Table 2 shows implementation results of AS [6] and our scheme. Without using full mix and match and applying some optimization (see Section 6), we can reduce gas on a 3-bidder and 6-bidding price setting.
6. Comparison
In this section, we compared the performance of our scheme with those of the AS [6], OM [7], GY [8], and MMO [9], as shown in Table 3; compared with other schemes, we do not need a trusted manager. The only role in our scheme is bidder. This design matches the ultimate goal of smart contract protocol, decentralized and trustless. As one of our main contributions in the bid verification phase, we use verifiable shuffle, i.e., the mix part, instead of the whole mix and match protocol as other related works do.
Detailed comparisons of phases 1 and 3 are as follows:(1)Phase 1: Bidder Initialization. In previous research [6, 9, 11, 12], the bids are encrypted only by managers’ public key. The bid secrecy, bidder anonymity, and many other properties all relied on the trusted manager. On the other hand, in our scheme, the ciphertexts are encrypted by all bidders’ public keys. Without all bidders’ collaboration, no one can break the bid secrecy and bidder anonymity.(2)Phase 3: Bid Verification. A valid bidding vector should contain exactly amounts of and one . In previous research [6, 9, 11, 12], bidding vector verification contains two parts: (1) ; (2) . The first part is accomplished by mix and match [5]. This requires (trusted) mix servers to perform mix (secure shuffle [23–25]) and match (zk equality proof). The second part is accomplished by asking trusted manager to decrypt .
In our scheme, we only use the match part (secure shuffle) of the mix and match protocol to prove these two parts simultaneously. By all bidders’ collaboration, we decrypt (a publicly verifiable shuffle of ). can verify if there is exactly amounts of and one in without leaking any secret.
Table 4 compares our protocol with previous protocols. In previous research, trusted managers need to use mix and match on values to verify ciphertexts in bidding vector for all bidders. Therefore, the time complexity of manager is [6–8]. The time complexity and storage complexity on are proportional to the number of trusted manager , i.e., overall. By removing the manager and letting bidders act as managers, the time complexity of our bidder is as good as the time complexity of the manager in previous research. On the other hand, as one of our contributions, we applied optimization to reduce the storage complexity from to . In previous research, the multiparty ElGamal ciphertext is in a format of . However, it is meaningless to use different randomness since the ciphertexts are created by the same bidder. Only is enough.
7. Conclusion
We propose an efficient and secure st-price auction protocol without a trusted manager under a malicious model. Out protocol satisfies anonymity, robustness, correctness, public verifiability, and financial fairness.
Data Availability
The data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This study was partially supported by enPiT (Education Network for Practical Information Technologies) of MEXT and Innovation Platform for Society 5.0 of MEXT.