A Confidential Batch Payment Scheme with Integrated Auditing for Enhanced Data Trading Security

Abstract

Current data trading systems only support plaintext or unaudited private transactions. To overcome these, we present a confidential batch payment scheme with integrated auditing for enhanced data trading security. We use Castagnos–Laguillaumie (CL) homomorphic encryption and batch zero-knowledge proofs to construct the scheme. The scheme reduces decryption complexity and ciphertext length while enabling malicious model operations. In addition, it supports efficient batch payments to multiple recipients and includes features for payment statistic analysis and auditing. Experimental results indicate that the system efficiently handles encryption, decryption, and auditing tasks, completing each operation in an average of 0.89, 1.55, and 1.55 milliseconds, respectively.

1. Introduction

Securing data trading [1,2,3,4,5,6] is of paramount importance in today’s interconnected digital landscape. As the volume of data exchanged across platforms and borders continues to escalate, the potential vulnerabilities and threats to data integrity and privacy also increase. Effective security measures in data trading not only protect sensitive information from unauthorized access and cyber threats but also ensure the maintenance of trust between trading partners. It encompasses the implementation of robust encryption methods, stringent access controls, and comprehensive data governance policies. Ensuring the security of data trading is crucial for preserving the confidentiality, integrity, and availability of data, which are the cornerstones of a reliable and resilient digital economy.

Current data trading schemes [7,8,9,10] exhibit significant shortcomings in terms of privacy protection and auditing capabilities. These systems often prioritize efficiency and profitability over stringent security measures, leading to vulnerabilities where sensitive data can be exposed or misused. The lack of robust privacy protection mechanisms [11] means that personal and confidential information can be traded without adequate safeguards, potentially leading to breaches of data privacy laws and erosion of trust among stakeholders. Additionally, insufficient auditing processes [12] fail to provide a transparent and traceable record of data transactions, making it challenging to detect and address unauthorized access or data manipulation. To rectify these issues, it is imperative to integrate advanced security protocols, enforce strict privacy standards, and implement comprehensive auditing practices in data trading platforms.

Therefore, we introduce a confidential batch payment scheme with integrated auditing for enhanced data trading security. Specifically, we make the following contributions:

• We propose a confidential batch payment scheme with integrated auditing for enhanced data trading security. Our scheme ensures payment privacy, allows senders to compile payment statistic analysis, and enables independent auditing by two separate auditors.
• We propose a framework for the batch payment scheme, providing a scheme instance that meets CCA security under a game-based security model.
• We conduct a comparative analysis which indicates that our scheme distinctively balances privacy and audit needs in blockchain payments, emphasizing efficiency and privacy. Test results demonstrate practical encryption, decryption, and audit time of 0.89/1.55/1.55 ms, respectively.

2. Related Works

Publicly verifiable secure data trading. Dai et al. [13] presented a blockchain-based data trading ecosystem. In the ecosystem, both the data broker and buyer are not able to obtain access to the seller’s raw data, as they are only obtaining access to the analysis findings that they require. In other words, it reduces the challenge of securing the dataset to the challenge to secure data processing. However, users typically need access to plaintext data to enable various sharing activities. Li et al. [14] proposed a decentralized trading solution for open fair data trading by deploying a smart contract on a blockchain network. As the trading content is the decryption key of the data, it can alleviate the storage pressure of the blockchain by reducing the transaction cost. This scheme uses transaction content as the decryption key, which can only slightly reduce the blockchain storage pressure. More optimal data compression algorithms should be studied to significantly reduce blockchain storage pressure. Guan et al. [15] proposed two secure, fair, and efficient data trading schemes that do not rely on any third party using blockchain. The first scheme achieves direct raw data exchange for large amounts of data but lacks privacy protection. The second scheme enables statistical data transactions but cannot perform other in-depth data analysis and statistics. An et al. [16] proposed a blockchain-based crowd sensed data trading system. They used blockchain-based reverse auction to assign sensing tasks to data sellers to ensure the data sellers to report data collection costs honestly and prevent sellers to manipulate the auction. However, the paper does not provide a method for fair and objective task data allocation. Finally, these schemes fail to address the critical issues of privacy protection and auditing.

Data trading schemes with privacy. Maxwell [17] employs Pedersen commitments for blockchain transactions, ensuring payment amount privacy. This method requires extra interaction, where the sender communicates the amount and a random number to the receiver. Therefore, this scheme is not friendly in a non-interactive blockchain environment. Additionally, extra interactions are susceptible to denial-of-service attacks, which can lead to transaction failures and other issues. Zerocoin [18] and Zerocash [19] uses zkSnark (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) [20] for concise, non-interactive, zero-knowledge proofs, verifying transactions without disclosing details. These proofs involve polynomial products and use homomorphic encryption to hide payment amounts, keeping the sender’s and receiver’s addresses and payment amounts confidential. However, zkSnark’s computational complexity is high. Also, hash function-based accumulator technology [21,22] is integral for blockchain privacy protection. Reference [23] used Paillier homomorphic encryption to achieve payment amount privacy protection for Bitcoin. Paillier homomorphic encryption is based on the large integer factorization problem, while Bitcoin is based on the elliptic curve discrete logarithm problem. Thus, the compatibility of Paillier homomorphic encryption with elliptic curve systems requires extra caution to avoid potential security issues. In contrast, the homomorphic encryption implemented on class groups in this paper is more easily compatible with elliptic curve systems, and there are precedents for this, such as in reference [24]. In contrast to these schemes, our batch confidential payment scheme, which simultaneously prioritizes privacy and audit functions, holds substantial practical significance in financial systems.

