Range proof method, apparatus, device, and storage medium

Abstract

The application discloses a range proof method, device and equipment and a storage medium, and relates to the field of data processing. The method comprises the following steps: obtaining target proof information, performing range extraction on the target proof information according to a private key of a verifier, determining a data range corresponding to the verifier, and providing the data range to the verifier to enable the verifier to perform range verification. According to the application, the target proof information is extracted according to the verifier, different data ranges are extracted according to the identities of different verifiers to enable the verifiers to perform verification, when the trust degree of the verifier to the proof provider is high, the range that can be extracted by the verifier is more accurate, the privacy of the data can be better protected, and the risk management level is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a range verification method, apparatus, device, and storage medium. Background Technology

[0002] Range proofs concern themselves with efficiently proving that a value lies within a certain range (e.g., where the range is a positive integer). Range proofs are a special case of zero-knowledge proofs, which are protocols where the prover demonstrates to the verifier that a given statement is true without conveying any additional information beyond stating the fact. However, prover trust in verifiers varies depending on their identity, and current range proof methods cannot effectively protect privacy for different verifiers, leading to significant risks in the verification process.

[0003] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this invention is to provide a range verification method, apparatus, device, and storage medium, which aims to solve the technical problem that the existing technology cannot effectively protect the privacy of verifiers with different identities, resulting in a high risk in the verification process.

[0005] To achieve the above objectives, the present invention provides a scope proof method, the method comprising the following steps:

[0006] Obtain the target proof information;

[0007] Based on the verifier's private key, the target proof information is range-extracted to determine the data range corresponding to the verifier;

[0008] The data range is provided to the verifier so that the verifier can perform range verification.

[0009] Optionally, the step of extracting a range of the target proof information based on the verifier's private key to determine the data range corresponding to the verifier includes:

[0010] Based on the verifier's private key, the target proof information is range-extracted to determine the left and right boundaries of the range.

[0011] The data range corresponding to the verifier is determined based on the left boundary and the right boundary of the range.

[0012] Optionally, before determining the data range corresponding to the verifier by performing range extraction on the target proof information based on the verifier's private key, the method further includes:

[0013] The target proof information is sent to the verifier so that the verifier can verify based on the target proof information;

[0014] When the verifier passes the verification, the step of extracting the target proof information based on the verifier's private key to determine the data range corresponding to the verifier is executed.

[0015] The proof process ends when the verifier fails to verify the proof.

[0016] Optionally, sending the target proof information to the verifier so that the verifier performs verification based on the target proof information includes:

[0017] Obtain the target protocol;

[0018] The target protocol and the target proof information are sent to the verifier so that the verifier can verify the target protocol based on the target proof information.

[0019] Optionally, obtaining the target proof information includes:

[0020] Obtain security parameters;

[0021] Obtain common parameters based on the security parameters;

[0022] The common parameters are processed to obtain the target proof information.

[0023] Optionally, the public parameters include a public key and a private key. Obtaining the public parameters based on the security parameters includes:

[0024] Based on the security parameters, obtain the public reference string and function family;

[0025] Obtain the public key and private key based on the public reference string and the function family.

[0026] Optionally, processing the public parameters to obtain target proof information includes:

[0027] Obtain evidence information;

[0028] Based on the evidence information, the public parameters are processed to obtain candidate proof information;

[0029] The bit value is determined based on the candidate proof information and the preset declaration information;

[0030] The target proof information is obtained based on the bit value and the candidate proof information.

[0031] Furthermore, to achieve the above objectives, the present invention also proposes a range verification device, the range verification device comprising:

[0032] The information acquisition module is used to acquire target proof information;

[0033] The range extraction module is used to extract the range of the target proof information based on the verifier's private key, and determine the data range corresponding to the verifier;

[0034] The range verification module is used to provide the data range to the verifier so that the verifier can perform range verification.

[0035] Furthermore, to achieve the above objectives, the present invention also proposes a range proof device, the range proof device comprising: a memory, a processor, and a range proof program stored in the memory and executable on the processor, the range proof program being configured to implement the steps of the range proof method as described above.

[0036] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a range proof program, which, when executed by a processor, implements the steps of the range proof method as described above.

[0037] This invention obtains target proof information, extracts a range from the target proof information based on the verifier's private key, determines the data range corresponding to the verifier, and provides the data range to the verifier so that the verifier can perform range verification. Because this invention extracts a range from the target proof information based on the verifier's identity, it can extract different data ranges for verification based on the verifier's identity. When the prover's trust in the verifier is high, the range that the verifier can extract is more accurate, which can better protect data privacy and effectively improve the level of risk management. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the structure of the hardware operating environment proof device involved in the embodiments of the present invention;

[0039] Figure 2 This is a flowchart illustrating the first embodiment of the method for proving the scope of the present invention;

