Identity privacy protection method based on verifiable shuffle

Abstract

An identity privacy protection method based on verifiable shuffling, in the contract initialization and deposit stage, set the fixed token amount of each deposit, for verifying whether all participants deposit token to the specified public address according to the amount of amt parameter and the validity of public key when depositing, when the verification is passed, the public key of the participant is recorded in the initPubKeys[] array. In the alternating shuffling stage and challenge stage, any receiver is allowed to challenge the recent shuffling stage as a challenger, and when the challenge is established, the deposit of the current shuffler is returned to the challenger, at the same time, the wrong shuffling result is revoked and the public key set of the last correct result is returned to restart the shuffling stage. Finally, the final accumulated shuffling constant is generated, and the public key of any receiver B is converted into the receiver through the private key s B Prove its identity to the contract in a signed way, so as to safely extract token. The application combines encryption technology and off-chain processing with on-chain verification, effectively reduces resource consumption and cost in blockchain operation under the premise of ensuring transaction security.

Description

Technical Field

[0001] This invention relates to a technology in the field of information security, specifically a method for protecting identity privacy based on verifiable shuffling. Background Technology

[0002] Blockchain technology still has significant shortcomings in privacy protection. Transaction data on public blockchains can be analyzed on-chain, allowing attackers to associate user transactions with public keys and thus infer their true identity and financial information. In the field of electronic voting, traditional systems rely on anonymized identity data from centralized institutions, but these systems are prone to single points of failure and metadata leaks. While existing blockchain voting solutions improve transparency, they may expose voter preferences through transaction graph analysis, and even lead to bribery or coercion, threatening the fairness and security of elections. Summary of the Invention

[0003] This invention addresses the problems of low efficiency, high on-chain computation costs, and complex operation of existing decentralized identity privacy protection technologies. It proposes a verifiable shuffling-based identity privacy protection method that combines encryption technology and off-chain processing with on-chain verification to effectively reduce resource consumption and costs in blockchain operations while ensuring transaction security.

[0004] This invention is achieved through the following technical solution:

[0005] This invention relates to a method for protecting identity privacy based on verifiable shuffling, comprising:

[0006] Step 1, Contract Initialization and Deposit Phase: Set a fixed amount of tokens to be deposited each time, i.e., the amt parameter, to verify whether all participants deposit tokens into the specified public address according to the amount in the amt parameter and the validity of the public key. When the verification is successful, the participants' public keys are recorded in the initPubKeys[] array.

[0007] Step 2: Alternate between the shuffling phase and the challenge phase. Each round of shuffling is followed by a challenge phase, allowing any receiver to challenge the most recent shuffling phase. If the challenge is successful, the current shuffler's deposit is returned to the challenger, the incorrect shuffling result is revoked, and the shuffling phase is restarted from the public key set of the previous correct result.

[0008] Step 3: After the protocol has completed all shuffling rounds, the final cumulative shuffling constant will be generated. And convert the public key of any recipient B into The recipient uses their private key. B Prove your identity to the contract by signing, thereby securely retrieving your token.

[0009] This invention relates to a system for implementing the above-mentioned method, comprising: a blockchain unit, a payment hub unit, a user management unit, and a token processing unit, wherein: the blockchain unit performs distributed ledger recording and smart contract deployment processing based on transaction data information, generating immutable transaction vouchers and contract execution records; the payment hub unit performs deposit verification, shuffling operations, and fund withdrawal processing based on user transaction requests and smart contract rule information; the user management unit performs public-private key pair generation and identity binding processing based on blockchain network connection information, establishing a secure communication channel between the user and the payment hub; and the token processing unit performs token generation and cryptographic signature processing based on blockchain transaction format specification information, forming a transaction data structure that conforms to the requirements of the smart contract. Technical effect

[0010] This invention employs a verifiable shuffling algorithm based on SM2, combined with Chaum-Pedersen zero-knowledge proofs to verify the shuffling parameters on-chain, ensuring that the permutation process satisfies the discrete logarithmic equivalence constraint. Compared with existing technologies, this invention fundamentally blocks malicious data injection paths and reduces gas consumption, thus saving costs. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the invention;

[0012] Figure 2 This is a flowchart of the present invention;

[0013] Figure 3 Flowchart of Chaum-Pedersen zero-knowledge proof;

[0014] Figure 4 This is a flowchart of the shuffling process;