3. System Framework

As shown in Figure 1, a confidential batch payment scheme with integrated auditing for enhanced data trading security has eight steps: Initial, KeyGen, BatchPay, Consensus, Receipt, PaymentStatistic, and two distinct Audit phases. The Initial and KeyGen steps are responsible for generating the system parameters and key pairs independently. During BatchPay, the sender employs CL homomorphic encryption to encrypt multiple payment amounts, ensuring their privacy. Subsequently, the Consensus algorithm records the transaction on the blockchain. As a result, multiple receivers and the sender can independently decrypt the payment amount for reception and payment statistics analysis. Finally, in the two Audit phases, two separate auditors have the capability to independently decrypt each payment amount for auditing purposes. Therefore, our scheme skillfully combines the aspects of payment privacy and auditing.

A formal definition of batch payment scheme is as follows:

Initial. The system parameter generation algorithm $\mathsf{Init}$ takes as input a security parameter $\lambda$ and generates the system public parameters $SP$

$$SP\leftarrow \mathsf{Init}(\lambda ).$$

KeyGen. Each participant runs the key generation algorithm $\mathsf{KeyGen}$ independently, takes as input the system parameters $SP$, and outputs the key pairs $(P{K}_j,s{k}_j)$ for homomorphic encryption

$$(P{K}_j,s{k}_j)\leftarrow \mathsf{KeyGen}(SP),j=1,2,3,4.$$

Let $j=1,2,3,4$ represent four participants which are the sender, receiver, and two auditors, respectively. Additionally, let $(P{K}_{2,i},s{k}_{2,i})$ be key pairs for receiver i, where $i=1,...,m$.

BatchPay. The sender runs homomorphic encryption algorithm $Enc$; takes as input the private key $s{k}_1$ of the sender, multiple payment amounts $v_i,i=1,...,m$, public keys $P{K}_{2,i}$ of multiple receivers and public keys $(P{K}_3,P{K}_4)$ of the two auditors; and outputs ciphertexts $C_i$ for the payment amounts

$$C_i\leftarrow \mathsf{Enc}(s{k}_1,P{K}_{2,i},P{K}_3,P{K}_4,v_i).$$

Let $P{K}_{2,m}$ be the public key of the sender. Then, setting the change amount in the above payment process is unnecessary. In other words, the sender possesses a correct private key $s{k}_{2,m}$ corresponding to the public key $P{K}_{2,m}$ and can spend the corresponding payment $v_m$.

The balance $v_0$ of the sender is expressed in homomorphic ciphertext as follows,

$$C_0\leftarrow \mathsf{Enc}(s{k}_0,P{K}_1,P{K}_3,P{K}_4,v_0),$$

where $v_0$ is the balance by another user (with private key $s{k}_0$) paid to the sender; $P{K}_1$ is the collection public key. As the sender knows the private key $s{k}_1$ corresponding to the collection public key $P{K}_1$, they are able to spend it.

To guarantee that the total payment aligns with the sender’s balance, the ciphertext is valid, and all payment amounts are positive, the sender performs Sigma, batch, and range zero-knowledge proofs, as follows:

$$\begin{array}{cc}& zk\left\{v_1,...,v_m\left|v_0=v_0+...+v_m\right.\right\},\hfill \\ & zk\left\{v_i,u_i\left|C_i=\mathsf{Enc}\left(s{k}_1,P{K}_{2,i},P{K}_3,P{K}_4,v_i\right)\right.\right\},\hfill \\ & zk\left\{v_i\left|0\le v_i\le K,C_i=\mathsf{Enc}\left(s{k}_1,P{K}_{2,i},P{K}_3,P{K}_4,v_i\right)\right.\right\},\hfill \end{array}$$

where $K=2^{32}$, the upper limit of each payment. Thus, the sender can send the ciphertexts and proofs together with a signature to the blockchain system.

Consensus. Consensus nodes run a validation algorithm to confirm the signature and the three proofs’ accuracy. If validations are correct and there is no double-spending evidence, the nodes use a consensus mechanism, such as Byzantine consensus, to log the transactions.

Receipt. Each receiver i uses their public key $P{K}_{2,i}$ to obtain their homomorphic ciphertext $C_i$ from the blockchain. They then decrypt it using the decryption algorithm with their private key $s{k}_{2,i}$, the sender’s public key $P{K}_1$, and the public keys $(P{K}_3,P{K}_4)$ of two auditors, obtaining the decrypted payment amount $v_i$

$$v_i\leftarrow \mathsf{Dec}(P{K}_1,P{K}_3,P{K}_4,s{k}_{2,i},C_i).$$

PaymentStatistic. The sender retrieves the ciphertext $C_i$ from the blockchain system and runs the decryption algorithm, takes their private keys $s{k}_1$ and the public keys $(P{K}_3,P{K}_4)$ of two auditors as input, and outputs the payment amount $v_i$