[0040] Figure 3 This is a schematic diagram of the verification steps in the first embodiment of the method for proving the scope of the present invention;

[0041] Figure 4 This is a flowchart illustrating the second embodiment of the method for proving the scope of the present invention;

[0042] Figure 5 A schematic diagram of the generator vector g in the second embodiment of the method for proving the scope of the present invention;

[0043] Figure 6 This is a schematic diagram of the generator vector h in the second embodiment of the method for proving the scope of the present invention;

[0044] Figure 7 The second embodiment of the method for proving the scope of the present invention A schematic diagram;

[0045] Figure 8 The second embodiment of the method for proving the scope of the present invention A schematic diagram;

[0046] Figure 9 The second embodiment of the method for proving the scope of the present invention and A schematic diagram;

[0047] Figure 10 The second embodiment of the method for proving the scope of the present invention A schematic diagram;

[0048] Figure 11 This is a structural block diagram of the first embodiment of the device for proving the scope of the present invention.

[0049] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0050] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0051] Reference Figure 1 , Figure 1 This is a schematic diagram of the device structure demonstrating the scope of the hardware operating environment involved in the embodiments of the present invention.

[0052] like Figure 1As shown, the scope of the device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0053] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the scope of the proof device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0054] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and a range verification program.

[0055] exist Figure 1 In the range proof device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in the range proof device of the present invention can be set in the range proof device, and the range proof device calls the range proof program stored in the memory 1005 through the processor 1001 and executes the range proof method provided in the embodiment of the present invention.

[0056] This invention provides a range proof method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating a first embodiment of a range proof method according to the present invention.

[0057] In this embodiment, the range proof method is applied to the prover, and the range proof method includes the following steps:

[0058] Step S10: Obtain the target proof information.

[0059] It should be understood that the execution subject of the method in this embodiment may be a scope verification device with data processing, network communication and program running functions, such as a computer, or other devices or equipment that can achieve the same or similar functions. Here, the scope verification device (hereinafter referred to as the verifier) ​​is used as an example for explanation.

[0060] It should be noted that this embodiment applies non-interactive zero-knowledge proof of functional knowledge (NIZK) to range proof. The specific construction of the range proof of functional knowledge under the discrete logarithm setting in this embodiment is based on the Bulletproofs protocol. Bulletproofs can effectively prove that a value submitted via the Peterson commitment mode is in the range [0, 2]. k In [-1], where k is an integer. The non-interactive zero-knowledge proof of functional knowledge is defined as follows: Let... It is an NP language, associated with an NP relation. It is a family of functions. This embodiment includes the following 6 steps:

[0061] Taking the safety parameter λ as input, the algorithm is set to output a common reference string crs and a family of functions. If crs is a uniformly distributed random string, then we say that fNIZK is in the common random string model.

[0062] Input a common reference string crs and a family of functions The public key generation function outputs a public key pk and a master private key msk. We assume that pk implicitly includes... Information.

[0063] SKGen(crs, msk, f) → sk f Input a public reference string crs, a master private key msk, and a function. The key generation algorithm outputs a key sk f .

[0064] Prove(crs, pk, x, w) → π: Input a public reference string crs, a public key pk, a statement x, and a proof w. The proof algorithm outputs a proof π.

[0065] Verify(crs, x, π) → {0, 1}: Take a public reference string crs, a statement x, and a proof π as input. The verification algorithm outputs a bit b ∈ {0, 1}.

[0066] Extract(crs, x, π, sk) f →y: Input a public reference string crs, a declaration x, a proof of π, and a key sk for a function f. f The extraction algorithm outputs y.

[0067] Furthermore, in order to accurately obtain the target proof information, step S10 above may include:

[0068] Obtain security parameters;

[0069] Obtain common parameters based on the security parameters;

[0070] The common parameters are processed to obtain the target proof information.

[0071] Understandably, let λ be a safety parameter. It is a group ordered by prime number p, and it has two generators g and h(log p). g h is unknown), n is a relatively small integer representing the maximum bit length of the witness value to be proven. Let RP = (Setup, Prove, Verify) be an NIZK pattern (correlation). This pattern is inspired by the Fait-Shamir protocol Prot. rp superior.

[0072] Furthermore, in order to accurately obtain the public parameters, which include the public key and private key, obtaining the public parameters based on the security parameters includes:

[0073] Based on the security parameters, obtain the public reference string and function family;

[0074] Obtain the public key and private key based on the public reference string and the function family.

[0075] Then, we propose the construction of a range proof for functional knowledge. This model comprises five algorithms fRP = (Setup, KGen, Prove, Verify, Extract), details of which are as follows:

[0076] Input the security parameter λ, which runs the RP settings, for example, crs←RP.Setup(1 λ Then it chooses a family of functions. Note that for range proofs, the family of functions relates to different ranges. Here, for any It represents a range [0, 2]. k -1], where k is an integer less than n. Finally, the algorithm outputs...