[0015] Figure 5 Flowchart for the challenge phase;

[0016] Figure 6 This is a schematic diagram illustrating the effect of an example. Detailed Implementation

[0017] like Figure 1 and Figure 2 As shown in the figure, this embodiment relates to an identity privacy protection method based on verifiable shuffling, which includes: contract initialization and deposit stage, alternating shuffling and challenge stage, and withdrawal stage.

[0018] Step 1, Contract Initialization and Deposit Phase: Set a fixed amount of tokens to be deposited each time, i.e., the amt parameter, to verify whether all participants deposit tokens into the specified public address according to the amount in the amt parameter and the validity of the public key. When the verification is successful, the participants' public keys are recorded in the initPubKeys[] array.

[0019] The amt parameter is set to 1 by default.

[0020] Step 2: Alternate between the shuffling phase and the challenge phase. Each round of shuffling is followed by a challenge phase, allowing any receiver to challenge the most recent shuffling phase. If the challenge is successful, the current shuffler's deposit is returned to the challenger, the incorrect shuffling result is revoked, and the shuffling phase is restarted from the public key set of the previous correct result.

[0021] The aforementioned shuffling phase specifically includes:

[0022] a) The shuffler, in compliance with the protocol, generates a random secret multiplier c and encrypts it. Then, while rearranging the transformed public key, the shuffler submits an updated shuffle cumulative constant along with a Chaum-Pedersen proof that ensures the accuracy and legitimacy of the updated shuffle cumulative constant.

[0023] The shuffling accumulation constant is calculated using the secret multiplier c and the rearranged public key.

[0024] The aforementioned conversion refers to encryption using the SM2 algorithm.

[0025] The rearrangement is implemented using, but is not limited to, the Fisher-Yates shuffle algorithm.

[0026] The updated shuffle accumulation constant refers to the constant generated during the shuffle process, which is used by the receiver to verify the integrity of the shuffle and withdraw funds after the final shuffle. New accumulation constant. Depend on Generate, where: E() is the SM2 encryption algorithm; c is the cumulative shuffling constant for the i-th round; i Let be the random secret multiplier for the i-th round.

[0027] like Figure 3 As shown, the Chaum-Pedersen proof is generated and verified in the following ways, specifically including:

[0028] 1. The verifier randomly selects an integer s from the group of integers modulo q, generates a cryptographic commitment value for s, and sends the commitment to the prover.

[0029] 2. The prover randomly selects an integer r from the integer group modulo q, calculates the temporary elliptic curve point and sends it to the verifier, specifically: y1 = r·G; y2 = r·B, where: G is the base point of the elliptic curve and B is the elliptic curve public key point preset by the protocol.

[0030] 3. The verifier publicly reveals the previously generated random number s, thus removing the hidden state of the commitment.

[0031] 4. The prover calculates the response value z = (r + a·s) mod q according to the following formula, where a is the secret scalar value bound in the protocol, and sends z to the verifier.

[0032] 5. The verifier proves something by verifying whether two conditions are met simultaneously, including:

[0033] Condition 1: Check whether z·G is equal to y1+s·A, where: A is the public key point corresponding to the secret scalar a, i.e. A=a·G.

[0034] Condition 2: Check whether z·B is equal to y2+s·C, where: C is the public key point associated with B in the protocol, which must satisfy C=a·B.

[0035] b) Upload the shuffled public key set, the updated cumulative constant, and the Chaum-Pedersen proof to the contract, allowing anyone to verify the correctness of the shuffle and ensuring that the shuffle can continue after the challenge round.

[0036] like Figure 3 As shown, a Chaum-Pedersen proof is generated to ensure the correctness of the shuffling operation. This proof demonstrates log... G (A) = log B (C) Relationship. The contract only accepts shuffle transactions during the shuffle phase and if the proof passes verification; otherwise, it will be rejected outright.

[0037] The aforementioned challenge phase specifically includes:

[0038] i) Any recipient uses their private key to verify whether the corresponding shuffled public key is correctly included in the current public key set: if the recipient's public key is not correctly included in the set, a challenge is initiated.

[0039] ii) The challenger provides a Chaum-Pedersen proof to demonstrate that the public key set in the previous round (round i-1) was intact but has been corrupted in the current round (round i).

[0040] iii) The privacy protection contract verifies the validity of the Chaum-Pedersen proof provided by the challenger to confirm that there is indeed a problem in the current round. If the verification passes, the result of the current shuffling phase is deemed invalid, and the shuffling starts again from the public key set of the previous round; otherwise, the challenge fails.