$$v_i\leftarrow \mathsf{Dec}(P{K}_{2,i},P{K}_3,P{K}_4,s{k}_1,C_i).$$

Therefore, the sender can decrypt each payment amount $v_i$ to achieve payment statistic analysis.

Audit 1. Auditor 1 runs the audit algorithm $Audi{t}_1$; takes the private key $s{k}_3$ and ciphertext $C_i$ as input; and outputs the payment amount $v_i$

$$v_i\leftarrow \mathsf{Dec}(s{k}_3,C_i).$$

Audit 2. Auditor 2 runs the audit algorithm $Audi{t}_2$, takes the private key $s{k}_4$ and ciphertext $C_i$ as input, and outputs the payment amount $v_i$

$$v_i\leftarrow \mathsf{Dec}(s{k}_4,C_i).$$

Thus, both auditors can independently decrypt each payment amount $v_i$, enabling the audit of every payment.

4. Scheme Construction

Initial: The initialization algorithm $\mathsf{Init}$ takes a security parameter $\lambda$ as input. It yields the class group parameters $(\tilde{s},g,f,g_q,\varphi ,\widehat{G},G,F,G^q)$. Four hash functions are specified as follows: ${\mathsf{hash}}_{\mathsf{1}},{\mathsf{hash}}_{\mathsf{2}},{\mathsf{hash}}_{\mathsf{3}}:{\{0,1\}}^{*}\to {\mathbb{Z}}_q,{\mathsf{hash}}_{\mathsf{4}}:{\{0,1\}}^{*}\to {\{0,1\}}^n$. The system parameter is then defined as follows:

$$SP=\left\{\tilde{s},g,f,g_q,\varphi ,\widehat{G},G,F,G^q,{\mathsf{hash}}_{\mathsf{1}},{\mathsf{hash}}_{\mathsf{2}},{\mathsf{hash}}_{\mathsf{3}},{\mathsf{hash}}_{\mathsf{4}}\right\}.$$

KeyGen: In this phase, each participant independently executes the key generation algorithm $\mathsf{KeyGen}$, takes the system parameters $SP$ as input. This results in the generation of key pairs $\left((x_i,y_i),(X_i,Y_i)\right)$ for CL homomorphic encryption. The process is represented as follows:

$$\left((x_i,y_i),(X_i,Y_i)\right):=\mathsf{KeyGen}(SP),i=1,2,3,4$$

where $\left((x_1,y_1),(X_1,Y_1)\right)$ are key pairs for the sender, $\left((x_2,y_2),(X_2,Y_2)\right)$ for the receiver, $\left((x_3,y_3),(X_3,Y_3)\right)$ for auditor 1, and $\left(x_4,X_4\right)$ for auditor 2. For the convenience of subsequent description, let $h=X_4$. Typically, $\left((x_{2,i},y_{2,i}),(X_{2,i},Y_{2,i})\right)$ are the key pairs for the receiver i.

BatchPay: During the BatchPay phase, the sender executes the CL homomorphic encryption algorithm $\mathsf{CLEnc}$. This process involves two random numbers $(r_i,u_i)$, the sender’s private key $(x_1,y_1)$, multiple payment amounts $v_i\in {\mathbb{Z}}_q$, the public keys $(X_{2,i},Y_{2,i})$ of multiple receivers, and the public keys $(X_3,Y_3,h)$ of the two auditors. The sender computes the following:

$$\begin{array}{cc}& c_{i,1}:=r_i,s_i:={\mathsf{hash}}_{\mathsf{1}}(r_i,X_{2,i}^{x_1},Y_{2,i}^{y_1}),\hfill \\ & c_{i,2}:=g_q^{s_i},t_i:={\mathsf{hash}}_{\mathsf{2}}(X_3^{s_i},Y_3^{s_i}),\hfill \\ & c_{i,3}:=g_q^{t_i},c_{i,4}:=f^{u_i}·h^{t_i},c_{i,5}:=f^{v_i}·{\varphi }^{{\mathsf{hash}}_{\mathsf{3}}(u_i)},\hfill \\ & c_{i,6}:={\mathsf{hash}}_{\mathsf{4}}(u_i,v_i,c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5}),\hfill \end{array}$$

The resulting CL homomorphic ciphertext is represented as $\{c_{i,1},c_{i,2},c_{i,3},c_{i,4},$$c_{i,5},c_{i,6}\}$. If $X_{2,m}$ denotes the public key of the sender, then it is unnecessary to specify a change amount in the payment process. This is because the sender, knowing the private key $x_{2,m}$ corresponding to the public key $X_{2,m}$, can obtain the corresponding payment $v_m$. Therefore, the paid amount itself serves as the change amount.

The sender’s unspent amount, denoted as $v_0$, is represented in homomorphic ciphertext as follows:

$$\begin{array}{cc}& c_{0,1}:=r_0,s_0:={\mathsf{hash}}_{\mathsf{1}}(r_0,X_1^{x_0},Y_1^{y_0}),\hfill \\ & c_{0,2}:=g_q^{s_0},t_0:={\mathsf{hash}}_{\mathsf{2}}(X_3^{s_0},Y_3^{s_0}),\hfill \\ & c_{0,3}:=g_q^{t_0},c_{0,4}:=f^{u_0}·h^{t_0},c_{0,5}:=f^{v_0}·{\varphi }^{{\mathsf{hash}}_{\mathsf{3}}(u_0)},\hfill \\ & c_{0,6}:={\mathsf{hash}}_{\mathsf{4}}(u_0,v_0,c_{0,1},c_{0,2},c_{0,3},c_{0,4},c_{0,5}),\hfill \end{array}$$