[0077] KGen(crs, f) → (pk, sk): Input a common reference string crs and a function It outputs a key pair Where sk is from The public key pk is randomly selected. We assume that a public key pk contains (perhaps implicitly) information about the function f.

[0078] Prove(crs,{pk i} i∈[m] x, w) → π: Input public reference string crs, m distinct public keys {pk i} i∈[m] A declaration x (where x represents a range [0, 2)) n Given a piece of evidence w, the algorithm generates a proof as follows:

[0079] We denote w as v0. As mentioned before, n is the maximum bit length of w, therefore υ0∈[0, 2]. n -1]. For any f i (i∈[m]), select a range [a i b i ] such that υ0∈[a i b i ]and Where k i <n. This requires a i ∈A i A i It is a polynomial and a public set, for example, |A i |=poly(λ)(Since n is a small integer, |A i | can be a polynomial in λ), and is controlled by f i The decision is made by [the algorithm]. Finally, the algorithm sets v. i =v0-a i .

[0080] For any v i (i∈[0,m]), computed using the Peterson commitment model in It is a random number. For any i∈[m], calculate

[0081] set up Then, regarding the following relationship

[0082]

[0083] Running π RP ←RP.Prove(crs,x′=(V,k0,(k i α i , pk i ) i∈[m] ), w′=(v,r)); Finally, output the proof.

[0084] π←(π RP ,V,(k i α i , pk i ) i∈[m] ).

[0085] Verify(crs, x, π) → {0, 1}: Given a common reference string crs, a declaration x, and a proof π, it first parses π as π = (π / 2) RP ,V,(k i α i , pk i ) i∈[m] Then if

[0086] RP.Verify(crs,x′=(V,k0,(k i α i , pk i ) i∈[m] ), π RP ) = 1,

[0087] It outputs 1 otherwise.

[0088] Extract(crs, x, π, sk) i →y: Input public reference string crs, a statement x, a proof π, and a key sk i It calculates And find a i ∈A i Make Finally it returned

[0089] Furthermore, to improve processing efficiency, the aforementioned common parameters are processed to obtain target proof information, including:

[0090] Obtain evidence information;

[0091] Based on the evidence information, the public parameters are processed to obtain candidate proof information;

[0092] The bit value is determined based on the candidate proof information and the preset declaration information;

[0093] The target proof information is obtained based on the bit value and the candidate proof information.

[0094] It should be noted that this embodiment demonstrates how to handle relationships. Create an NIZK schema. We originally intended to apply Bulletproofs directly here, but the relationship is slightly different from the one in the following formula.

[0095]

[0096] Where n is the bit length of v, V is the submission of v, and r is the randomness used in the submission. In the relation and The main difference between them is There are multiple ranges and multiple properties of randomness (used to generate submissions, such as V and V). i The challenge here concerns the sub-relations of linear combinations of randomness. We will now briefly outline the main idea behind how we prove this relation.

[0097] We first consider the following relationship:

[0098]

[0099] Where V is a submission of value υ, r is the randomness used in the submission, k is the bit length of v, pk is a public key, and α is pk raised to the power of r. This is in contrast to the basic relationships in Bulletproofs. relation Having one more sub-relation with respect to randomness r (or one more declaration α), we can observe the relations of Bulletproofs. Randomness *r* is also considered as evidence, so through the reliability of Bulletproofs (or computational evidence extension simulation), we can extract randomness *r* by rewinding. Therefore, based on Bulletproofs, we only need to embed some aspects of the α-tube into the proof.

[0100] Then, we further considered expanding the relationship. The relationship is as follows:

[0101]

[0102] Comparison and Relationship The above relationship There are two submissions, one for values ​​v1 and the other for v2, with bit lengths k1 and k2 respectively. Therefore, There are two range proofs for the sub-relation. Another difference lies in... In this context, the sub-relation concerning randomness is different. More precisely, it states that the discrete logarithm of α is a linear combination of randomness (e.g., r1-r2).

[0103] By introducing and We first define the relationship Separate into two relations, that is, two different ones. Then, we use the "AND" operation to combine the two relations above and obtain another relation.

[0104]

[0105]

[0106]

[0107] We can know that if some statement-evidence is a... In terms of legal pairings, for example, Then declare - evidence pair ((V1, V2, k1, k2, α1, α2, pk), (v1, v2, r1, r2)) for This is a valid pairing, for example, Where α = α1 / α2.

[0108] Therefore, the protocol Prot two The proof can be generated via the Prot protocol. ext The proof is generated (e.g., by receiving the same challenge from the verifier v and running the protocol Prot). ext (The proof is generated twice). It can be observed that proof generation does not require α, α1, or α2. The only challenge is that we need to slightly verify the verification protocol.