[0041] like Figure 3 As shown, the Chaum-Pedersen proof verifies the validity of the discrete logarithmic relation by checking whether the two equations zG≡sA+y1 and zB≡sC+y2 hold true. If the verification passes, it returns true, indicating that log_G(A)=log_B(C) holds true; otherwise, it returns false to reject the proof.

[0042] The verification described herein employs, but is not limited to, the techniques described in "Wallet Databases with Observers" (Advances in Cryptology—CRYPTO'92, Conference paper pp 89–105).

[0043] Step 3: After the protocol has completed all shuffling rounds, the final cumulative shuffling constant will be generated. And convert the public key of any recipient B into The recipient uses their private key. B Prove your identity to the contract by signing, thereby securely retrieving your token.

[0044] The initial public key s of receiver B B G is in the initial public key set initPubKeys[].

[0045] The shuffling constant mentioned above in: c is the cumulative constant for the penultimate round of shuffling. final-1 Let be the random secret multiplier for the i-th round.

[0046] Through specific practical experiments, in a Macbook Pro 2021 environment, a program was written in Solidity and simulated on the Ganache platform. Specifically, the off-chain obfuscation part used the SM2 algorithm, and the digital signature part used ECDSA signature on the secp256k1 curve. This was applied to three U... A and U B The following conditions were tested:

[0047] Phase 1, Initial Deposit, specifically includes:

[0048] 1.1 User A deposits (sent to B): User A generates private key sk APK with public key A =sk A G. User A's target is user B's public key PK. B Therefore, Deposit(tumblers, sk) is called. A ,pk B Deposit 1 token. After the contract verifies the amount, record the target public key (PK). B To initPubKeys[]. On-chain state: initPubKeys[] = [PK B ];

[0049] 1.2 User C deposits (sent to D): User C generates private key s C PK with public key C =s C G. User C's target is user D's public key PK. D Therefore, Deposit(tumblers, sk) is called. C ,pk D Deposit 1 token. The contract records the target public key PK_D. On-chain state: initPubKeys[] = [PK_D] B PK D ].

[0050] Phase 2, the obfuscation process, specifically includes:

[0051] 2.1 First round of shuffling (users A and C participate): The shuffling party selects a random multiplier c1 and generates a permutation rule π1;

[0052] 2.2 Shuffling Operation:

[0053] i) Convert the public key: PK1[j] = E(c1)·PK0[j], where: PK_0 is the initial set;

[0054] ii) Update the cumulative constant: Where: initial

[0055] iii) Submit the shuffle result: PK1 = [E(c1)PK π(B) ,E(c1)PK π(D) [and Chaum-Pedersen's proof;]

[0056] iv) On-chain verification: After verifying the validity of the contract proof, update the state to PK1.

[0057] 2.3 First Round Challenge:

[0058] i) User A checks if the public key after the shuffle contains

[0059] ii) User C checks whether the public key contains the shuffled value.

[0060] If the verification passes and no challenge is triggered, the shuffle result is retained.

[0061] 2.4 Second round of shuffling (users A and C continue):

[0062] i) The shuffler chooses a new random multiplier c2 and a permutation π2;

[0063] ii) Convert the public key: PK2[j] = E(c2)·PK1[j];

[0064] ii) Update the cumulative constant:

[0065] iv) Submit and verify the shuffle results, and update the on-chain state to PK2.

[0066] Phase 3, final withdrawal, specifically includes:

[0067] 3.1 User B withdraws money (receiving deposit from User A):

[0068] i) User B calculates the final public key:

[0069] ii) Generate signature: using generator Message Signature

[0070] iii) Call Release 1 token after the contract verifies the signature.

[0071] 3.2 User D withdraws money (receiving deposits from C) in the same way.

[0072] like Figure 6 As shown in Table 1, this represents the number of take-out transactions that each protocol can accommodate within a block under different numbers of participants.

[0073] Table 1. Comparison of computational consumption for each stage of each protocol

[0074] In summary, this invention not only achieves an efficient identity privacy protection process, but also significantly reduces gas consumption, improving the overall system performance and user experience.

[0075] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.

Claims