In this context, $v_0\in {\mathbb{Z}}_q$ represents the amount paid to the sender by another user, who possesses the private key $(x_0,y_0)$. The collection public key is denoted as $(X_1,Y_1)$, and the sender, knowing the corresponding private key $(x_1,y_1)$ to this collection public key, is thereby enabled to spend the amount $v_0$.

To guarantee that the total payment aligns with the sender’s balance, the ciphertext is valid, and all payment amounts are positive, the sender performs Sigma, batch, and range zero-knowledge proofs.

Specifically, the Sigma zero-knowledge proof is used to prove that they know the secret $\omega =s_0-({\sum }_{i=1}^m{s}_i)$ such that

$$c_{0,5}/(c_{1,5}·...·c_{m,5})=h^{u_0-({\sum }_{i=1}^m{u}_i)}.$$

As $c_{0,5}/(c_{1,5}·...·c_{m,5})=f^{v_0-({\sum }_{i=1}^m{v}_i)}·h^{u_0-({\sum }_{i=1}^m{u}_i)},$ the Sigma zero-knowledge proof ensures that $f^{v_0-({\sum }_{i=1}^m{v}_i)}$ is equal to the identity element I in the class group, that is,

$$f^{v_0-({\sum }_{i=1}^m{v}_i)}=I.$$

Therefore, it guarantees that the payments are equal to their balance

$$v_0-({\sum }_{i=1}^m{v}_i)=0.$$

The Sigma zero-knowledge proof is denoted as

$$zk\left\{\omega \left|c_{0,5}/(c_{1,5}·...·c_{m,5})=h^{\omega }\right.\right\}.$$

To ensure data integrity, the sender generates proofs to verify the correctness and validity of the encrypted payment data. A batch zero-knowledge proof confirms the consistency between the payment amounts and associated random numbers used in the CL homomorphic encryption process,

$$zk\left\{v_i,t_i\left|\begin{array}{c}{c}_{i,3}=g_q^{t_i},c_{i,4}=f^{u_i}·h^{t_i},c_{i,5}=f^{v_i}·{\varphi }^{{\mathsf{hash}}_{\mathsf{3}}(u_i)}\hfill \end{array}\right.\right\}.$$

Additionally, a batch range proof establishes that all payment values fall within a predetermined limit of $2^{32}$

$$zk\left\{v_i\left|\begin{array}{c}0\le v_i\le 2^{32},c_{i,5}=f^{v_i}·{\varphi }^{{\mathsf{hash}}_{\mathsf{3}}(u_i)}\hfill \end{array}\right.\right\},$$

Once these proofs are generated, the sender securely transmits the encrypted payments, accompanied by the proofs and a digital signature, to the blockchain network.

Consensus: The consensus stage is consistent with the system framework, and its description is omitted here for brevity.

Receipt: During this stage, the intended recipient obtains their encrypted payment from the blockchain using their unique public key $(X_{2,i},Y_{2,i})$. To decrypt this information, they utilize the CL decryption process. This requires their private key $(x_{2,i},y_{2,i})$, specific components of the ciphertext $(c_{i,1},c_{i,4})$, the sender’s public key $(X_1,Y_1)$, and the public keys $(X_3,Y_3,h,\varphi )$ of both auditors. Through these inputs, the recipient performs the necessary calculations to reveal the payment amount,

$$s_i^{\prime }:={\mathsf{hash}}_{\mathsf{1}}(c_{i,1},X_1^{x_{2,i}},Y_1^{y_{2,i}}),t_i^{\prime }:={\mathsf{hash}}_{\mathsf{2}}(X_3^{s_i^{\prime }},Y_3^{s_i^{\prime }}),f^{u_i^{\prime }}:=c_{i,4}·h^{-t_i^{\prime }}$$

Subsequently, they apply a probabilistic polynomial time (PPT) algorithm $\mathsf{Solve}()$, efficiently calculating the discrete logarithm $f^{u_i^{\prime }}$ and obtaining the plaintext $u_i^{\prime }$. The receiver then proceeds to process part of the ciphertext $c_{i,5}$, calculating:

$$f^{v_i^{\prime }}:=c_{i,5}·{\varphi }^{-{\mathsf{hash}}_{\mathsf{3}}(u_i^{\prime })}.$$

Using the $\mathsf{Solve}()$ algorithm, they efficiently compute the discrete logarithm $f^{v_i^{\prime }}$ and obtain the plaintext $v_i^{\prime }$. Finally, they verify the consistency of the following equality:

$$c_{i,6}={\mathsf{hash}}_{\mathsf{4}}(u_i^{\prime },v_i^{\prime },c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5}).$$

If the verification is valid, then accept $v_i^{\prime }$; otherwise, reject it.

PaymentStatistic: During this stage, the sender obtains their encrypted payment from the blockchain using their unique public key. To decrypt this information, they utilize the CL decryption process. This requires their private key $(x_1,y_1)$, specific components of the ciphertext $(c_{i,1},c_{i,4})$, the recipient’s public key $X_{2,i},Y_{2,i}$, and the public keys $(X_3,h)$ of both auditors. Through these inputs, the sender performs the necessary calculations to reveal the payment amount