[0109] With Prot two Following this line of thought, we can target relationships Create an interactive protocol Prot rp Then, by applying the Fiat-Shamir transform, we can obtain a NIZK RP. Prot rp Here we Prot two The main idea. In other words, for each v i (i∈[0,m]), we call Prot rp Let's generate the proof. Note that we made a minor modification to v0.

[0110] For verification, the protocol Prot rp With Protocol Prot two They are very similar. More precisely, Prot rp The verification follows the Protocol Prot ext The verification for each v i Except for the second part, see Figure 3 , Figure 3 To verify the step diagram, Prot rp (For example, the verification for v3) is as follows:

[0111] For every i∈[0,m]computes:

[0112]

[0113]

[0114] / / compute comitment to l (i) (x)and r (i) (x)

[0115]

[0116]

[0117] Then compute

[0118]

[0119] For completeness, most of the computations for verification are similar to those for Prot. ext The verification (of the above formula) is then performed. Therefore, we omit the analysis of these calculations and demonstrate why the verification passes.

[0120] For any declaration (V, (k) i α i , pk i ) i∈[m] ) and evidence (v, r) (belonging to ), and also the protocol Prot rp The generated copy, such as We have,

[0121]

[0122] Note Prot two The completeness of this implies that the second equation in the above formula holds true. Therefore, the protocol Prot rp Completeness is satisfied. Reliability is determined by Prot. extThis is guaranteed by its reliability.

[0123] Step S20: Extract the range of the target proof information based on the verifier's private key to determine the data range corresponding to the verifier.

[0124] It should be noted that the main idea behind this embodiment is: first, assume a value to be proven, v ∈ [0, 2]. k -1], a function f i Indicates a smaller interval Then we find an a i Make v i =va i Falling Within the scope. Bulletproofs support proof. The remaining step is for the verifier to use their private key to obtain a. i If encrypt a i Therefore, we also need to ensure that relation a i +v i =v (for example, given v and v) i Peterson's commitment, given a i Given the ciphertext, we need to prove a using zero-knowledge methods. i +v i =v). An encryption algorithm should satisfy the following two conditions: it should be easy to prove that the ciphertext is well-structured, and the encryption mode should conform to the Petersen commitment. Therefore, the prover allows i th The verifier finds 'a' by repeatedly trying and enumerating. i Instead of encrypting a i (We can do this because we are only considering a small range here). Then, we provide an intermediate variable. It is related to random numbers r and r i Related (these two variables will be used in commitment generation) to help the verifier find a i .

[0125] Furthermore, to enhance verification security, the following steps are included before step S20:

[0126] Obtain the target protocol;

[0127] The target protocol and the target proof information are sent to the verifier so that the verifier can verify the target protocol based on the target proof information;

[0128] When the verifier passes the verification, the step of extracting the target proof information based on the verifier's private key to determine the data range corresponding to the verifier is executed.

[0129] The proof process ends when the verifier fails to verify the proof.

[0130] It should be noted that this describes a relevant implementation scenario: An electronic cryptocurrency account A has just completed a transfer of 666, while the daily maximum transfer limit for the account is known to be 65535 (2 16 -1). A wants to prove to other accounts that they have indeed completed a transfer without revealing the specific amount. Furthermore, the range of transfer amounts A can extract varies depending on their level of trust in the other accounts. For example, for ordinary account B, with the lowest level of trust, the range is only [0, 65535]; for fund manager account C, the range is relatively more precise; and for close partner account D, with the highest level of trust, the range may be even smaller. Non-interactive zero-knowledge proofs (NIZK) of functional knowledge can be applied here. A simplified description of the NIZK process is as follows:

[0131] Setup phase: Generates the common reference string crs. Generate a group G ordered by large prime numbers p, where g and h are generators of group G. It is a family of functions, representing different ranges in the range proof. Here, for each Represents a range [0, 2] k -1], where k is an integer smaller than n, and n is the bit length of the evidence. Finally, output...

[0132] K Gen phase: Input a public reference string crs and a function f, output a key pair Where sk is The public key pk is randomly selected from the given information. We assume that the public key pk contains information about the function f.

[0133] Prove Prove Phase: Input public reference string crs, m distinct public key pairs {pk i} i∈[m] A declaration x (here declared as a range [0, 2)) n -1]) and one piece of evidence w (here referring to the score):

[0134] Let w be represented as v0, and v0∈[0, 2]. n -1]. For each f i (i∈[m]), select a range [a i b i ] such that v0∈[a i b i ],and Where ki <n. It requires a i ∈A i A i It is a polynomial and a common set, by f i To decide. The final algorithm sets v i =v0-a i .

[0135] For each v i Calculate using Peterson commitment model in It is a random number. For each i∈[m], calculate

[0136] set up Then run π RP ←RP.Prove(crs,x′=(V,k0,(k i α i , pk i ) i∈[m] ), w′=(v,r)). Finally, output the proof that π←(π RP ,V,(k i α i , pk i ) i∈[m] ).