1. A method for protecting identity privacy based on verifiable shuffling, characterized in that, During contract initialization and deposit phases, a fixed amount of tokens is set for each deposit. This is used to verify whether all participants deposit tokens into the specified public address according to the amount specified by the `amt` parameter and to verify the validity of the public keys. When verification is successful, the participants' public keys are recorded in the `initpubKeys[]` array. During the alternating shuffling and challenge phases, any receiver is allowed to challenge the most recent shuffling phase. If the challenge is successful, the current shuffler's deposit is returned to the challenger, the incorrect shuffling result is revoked, and the shuffling phase restarts from the public key set of the previous correct result. Finally, the final accumulated shuffling constant is generated. And convert the public key of any recipient B into The recipient uses their private key. B The token is retrieved securely by proving its identity to the contract through a signature, whereby: This is the cumulative shuffling constant.

2. The identity privacy protection method based on verifiable shuffling according to claim 1, characterized in that, The aforementioned shuffling phase specifically includes: a) The shuffler, in compliance with the protocol, generates a random secret multiplier c and encrypts it. Then, while rearranging the transformed public key, the shuffler submits an updated shuffle cumulative constant along with a Chaum-Pedersen proof that ensures the accuracy and validity of the updated shuffle cumulative constant. b) Upload the shuffled public key set, the updated cumulative constant, and the Chaum-Pedersen proof to the contract, allowing anyone to verify the correctness of the shuffle and ensuring that the shuffle continues after the challenge round.

3. The identity privacy protection method based on verifiable shuffling according to claim 1, characterized in that, The aforementioned challenge phase specifically includes: i) Any recipient uses their private key to verify whether the corresponding shuffled public key is correctly included in the current public key set: if the recipient's public key is not correctly included in the set, a challenge is initiated; ii) The challenger provides a Chaum-Pedersen proof demonstrating that the public key set from the previous round (round i-1) was intact but has been corrupted in the current round (round i); iii) The privacy protection contract verifies the validity of the Chaum-Pedersen proof provided by the challenger using the verifyCP algorithm to confirm that there is indeed a problem in the current round. If the verification passes, the result of the current shuffling phase is deemed invalid, and the shuffling starts again from the public key set of the previous round; otherwise, the challenge fails.

4. The identity privacy protection method based on verifiable shuffling according to claim 2 or 3, characterized in that, The Chaum-Pedersen proof is generated and verified in the following ways, specifically including: 1) The verifier randomly selects an integer s from the group of integers modulo q, generates a cryptographic commitment value for s, and sends the commitment to the prover; 2) The prover randomly selects an integer r from the group of integers modulo q, calculates a temporary elliptic curve point, and sends it to the verifier, specifically: y1 = r·G; y2 = r·B, where: G is the base point of the elliptic curve, and B is the elliptic curve public key point preset by the protocol. 3) The verifier publicly reveals the previously generated random number s, thus removing the hidden state of the commitment; 4) The prover calculates the response value z = (r + a·s) mod q according to the following formula, where a is the secret scalar value bound in the protocol, and sends z to the verifier; 5) The verifier proves something by verifying whether two conditions are met simultaneously, including: Condition 1: Check whether z·G is equal to y1+s·A, where: A is the public key point corresponding to the secret scalar a, i.e. A=a·G; Condition 2: Check whether z·B is equal to y2+s·C, where: C is the public key point associated with B in the protocol, which must satisfy C=a·B.

5. The identity privacy protection method based on verifiable shuffling according to claim 2 or 3, characterized in that, The Chaum-Pedersen proof verifies the validity of the discrete logarithmic relation by checking whether the two equations zG≡sA+y1 and zB≡sC+y2 hold true. If the verification passes, it returns true, indicating that log_G(A)=log_B(C) holds true; otherwise, it returns false to reject the proof.

6. A verifiable shuffling-based identity privacy protection system implementing the method of any one of claims 1-5, characterized in that, include: The system includes a blockchain unit, a payment hub unit, a user management unit, and a token processing unit. The blockchain unit performs distributed ledger recording and smart contract deployment based on transaction data information, generating immutable transaction certificates and contract execution records. The payment hub unit performs deposit verification, shuffling operations, and fund withdrawal processing based on user transaction requests and smart contract rules; the user management unit generates public and private key pairs and binds identities based on blockchain network connection information, establishing a secure communication channel between users and the payment hub; the token processing unit generates tokens and performs encrypted signature processing based on blockchain transaction format specifications, forming a transaction data structure that meets the requirements of smart contracts.

Images