$$s_i^{″}:={\mathsf{hash}}_{\mathsf{1}}(c_{i,1},X_{2,i}^{x_1},Y_{2,i}^{y_1}),t_i^{″}:={\mathsf{hash}}_{\mathsf{2}}(X_3^{s_i^{\prime }},Y_3^{s_i^{\prime }}),f^{u_i^{″}}:=c_{i,4}·h^{-t_i^{″}}$$

Subsequently, they apply a PPT algorithm $\mathsf{Solve}()$, efficiently determining the discrete logarithm $f^{u_i^{″}}$ and extracting the plaintext $u_i^{″}$. The sender then proceeds to process part of the ciphertext $c_{i,5}$, calculating:

$$f^{v_i^{″}}:=c_{i,5}·{\varphi }^{-{\mathsf{hash}}_{\mathsf{3}}(u_i^{″})}.$$

Using the $\mathsf{Solve}()$ algorithm, the sender efficiently computes the discrete logarithm $f^{v_i^{″}}$ and acquires the plaintext $v_i^{″}$. Finally, they verify the consistency of the following equality:

$$c_{i,6}={\mathsf{hash}}_{\mathsf{4}}(u_i^{″},v_i^{″},c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5}).$$

If the verification is valid, then accept $v_i^{″}$; otherwise, reject it. This process enables the sender to decrypt each $v_i^{″}$, facilitating payment statistic analysis.

Audit 1. In this phase, auditor 1 initiates the audit algorithm $Audi{t}_1$. The inputs for this procedure include the auditor’s private key $(x_3,y_3)$, selected components of the ciphertext $(c_{i,2},c_{i,4})$, and the public key $X_4$ of auditor 1. The following calculation is performed:

$${\widehat{t}}_i:={\mathsf{hash}}_{\mathsf{2}}(c_{i,2}^{x_3},c_{i,2}^{y_3}),f^{{\widehat{u}}_i}:=c_{i,4}·h^{-{\widehat{t}}_i}$$

Subsequently, the auditor employs the PPT algorithm $\mathsf{Solve}()$, efficiently computing the discrete logarithm $f^{{\widehat{u}}_i}$ to extract the plaintext ${\widehat{u}}_i$. Auditor 1 proceeds to process part of the ciphertext $c_{i,5}$, calculating the following:

$$f^{{\widehat{v}}_i}:=c_{i,5}·{\varphi }^{-{\mathsf{hash}}_{\mathsf{3}}({\widehat{u}}_i)}.$$

Using the $\mathsf{Solve}()$ algorithm, the auditor efficiently computes the discrete logarithm $f^{{\widehat{v}}_i}$ and acquires the plaintext ${\widehat{v}}_i$. Finally, they verify the consistency of the following equality:

$$c_{i,6}={\mathsf{hash}}_{\mathsf{4}}({\widehat{u}}_i,{\widehat{v}}_i,c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5}).$$

If the verification is valid, then accept ${\widehat{v}}_i$; otherwise, reject it. This enables auditor 1 to decrypt each payment amount ${\widehat{v}}_i$, ensuring meticulous auditing.

Audit 2. In this stage, auditor 2 activates the audit algorithm $Audi{t}_2$. The inputs for this algorithm are the auditor’s private key $x_4$ and specific parts of the ciphertext $(c_{i,3},c_{i,4})$. The auditor computes the following:

$$f^{{\tilde{u}}_i}:=c_{i,4}·c_{i,3}^{-x_4}.$$

Following this, a PPT algorithm $\mathsf{Solve}()$ is employed to efficiently calculate the discrete logarithm $f^{{\tilde{u}}_i}$, leading to the retrieval of the plaintext ${\tilde{u}}_i$. Auditor 2 then proceeds to process part of the ciphertext $c_{i,5}$, calculating the following:

$$f^{{\tilde{v}}_i}:=c_{i,5}·{\varphi }^{-{\mathsf{hash}}_{\mathsf{3}}({\tilde{u}}_i)}.$$

Using the $\mathsf{Solve}()$ algorithm, the auditor efficiently computes the discrete logarithm $f^{{\tilde{v}}_i}$ and obtains the plaintext ${\tilde{v}}_i$. Finally, they verify the consistency of the following equality:

$$c_{i,6}={\mathsf{hash}}_{\mathsf{4}}({\tilde{u}}_i,{\tilde{v}}_i,c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5}).$$

If the verification is valid, then accept ${\tilde{v}}_i$; otherwise, reject it. Thus, auditor 2 can decrypt each payment amount ${\tilde{v}}_i$, enabling detailed and precise auditing.

5. Security Analysis

Definition 1.

In the classic IND-CCA game-based security model [25], our Confidential batch payment scheme using CL homomorphic encryption is $(t,q_{\mathcal{D}},\epsilon )$-secure if no PPT adversary $\mathcal{A}$ can win the game within time t with an advantage ε, after making $q_{\mathcal{D}}$ decryption queries.