[0137] Verify phase: Input a common reference string crs, a declaration x (here in the range [0, 64]) and a proof π, which first resolves π to π = (π / 2) RP ,V,(k i α i , pk i ) i∈[m] If RP.Verify(crs, x′=(V, k0, (k i α i , pk i ) i∈[m] ), π RP If ) = 1, then output 1; otherwise, output 0.

[0138] Extract phase: Input public reference string crs, a declaration x (here in the range [0, 64]), a proof π, and a key sk i It calculates Then find a i ∈A i Make Finally, it returned.

[0139] Step S30: Provide the data range to the verifier so that the verifier can perform range verification.

[0140] It should be noted that for special honest verifiers with zero knowledge, it is also very similar to Prot. ext Yes. Here we also built Prot. rp Simulator. Given a declaration (V, k0, (k... i α i , pk i ) i∈[m] Given the challenges (y, z, x), the simulator Sim calculates them as follows:

[0141] 1. For each i∈[m], it randomly selects from its respective neighborhood.

[0142] 2. For each i∈[m], it calculates

[0143] 3. For each i∈[m], it is calculated as follows:

[0144]

[0145] 4. For each i∈[m], it randomly selects from its respective neighborhood. Then calculate Refer to the following formula:

[0146]

[0147] 5. Finally, the Sim simulator returns.

[0148] It can be verified very easily that: 1) the verifier accepts the proof; 2) those generated by the interactive protocol are indistinguishable. Therefore, the protocol Prot rp It is a special HVZK. Influenced by Bulletproofs, we apply the inner product argument several times for each v i We can obtain a proof of its logarithmic size. Finally, using the Fiat-Shamir transform, we can obtain a NIZKRP.

[0149] This embodiment obtains target proof information, extracts a range of the target proof information based on the verifier's private key, determines the data range corresponding to the verifier, and provides the data range to the verifier so that the verifier can perform range verification. Since this embodiment extracts a range of the target proof information based on the verifier's identity, it can extract different data ranges for the verifier to verify based on the verifier's identity. When the prover's trust in the verifier is high, the range that the verifier can extract is more accurate, which can better protect data privacy and effectively improve the level of risk management.

[0150] refer to Figure 4 , Figure 4 This is a flowchart illustrating a second embodiment of a range proof method according to the present invention.

[0151] Based on the first embodiment described above, in this embodiment, step S20 includes:

[0152] Step S201: Extract the range of the target proof information based on the verifier's private key to determine the left and right boundaries of the range;

[0153] Step S202: Determine the data range corresponding to the verifier based on the left boundary and the right boundary of the range.

[0154] In a specific implementation, this section describes an example where an electronic cryptocurrency account A completes a transaction of 666 (evidence). The default daily transfer limit is known to be [0, 65535] (declaration, i.e., [0, 2...). 16 -1]. The three validators (m=3) are a regular account B, a fund manager account C, and a partner account D. Account A's trust in these three accounts increases sequentially. The stages of fNIZK are shown below:

[0155] The setup phase of NIZK consists of the following steps: Let group G be a group ordered by the 256-bit prime number p = 86961209857022906029575193214766894935632767170513461399082395413577572895499, and by the prime number...

[0156] q = 2p + 1 = 173922419714045812059150386429533789871265534341026922798164790827155145790999 is a multiplicative cyclic group modulo 1. It is a model

[0157] The integer ring of p = 86961209857022906029575193214766894935632767170513461399082395413577572895499. G n and In G and The above is an n-dimensional vector space, where n = 16, i.e., bit length. The two generators of the group G are:

[0158] g=51741104615612762588582578791120384452828536689305541874758746537136831137713

[0159] h=2411375069566833232073581129301397110393129857303343896167553316094723939907

[0160] Since this embodiment includes three verifiers with different identities—a regular account B, a fund manager account C, and a partner account D—we set the number of functions m = 3. Where f1 = [0, 2...]. 8 -1], k1=8; f2=[0,2],k1=8;f2=[0,2 4 -1],k2=4;f0=[0,2 16 -1], k0=16, which is the original default range. Given v0=666, randomly select a1=627, b1=a1+2 8 -1 = 882, such that v0 ∈ [a1, b1]; and randomly select a2 = 655, b2 = a2 + 2. 4 -1 = 670, such that v0 ∈ [a2, b2]. Therefore, we can obtain v1 = v0 - a1 = 39 and v2 = v0 - a2 = 11.

[0161] NIZK's two generator vectors g and h are respectively as follows: Figure 5 and Figure 6 As shown, generator

[0162] u=18861548404792030287269753433404212178827822445025042333976709905597501986023

[0163] The K Gen phase of NIZK is shown below:

[0164] 1. Generating private keys: Two private keys are randomly selected from the integer ring and assigned to fund account manager C and partner account D respectively.