In this context, the adversary $\mathcal{A}$ may impersonate the sender, receiver, or auditor to launch an attack. Additionally, the computational process between the sender and the receiver are symmetric. This leads to the establishment of the following theorems:

Theorem 1.

The scheme is provably secure against an IND-CCA attack perpetrated by an adversary $\mathcal{A}$, acting either as a sender or a receiver. This security is predicated on the hardness of the Computational Diffie-Hellman (CDH) problem in the class group and the random oracle model for the hash function, with a reduction loss factor $L=q_{\mathcal{D}}$.

Theorem 2.

The scheme is provably secure against an IND-CCA attack perpetrated by an adversary $\mathcal{A}$, acting as auditor 1. This security is predicated on the hardness of the CDH problem in the class group and the random oracle model for the hash function, with a reduction loss factor $L=q_{\mathcal{D}}$.

Theorem 3.

The scheme is provably secure against an IND-CCA attack by an adversary $\mathcal{A}$, acting as auditor 2. This assertion relies on the hardness of the Decisional Diffie–Hellman (DDH) problem in the class group and the random oracle model for the hash function, with a reduction loss factor $L=2q_{\mathcal{D}}$.

The validity of Theorem 1 is demonstrated through a specific proof, while the proof of Theorem 2 follows a similar approach. For Theorem 3, the essential ciphertext is formulated as follows:

$$\begin{array}{cc}& c_{i,3}=g_q^{t_i},c_{i,4}=f^{u_i}·h^{t_i},c_{i,5}=f^{v_i}·{\varphi }^{{\mathsf{hash}}_{\mathsf{3}}(u_i)},\hfill \\ & c_{i,6}={\mathsf{hash}}_{\mathsf{4}}(u_i,v_i,c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5}).\hfill \end{array}$$

where $t_i$ is regarded as a random number. Therefore, the aforementioned ciphertext is generated via a standard CCA-secure public-key encryption scheme.

Proof. 

Given a PPT adversary $\mathcal{A}$ capable of breaking the payment CL homomorphic encryption scheme with non-negligible probability $\epsilon$ within time t in the IND-CCA security model, we construct a PPT simulator $\mathcal{B}$ that solves the Computational Diffie-Hellman (CDH) problem within class groups.

Initial. Let $g_q,g_q^a,g_q^b\in {\tilde{G}}^q\subset \tilde{G}$ be a CDH challenge instance within the class group $(\tilde{s},g,f,g_q,\widehat{G}$, $\tilde{G},F,{\tilde{G}}^q)$. The simulator $\mathcal{B}$ interacts with adversary $\mathcal{A}$ as follows:

• $\mathcal{B}$ simulates four random oracles ${\mathcal{H}}_1,{\mathcal{H}}_2,{\mathcal{H}}_3,{\mathcal{H}}_4$.
• $\mathcal{B}$ chooses random $z_1,z_2\in {\mathbb{Z}}_q$ and computes its public key as:

  $$PK=(h,t)=(g_q^a,g_q^{z_1+z_2·a}),$$
• $\mathcal{B}$ sends $PK$ to $\mathcal{A}$.

Note that the public key $PK$ is implicitly defined by the CDH challenge instance $g_q,g_q^a$ and the random values $z_1,z_2$.

Random Oracle Query. Adversary $\mathcal{A}$ is permitted to query the random oracles ${\mathcal{H}}_1$ and ${\mathcal{H}}_4$. Simulator $\mathcal{B}$ maintains a record of all oracle queries and corresponding responses in a list, initially empty. For the j-th ${\mathcal{H}}_1$ query of the form $(r_{i,j},h^{b_{i,j}},t^{b_{i,j}},{\varphi }^{s_{i,j}},{\phi }^{s_{i,j}})$, simulator $\mathcal{B}$ performs the following:

• Check for existing query: If the query exists in the hash list, $\mathcal{B}$ returns the previously recorded response.
• Generate new response: Otherwise, $\mathcal{B}$ selects random values $s_{i,j}$ and $t_{i,j}$, computes

  $$s_{i,j}={\mathcal{H}}_1(r_{i,j},h^{b_{i,j}},t^{b_{i,j}}),$$

  and sends $s_{i,j},t_{i,j}$ to $\mathcal{A}$, and adds $(r_{i,j},h^{b_{i,j}},t^{b_{i,j},s_{i,j}})$ to the hash list.

For any new query $(u_i^{\prime },v_i^{\prime },c_{i,1}^{\prime },c_{i,2}^{\prime },c_{i,3}^{\prime },c_{i,4}^{\prime },c_{i,5}^{\prime })$ to the oracle ${\mathcal{H}}_4$, if

$$(v_i^{\prime },c_{i,1}^{\prime },c_{i,2}^{\prime },c_{i,3}^{\prime },c_{i,4}^{\prime },c_{i,5}^{\prime })=(v_b,c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5}),$$

and $u_i^{\prime }$ is the searched $u_i$, which can be detected thanks to the decryption oracle, above $c_{i,6}$ is returned. Otherwise, a random value is sent.

Decryption Query 1. The adversary $\mathcal{A}$ seeks pairs $(v_i,u_i)$ and the query $(u_i,v_i,c_{i,1},c_{i,2}$, $c_{i,3},c_{i,4},c_{i,5})$ has been made to ${\mathcal{H}}_4$ with the response $c_{i,6}$. For each pair, it calculates ${\mathsf{hash}}_{\mathsf{3}}(u_i)$ using the aforementioned simulation and verifies if $c_{i,5}=f^{v_i}{\varphi }^{{\mathsf{hash}}_{\mathsf{3}}(u_i)}$ and consults the decryption oracle to confirm if $c_{i,4}$ encrypts $u_i$, resulting in at most $q_{{\mathcal{H}}_1}$ queries to this oracle. If $(v_i,u_i)$ is found and for

$$\begin{array}{cc}& c_{i,1}=r_i,s_i={\mathsf{hash}}_{\mathsf{1}}(r_i,X_{2,i}^{x_1},Y_{2,i}^{y_1}),\hfill \\ & c_{i,2}=g_q^{s_i},t_i={\mathsf{hash}}_{\mathsf{2}}(X_3^{s_i},Y_3^{s_i}),\hfill \\ & c_{i,3}=g_q^{t_i},c_{i,4}=f^{u_i}·h^{t_i},c_{i,5}=f^{v_i}·{\varphi }^{{\mathsf{hash}}_{\mathsf{3}}(u_i)},\hfill \\ & c_{i,6}={\mathsf{hash}}_{\mathsf{4}}(u_i,v_i,c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5}),\hfill \end{array}$$

the plaintext is identified as $v_i$, mirroring the decryption oracle’s action. Otherwise, the ciphertext is rejected. Incorrect decryption may occur, leading to valid ciphertext rejection if the query $(u_i,v_i,c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5})$ was not made to ${\mathsf{hash}}_{\mathsf{5}}$. This leads to two scenarios: either $c_{i,6}$ comes from the encryption oracle, indicating it is part of the challenge ciphertext, or the attacker correctly guesses ${\mathcal{H}}_4(u_i,v_i,c_{i,1},c_{i,2},c_{i,3},c_{i,4},c_{i,5})$ without querying, but with a probability of only $1/2^n$.

Challenge. Adversary $\mathcal{A}$ submits two distinct payment amounts $v_0$ and $v_1$. Simulator $\mathcal{B}$ randomly selects a bit $\xi \in \{0,1\}$ and sets the challenge value $v_{\xi }$. Additionally, $\mathcal{B}$ chooses random values $r_{i,j}^{*},s_{i,j}^{*},t_{i,j}^{*}{\in }_R{\mathbb{Z}}_n$ and random elements $\varphi ,\phi$ from the class group.

The value of $s_{i,j}^{*}$ is determined as the output of the random oracle ${\mathcal{H}}_1$ for the inputs ${\mathcal{H}}_1(r_{i,j}^{*},h^b,t^b)$, expressed as $s_{i,j}^{*}={\mathcal{H}}_1(r_{i,j}^{*},h^b,t^b)$. Subsequently, the challenge ciphertext $C{T}^{*}$ is constructed as a combination of various elements:

$$\begin{array}{cc}& t_{i,j}^{*}={\mathcal{H}}_2({\varphi }^{s_{i,j}^{*}},{\phi }^{s_{i,j}^{*}})\hfill \\ & c_{i,1}^{*}=r_{i,j}^{*},c_{i,2}^{*}=g_q^{s_{i,j}^{*}},c_{i,3}^{*}=g_q^{t_{i,j}^{*}},\hfill \\ & c_{i,4}^{*}=f^{v_{\xi }}·h^{t_{i,j}^{*}}.\hfill \end{array}$$

Thus, the challenge ciphertext $C{T}^{*}$ is constructed as $C{T}^{*}=(c_{i,1}^{*},c_{i,2}^{*},c_{i,3}^{*},c_{i,4}^{*})$. In this scenario, where the adversary $\mathcal{A}$ does not query the value of $s_{i,j}^{*}={\mathcal{H}}_1(r_{i,j}^{*},h^b,t^b)$ from the random oracle ${\mathcal{H}}_1$, the challenge ciphertext remains as $C{T}^{*}$. From the perspective of $\mathcal{A}$, this ciphertext appears to be valid and correctly formed.

Decryption Query 2. The simulator handles decryption queries in a manner similar to that of Decryption Query 1, with the stipulation that no decryption queries are permitted on challenge ciphertext.

Guess. The adversary $\mathcal{A}$ returns a bit $0/1$ as the outcome of the challenge coin or outputs ⊥ to indicate failure. The challenge value is defined as follows:

$$Q^{*}=(h^b,t^b)=\left(g_q^{ab},g_q^{(z_1+z_{2}a)b}\right).$$

The list of random numbers includes entries of the form $\left(r_{i,j},h^{b_{i,j}},t^{b_{i,j}},s_{i,j}\right),j=1,\dots ,q_{{\mathcal{H}}_1}$. Notably, one query is $s_{i,j}^{*}={\mathcal{H}}_1\left(r_{i,j}^{*},h^{b^{*}},t^{b^{*}}\right)$. This leads to the following equality:

$${(g_q^b)}^{z_1}{(h^{b^{*}})}^{z_2}=t^{b^{*}}\iff g_q^{z_{1}b}{g}_q^{z_{2}a{b}^{*}}=g_q^{b^{*}(z_1+z_{2}a)}.$$