[0165] sk1=44542829117413695091862045493246720130749901478545135412016576274373909659272

[0166] sk2=7185085863885292765675015823481397611595724061424995332593542128723026042772

[0167] The public key is generated by creating three public keys based on the private key, corresponding to the ordinary account B, the fund manager account C, and the partner account D, respectively.

[0168] pk0=14139447647121484256213310738265205471199002879468716695506424949834078403795

[0169] pk1=17215468459780859946598738343061871510195013581929149281065196274950394666129

[0170] pk2=156533478181413196605161738619161460108079903835862400887583474560695662962097

[0171] The Prove phase of NIZK is as follows: For each v i Let i ∈ [0, m], and randomly select an r. i Then according to Calculating Peterson's commitment yields...

[0172] V0=60610953554560641470508499760244143083261930287276501216982957913302860435207

[0173] V1=53562884920220213239535071485393030292552821600055300267170793888854800542062

[0174] V2=68274411126299830370636841514642407362230459631079362909994158520588049795837

[0175] Then for each v i For i∈[0,m], we obtain its binary vector form.

[0176]

[0177]

[0178]

[0179] Then, according to It can be obtained as follows Figure 7 As shown, for each i∈[0, m], in the integer ring α is randomly selected from (i) And calculate A (i) S (i) .according to We can obtain,

[0180] A (0) =37275650537020948970218388019130113974898367401272763280816492408352791897316

[0181] A (1) =132740374799581061929386912963099356347979988122546276495386144644127678920161

[0182] A (2) =8830604788147804026607480156860817776507673114469052797525875115851874440842

[0183] Where, α (0) α (1) α (2) exist Randomly selected from the list, its value is:

[0184] α (0) =49392481375731228281202530145660158828782519559306332456355333980422867237445

[0185] α (1) =85872807222204211429325171390571651378013298902178471240300623402627726462319

[0186] α (2) =1184215940376172389501614127811345314464476530367132112815306402610322210712

[0187] according to We can obtain,

[0188] S (0) =101436816873687020344601993326249484057356913810273077308520043802755826618431

[0189] S (1) =130651683905186044714186612731083494078582526164683586217373211392068132398437

[0190] S (2) =27079671605522309115542013827279187748191158307828433385898289107374956539582

[0191] Where, ρ (0) , ρ (1) , ρ (2) exist Randomly selected from the list, its value is:

[0192] ρ (0) =63949519060582864170816269067661066783327172318251726122100365239289156411713

[0193] ρ (1) =68988028514441810813316937728248974466712946555145389052490075100308017714264

[0194] ρ(2) =4440793280810400341406076785275170657924939970437971267895461845376049202525

[0195] Furthermore, S L S R Also there Randomly selected from the middle, its value is as follows Figure 8 and Figure 9 As shown, next, random numbers y and x, i.e., the public challenge, are obtained through a Fiat-Shamir inspired method. The specific process is shown in the following formula:

[0196] y = sha256(A (0) :S (0) A (1) :S (1) A (2) :S (2) )=54833546603091950326826576992832210969341103553811249242537414096187653537334

[0197] z = sha256(A (0) :S (0) A (1) :S (1) A (2) :S (2) :y)=83809904828342625216324175678505030256723838935140973783881369402314445697741

[0198] The values ​​of each element are concatenated together and hashed using SHA256 to obtain a public challenge.

[0199] The next step is to calculate the coefficient values.

[0200]

[0201]

[0202]

[0203]

[0204]

[0205] Then calculate We can obtain the following formula:

[0206]

[0207]

[0208]

[0209]

[0210]

[0211]

[0212] Then, a random number x is obtained using a Fiat-Shamir inspired method.

[0213]

[0214] The result obtained in the previous step The elements are concatenated together and hashed using SHA256 to obtain a common challenge. Next, the calculation... And send it to the verifier, calculate as follows Figure 10 As shown.

[0215] The NIZK verification process is as follows:

[0216] calculate Then, calculate P. (i) , i∈[0,m], and then the verification of equation (1.1) is performed. By calculating the left and right sides of the equation, it is found that, referring to the following formula, the left and right sides are equal, and this step of verification is passed.

[0217] left=163036108002663594316128990953015189883885745455303859064132380487025803543101

[0218] right=163036108002663594316128990953015189883885745455303859064132380487025803543101

[0219] The proof process of NIZK calling the Improved Inner-product Argument:

[0220] Next, run the Improved Inner-product Argument to verify it. (i) r (i) Is it correct that i∈[0,m]? Is this correct? First, the common input for the Improved Inner-product Argument is... For each i ∈ [0, m], the proof algorithm for the Improved Inner-product Argument is run. The prover first calculates new P, μ, and ... for subsequent operations.

[0221] When i = 0, set the bit_length of both the prover and the verifier to 16. The prover first calculates the following formula:

[0222] P (0) =150415614355045125103893864918916944474758312418890188937989672037941429362620,

[0223] u (0) =36022435773292531735592539350679012301741144481414993438025135071010724126254

[0224] After iteratively running the improved inner-product argument proof, the element to be transmitted can finally be obtained: L. (0) R (0)

[0225] When i=1, set the bit_length of both the prover and the verifier to 8. The prover first calculates the following formula:

[0226] P (1) =61306393506215007803139317885851916198982252776569670204018476466328234384331,

[0227] u (1) =20075588535032562657880879316977840671498485763212595427046182898332217699827

[0228] After iteratively running the improved inner-product argument proof, the element to be transmitted can finally be obtained: L. (1) R (1)

[0229] When i = 2, set the bit_length of both the prover and the verifier to 4. The prover first calculates the following formula:

[0230] P (2) =114253139505984354171519520702951944264015661071874438469694456710398736940169,

[0231] u (2) =89722360542869079118799682527895813297920431527439728927451851731372103169499

[0232] After iteratively running the improved inner-product argument proof, the element to be transmitted can finally be obtained: L. (2) R (2) ,

[0233] The verification process of NIZK calling the Improved Inner-product Argument:

[0234] Each validator receives the elements passed from the previous step and uses these elements and its own iterations to calculate...

[0235] When i = 0, the following can be calculated:

[0236]

[0237]

[0238] It can be known The left and right elements are equal, and the verification is successful when i = 0.

[0239] When i = 1, the following can be calculated:

[0240]

[0241]

[0242] It can be known The left and right elements are equal, and the verification is successful when i=1.

[0243] When i = 2, the following can be calculated:

[0244]

[0245]

[0246] It can be known The left and right elements are equal, and the verification is successful when i=2.

[0247] In summary, the successful verification of this step for each verifier, combined with fNIZK's successful verification of (1.1), leads us to conclude that fNIZK's entire verification process is complete. That is, account A's proof of a transaction of 666 (evidence) has been verified in ordinary account B, fund manager account C, and partner account D.

[0248] The Extract phase of NIZK is as follows:

[0249] After verification, fund manager account C and partner account D can further extract the range of the transaction amount (evidence) completed by account A based on their assigned private keys. Ordinary account B can only know the publicly available range of the amount, namely [0, 65535].

[0250] When i=1, fund manager account C uses its private key sk1 (as shown below) to perform range extraction. First, it calculates the left boundary of the range a1=627, and then obtains the right boundary b1=a1+2. 8 -1 = 882, so the transaction amount (evidence) falls within the range of [627, 882].

[0251] sk1=44542829117413695091862045493246720130749901478545135412016576274373909659272

[0252] When i=2, partner account D uses its private key sk2 (as shown below) to perform range extraction. First, it calculates the left boundary of the range a2=655, and then obtains the right boundary b2=a1+2. 4 -1 = 670, so the transaction amount (evidence) falls within the range of [655, 670].

[0253] sk2=7185085863885292765675015823481397611595724061424995332593542128723026042772

[0254] This embodiment extracts a range of the target proof information based on the verifier's private key, determines the left and right boundaries of the range, and determines the data range corresponding to the verifier based on the left and right boundaries of the range. This allows for the extraction of corresponding ranges for verifiers with different identities and permissions, providing a more accurate data range when the verifier has a high degree of relative trust, and ensuring data privacy when the verifier has a low degree of relative trust.

[0255] Furthermore, embodiments of the present invention also propose a storage medium storing a range proof program, which, when executed by a processor, implements the steps of the range proof method described above.

[0256] Since this storage medium adopts all the technical solutions of all the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0257] Reference Figure 5 , Figure 5 This is a structural block diagram of the first embodiment of the device for proving the scope of the present invention.

[0258] like Figure 5 As shown, the range verification device proposed in this embodiment of the invention includes:

[0259] Information acquisition module 10 is used to acquire target proof information;

[0260] The range extraction module 20 is used to extract the range of the target proof information based on the verifier's private key, and determine the data range corresponding to the verifier.

[0261] The range verification module 30 is used to provide the data range to the verifier so that the verifier can perform range verification.

[0262] Furthermore, the range extraction module 20 is also used to extract the range of the target proof information based on the verifier's private key, determine the left boundary and the right boundary of the range, and determine the data range corresponding to the verifier based on the left boundary and the right boundary of the range.

[0263] Furthermore, the range extraction module 20 is also used to send the target proof information to the verifier so that the verifier can perform verification based on the target proof information; when the verifier passes the verification, the step of performing range extraction on the target proof information based on the verifier's private key to determine the data range corresponding to the verifier is executed; when the verifier fails the verification, the proof ends.

[0264] Furthermore, the range extraction module 20 is also used to obtain the target protocol; and send the target protocol and the target proof information to the verifier, so that the verifier can verify the target protocol based on the target proof information.