Consequently, it follows that $h^{b^{*}}=g_q^{ab}$. Therefore, the simulator $\mathcal{B}$ can identify the tuple $\left(r_{i,j}^{*},h^{b_{i,j}^{*}},t^{b_{i,j}^{*}},s_{i,j}^{*}\right)$ from the list of random numbers $\left(r_{i,j},h^{b_{i,j}},t^{b_{i,j}},s_{i,j}\right),j=1,\dots ,q_{{\mathcal{H}}_1}$, which satisfies the aforementioned equality. $\mathcal{B}$ utilizes this to solve the CDH problem instance in the class groups, indicating that there is no reduction loss in the aforementioned game model.

In summary, if an adversary $\mathcal{A}$ can break the scheme instance within time t and with advantage $\epsilon$, then the simulator $\mathcal{B}$ can solve the CDH problem instance in the class groups within time $t+T_s$ and with advantage $\epsilon /q_{\mathcal{D}}$. □

6. Comparison

Table 1. Comparison of algorithm complexity and functionality.

Scheme	Receivers	CipherSize (bits)	Decrypt	PayPrivacy	PayStats	Audit
S1 [17]	Single	256	-	√	-	-
S2 [26]	Single	512	High	√	-	-
S3 [23]	Single	2048	Low	√	-	-
Ours	Multiple	512	Low	√	√	√

compares payment amount privacy protection schemes [17,23,26] with our Confidential batch payment scheme. Key comparison criteria include the count of the number of receivers, decryption complexity, ciphertext size, payment privacy, payment statistic analysis, and auditing features, designated in the table as “Receivers”, “Decrypt”, “CipherSize”, “PayPrivacy”, “PayStats”, and “Audit”, respectively.

As shown in Table 1, our scheme allows for Confidential batch payments to multiple recipients in a single transaction, offering high payment efficiency and low costs; whereas other schemes can only pay a single recipient, resulting in lower efficiency and higher costs. In terms of ciphertext length and decryption complexity, S1 [17] has the shortest ciphertext but requires an additional round of interaction; S2 [26] has a shorter ciphertext but needs brute-force searching of discrete logarithms, leading to higher decryption complexity; S3 [23] has the lowest decryption complexity but the longest ciphertext; our scheme has both a shorter ciphertext and lower decryption complexity. Therefore, compared in terms of two key indicators, our scheme is the most optimal overall. Although each scheme offers privacy protection, only our scheme supports payment statistic analysis and audit functions, which are crucial in financial application systems.

Let n be the number of recipients. All three schemes [17,26,27], as well as our scheme, are constructed using homomorphic encryption, Sigma zero-knowledge proofs, and range proofs. Therefore, the ciphertext length for confidential payments in all of these schemes is composed of three parts.

• The ciphertext length of [17] is $(32n+64n+608n)$ bytes.
• The ciphertext length of [26] is $(64n+96n+608n)$ bytes.
• The ciphertext length of [23] is $256n+(2563+32)n+3424n$ bytes.
• The ciphertext length of our scheme is $64n+(64n+32)+(2{log}_2(n)+14)32$ bytes.

Therefore, compared to existing schemes [17,26,27], as the number of recipients n increases, our scheme has a greater advantage in terms of ciphertext length.

Overall, our scheme innovatively reconciles privacy protection with audit demands in blockchain payments, focusing on efficiency, privacy, and audit.

7. Experimental Analysis

Experiments were conducted on a system with an x86_64 Kernel, Win11, Intel i7-13700H CPU, and 16 GB RAM. We tested critically on homomorphic encryption/commitment in three schemes and ours, including CL homomorphic encryption on class groups, Pedersen commitment on secp256k1, and Paillier encryption with 2048-bit N. As shown in Figure 2, schemes [17,23,26], and our scheme are tested. Encryption/commitment time for the sender is labelled Commit/Encrypt, and decryption times for the receiver, sender, and two auditors as Decrypt1, Decrypt2, Audit1, and Audit2, respectively. The unit of time is milliseconds (ms).

Figure 2 indicates that Scheme S1 [17] has the lowest computation time of 0.03 ms but requires an additional decommitment step. Scheme S2 [26] offers quick encryption at 0.07 ms, yet decryption is impractical, taking $2^{32}$ ms for a 32-bit search. Schemes S3 [23] and our CL encryption have similar times, with Paillier encryption taking 0.82 ms for encryption and 1.53 ms for decryption, and CL encryption taking 0.89 and 1.55 ms for both processes. Additionally, our CL scheme facilitates auditing with a minimal effect on decryption time, thereby increasing its practicality. Additionally, our testing was focused solely on the running time of a single cipher, rather than multiple ciphers. The detailed test procedure is in the link: https://github.com/hsienfu/BatchPaymentSystem (accessed on 4 August 2024).

8. Conclusions

We proposed a confidential batch payment scheme with integrated auditing for enhanced data trading security. It features efficient batch processing for faster, more efficient payments, lowering costs and enhancing system performance. It ensures payment privacy and security while providing auditing functions. Senders can decrypt payment amounts, supporting payment statistic analysis. A balanced mechanism for auditing permits effective monitoring without infringing on privacy, and thwarting illegal activities like money laundering. Overall, our scheme innovatively reconciles privacy protection with the demand for auditing in blockchain payments, focusing on efficiency, privacy, and auditing.