[0265] Furthermore, the information acquisition module 10 is also used to acquire security parameters; acquire public parameters based on the security parameters; and process the public parameters to obtain target proof information.

[0266] Furthermore, the information acquisition module 10 is also used to acquire a public reference string and a function family based on the security parameters; and to acquire a public key and a private key based on the public reference string and the function family.

[0267] Furthermore, the information acquisition module 10 is also used to acquire evidence information; process the public parameters according to the evidence information to obtain candidate proof information; determine bit values ​​based on the candidate proof information and preset declaration information; and acquire target proof information according to the bit values ​​and the candidate proof information.

[0268] This embodiment obtains target proof information, extracts a range of the target proof information based on the verifier's private key, determines the data range corresponding to the verifier, and provides the data range to the verifier so that the verifier can perform range verification. Since this embodiment extracts a range of the target proof information based on the verifier's identity, it can extract different data ranges for the verifier to verify based on the verifier's identity. When the prover's trust in the verifier is high, the range that the verifier can extract is more accurate, which can better protect data privacy and effectively improve the level of risk management.

[0269] It should be understood that the above are merely illustrative examples and do not constitute any limitation on the technical solutions of the present invention. In specific applications, those skilled in the art can make settings as needed, and the present invention does not impose any restrictions on this.

[0270] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this invention. In practical applications, those skilled in the art can select some or all of the workflow to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.

[0271] In addition, for technical details not described in detail in this embodiment, please refer to the scope proof method provided in any embodiment of the present invention, which will not be repeated here.

[0272] Furthermore, it should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0273] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0274] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0275] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A range proof method, characterized in that, The range proof method includes: Obtain the target proof information; Based on the verifier's private key, a range is extracted from the target proof information to determine the data range corresponding to the verifier. The value to be proved for the target proof information is... , for The bit length; for each validator Define function Indicates a smaller interval ,in Determining the data range corresponding to the validator includes determining it based on the validator's private key. , making Falling Within the scope, and proved by the Bulletproofs protocol. The data range corresponding to the verifier is ,in, ; The data range is provided to the verifier so that the verifier can perform range verification.

2. The range proof method as described in claim 1, characterized in that, The step of extracting a range of the target proof information based on the verifier's private key to determine the data range corresponding to the verifier includes: Based on the verifier's private key, the target proof information is range-extracted to determine the left and right boundaries of the range. The data range corresponding to the verifier is determined based on the left boundary and the right boundary of the range.

3. The range proof method as described in claim 1, characterized in that, Before determining the data range corresponding to the verifier by performing range extraction on the target proof information based on the verifier's private key, the method further includes: The target proof information is sent to the verifier so that the verifier can verify based on the target proof information; When the verifier passes the verification, the step of extracting the target proof information based on the verifier's private key to determine the data range corresponding to the verifier is executed. The proof process ends when the verifier fails to verify the proof.

4. The range proof method as described in claim 3, characterized in that, Sending the target proof information to the verifier so that the verifier can perform verification based on the target proof information includes: Obtain the target protocol; The target protocol and the target proof information are sent to the verifier so that the verifier can verify the target protocol based on the target proof information.

5. The range proof method as described in claim 1, characterized in that, The acquisition of target proof information includes: Obtain security parameters; Obtain common parameters based on the security parameters; The common parameters are processed to obtain the target proof information.

6. The range proof method as described in claim 5, characterized in that, The public parameters include a public key and a private key. Obtaining the public parameters based on the security parameters includes: Based on the security parameters, obtain the public reference string and function family; Obtain the public key and private key based on the public reference string and the function family.

7. The range proof method as described in claim 6, characterized in that, The process of processing the public parameters to obtain the target proof information includes: Obtain evidence information; Based on the evidence information, the public parameters are processed to obtain candidate proof information; The bit value is determined based on the candidate proof information and the preset declaration information; The target proof information is obtained based on the bit value and the candidate proof information.

8. A range verification device, characterized in that, The range verification device includes: The information acquisition module is used to acquire target proof information; The range extraction module is used to extract a range from the target proof information based on the verifier's private key, determine the data range corresponding to the verifier, and the value to be proved corresponding to the target proof information is... , for The bit length; for each validator Define function Indicates a smaller interval ,in Determining the data range corresponding to the validator includes determining it based on the validator's private key. , making Falling Within the scope, and proved by the Bulletproofs protocol. The data range corresponding to the verifier is ,in, ; The range verification module is used to provide the data range to the verifier so that the verifier can perform range verification.

9. A range verification device, characterized in that, The range proof device includes: a memory, a processor, and a range proof program stored in the memory and executable on the processor, the range proof program being configured to implement the range proof method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a range proof program, which, when executed by a processor, implements the range proof method as described in any one of claims 1 to 7.

Images