Low-communication multi-index privacy protection password checking method

Abstract

The invention discloses a low-communication multi-index privacy protection password checking method. The method comprises the steps that a user sends a public key and a relinear key to a service provider; a service provider splits a database into a plurality of blocks, and encodes the plurality of blocks into plaintext blocks; the user sends a request report to a service provider; after receiving the request report, the service provider searches a database to obtain a plaintext block, randomly selects an integer vector, encodes the integer vector into a plaintext, and returns a reply report to the user; after receiving the reply report, the user decrypts the reply report into an integer vector; and outputting whether the account of the user is leaked or not according to the integer vector. According to the method and the device, whether the query account is leaked or not can be checked under the condition that the query account information of the user is not leaked.

Description

Technical Field

[0001] The present invention relates to the technical field of network security, and in particular to a low-communication multi-index privacy protection password checking method. Background Art

[0002] Due to hacker attacks, a large number of accounts are sold on the dark web every year. For convenience, many users are accustomed to registering multiple different applications with the same account. With the help of leaked accounts on the dark web, attackers can try to log in to a legitimate user's account, which is also known as a credential stuffing attack. Therefore, the leakage of an application's account may also threaten the security of other applications, and further make users vulnerable to financial losses and privacy leaks, such as fraudulent transactions, identity theft, illegal fund transfers, etc. The security of login accounts (usernames and passwords) has always been a matter of great concern to users, and users hope to receive timely notifications on whether their accounts have been leaked. To this end, some companies and institutions have begun to deploy privacy-preserving password checking services, allowing users to check whether their accounts appear in the database storing leaked accounts.

[0003] The currently deployed privacy-preserving password checking service reduces the computational cost by dividing the database storing the leaked account into multiple blocks. Specifically, the service provider uses a hash function to calculate the hash value of the username, selects the first l bits of the hash value as an identifier, and divides the database into multiple blocks. If a user's account exists in the database storing the leaked account, it will share the same block identifier with the database and its account can be found in the block. Therefore, it is only necessary to execute the privacy-preserving password checking protocol between the user account and the block to determine whether the user's account has been leaked.

[0004] However, some existing privacy-preserving password checking protocols implicitly trust the service provider to honestly process the account's hash value. Since the account's hash value contains password information, this raises concerns among users about whether the service provider can provide reliable account privacy when compromised. In addition, some existing privacy-preserving password checking protocols provide high security at the expense of long latency and high bandwidth. Summary of the invention

[0005] In view of this, the present invention provides a low-communication multi-index privacy protection password checking method.

[0006] The present invention discloses a low-communication multi-index privacy protection password checking method, which comprises:

[0007] Step 1: The user sends the public key and the re-linear key to the service provider;

[0008] Step 2: The service provider splits the database into multiple blocks and encodes the multiple blocks into plaintext blocks;

[0009] Step 3: The user sends a request report to the service provider. After receiving the request report, the service provider searches the database to obtain the plaintext block. The service provider randomly selects an integer vector, encodes the integer vector into a plaintext, and returns a reply report to the user.

[0010] Step 4: The user decrypts the received reply report into a plaintext, and decodes the plaintext into an integer vector. If there are multiple consecutive preset values ​​in the specified position of the integer vector, the output user's account has been leaked, otherwise the output user's account has not been leaked.

[0011] Furthermore, the step 1 comprises:

[0012] In the preprocessing phase, the user and the service provider first negotiate the parameters (n, q, t) of the homomorphic encryption algorithm and the hash function {h j : {0, 1} * →{0, 1} l |j∈[α+1]}; the user inputs the security parameter λ and calls HE.KeyGen(1 λ ) generates a private key sk, a public key pk and a relinear key rk, and sends {pk, rk} to the service provider.

[0013] Furthermore, the step 2 comprises:

[0014] Step 21: The service provider calculates α+1 hash values ​​for each leaked account, and uses the basis to represent one of the multiple hash values;

[0015] Step 22: After the service provider selects the first several bits from the αα hash values ​​respectively, the selected hash value is matched with the hash value outputted in step 21 after being represented by the basis, that is, the database is split into multiple blocks;

[0016] Step 23: The service provider encodes each of the plurality of blocks into a plaintext block.

[0017] Furthermore, the step 21 comprises:

[0018] The service provider selects α+1 hash functions h0,…,h α-1 ,h α , for each leaked account (u i , v i ), calculate α+1 hash values and x i =h α (u i ||vi ) = [x i，0 ,..., x i，l-1 , where \(i\in[n]\), \(h j :\{0, 1\} * \to\{0, 1\} l , \(l\geq(\log n+\lambda)\), represent \(x\) using base \(b\) as i represented as where, l b = l / \log_2 b, u i and \(v i respectively represent the username and password, and \(n\) is the total number of leaked accounts stored in the database \(D\).

[0019] Furthermore, step 22 includes:

[0020] is the first \(\beta\) bits of \(p i，j with \(\beta\ll l\), the service provider establishes a match between and ; the service provider uses multiple indexes to split the database \(D=\{(u_0, v_0),\ldots,(u n-1 , v n-1 )\}\) into multiple blocks

[0021] Furthermore, step 23 includes:

[0022] For each block the service provider calls the encoding operation HE.Encode to encode it into a plaintext block where

[0023] Furthermore, step 3 includes:

[0024] Step 31: The user inputs the account to be checked into \(\alpha + 1\) hash functions to obtain \(\alpha + 1\) hash values, and represents 1 of the multiple hash values using a base; then encodes the hash value represented using the base into a plaintext, and encrypts the plaintext into a ciphertext. The user selects the first several bits from \(\alpha\alpha\) hash values to obtain a hash value and sends the hash value and the ciphertext as a request report to the service provider;

[0025] Step 32: After receiving the request report sent by the user, the service provider uses the hash value obtained by selecting the first several bits from \(\alpha\alpha\) hash values to search the database to obtain a plaintext block; the service provider obtains a reply report based on the ciphertext in the request report and sends it to the user.

[0026] Furthermore, the step 31 comprises:

[0027] For the account to be checked (u * , v * ), the user uses α+1 hash functions h0,…,h α-1 ,h α , calculate α+1 hash values: and and select The first β bits of Using the basis b, we can re-express x* as Among them, {h j : {0, 1} * →{0, 1} l |j∈[α+1]}, l≥(log n+λ), l b =l / l0gb,

[0028] The user will Encoded as a plaintext and will Encrypted into a ciphertext User sends request report To service providers.

[0029] Further, the step 32 comprises:

[0030] The service provider receives After that, use Look up the database to get the plaintext block in

[0031] The service provider randomly selects an integer vector r = [r0, ..., r n-1 ], encoding r as a plaintext <r>=HE.Encode(r), calling the homomorphic evaluation operation HE.Eval rk Calculation Evaluation Circuit And return the reply report To the user.

[0032] Furthermore, the step 4 comprises:

[0033] User receives reply report After that, decrypt For a plain text And decode <Y * > is an integer vector Y * ; if Y * There are l b consecutive 0s at position v·l b ~(v+1)·l b , where v∈[n / l b ], then the output user's account has been leaked, otherwise the output user's account has not been leaked.

[0034] Due to the adoption of the above technical scheme, the present invention has the following advantages: in view of the problems of password information leakage, high computation and communication costs existing in the existing privacy protection password checking scheme, based on homomorphic encryption and hash functions, the present invention designs a low-communication multi-index privacy protection password checking scheme. The scheme enables users to check whether their accounts appear in the database storing the leaked accounts without disclosing their query account information. In addition, the scheme uses multiple different hash functions to generate multiple hash prefixes for the user name (rather than the user name and password), and divides the database storing the leaked account into multiple small blocks, which can effectively reduce the number of time-consuming ciphertext calculations, reduce the query latency, and provide better performance. At the same time, the hash prefix does not contain password information, which can better hide sensitive password information and provide higher security. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0036] Figure 1 The present invention is a flowchart of a low-communication multi-index privacy protection password checking method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0037] The present invention is further described in conjunction with the accompanying drawings and embodiments, and the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by ordinary technicians in this field should fall within the scope of protection of the embodiments of the present invention.

[0038] Homomorphic encryption (such as the BFV algorithm) can perform calculations directly without decrypting the ciphertext, and the calculation results on the ciphertext are consistent with the calculation results on the plaintext. In addition, it supports batch encoding of multiple data into a single plaintext, so that multiple data can be operated at the same time, which greatly improves the calculation efficiency. Assuming that the polynomial modulus is n, the ciphertext coefficient modulus is q, and the plaintext modulus is t, the main operations included in the homomorphic encryption algorithm are as follows:

[0039] (1) Key generation operation HE.KeyGen(1 λ ): Input security parameter λ and calculate the output public key pk, private key sk and relinear key rk.

[0040] (2) Encoding operation HE.Encode(x): Input an integer vector x = [x0, ..., x n-1 ], output a plaintext polynomial on a ring <x>In the encoding operation, if the length of the integer vector x' is s≤n, 0 is added to the end of x' to expand it into a vector x of length n, and then encoded into the plaintext polynomial <x>If s>n, let s=(w-1)·n+r, first pack the first (w-1)·s data into w-1 plaintext polynomials, then fill the remaining r data with 0 and encode them into a plaintext polynomial. Finally, w plaintext polynomials are obtained.

[0041] (3) Decoding operation HE.Encode(x): Input a plaintext polynomial on a ring <x>Decode and output an integer vector x = [x0, ..., x n-1 ].

[0042] (4) Encryption operation HE.Encpk((x>): Input public key pk and plaintext <x>, output ciphertext

[0043] (5) Decryption operation Enter the private key sk and ciphertext Output plain text <x>.

[0044] (6) Homomorphic evaluation operation Enter ciphertext And evaluation circuit f(y), output ciphertext

[0045] Based on the above homomorphic encryption, see Figure 1 The present invention provides an embodiment of a low-communication multi-index privacy protection password checking method, which includes a service provider having a database D = {(u0, v0), ..., (u n-1 , v n-1 )}, the user has an account (u * , v * ), and wants to check whether the account has been leaked, that is, appears in the database D owned by the service provider; where u i and v i Represents the user name and password respectively.

[0046] Assume that the service provider has a database D = {(u0, V0), ..., (u n-1 , v n-1 )}, where u i and v i Represents the user name and password respectively. A user has an account (u * , v * ), and want to check whether the account has been leaked. Based on homomorphic encryption and hash functions, the present invention designs a low-communication multi-index privacy-preserving password checking scheme. The scheme consists of two stages: preprocessing and online stage, which are described as follows:

[0047] 1. Preprocessing stage:

[0048] The user and the service provider negotiate the parameters (n, q, t) of the homomorphic encryption algorithm, where n is the polynomial modulus (power of 2), q is the ciphertext coefficient modulus, and t is the plaintext modulus. Then, the user enters the security parameter λ and calls HE.KeyGen(1 λ ) Generate a private key sk, a public key pk and a relinear key rk, store sk securely locally, and send {pk, rk} to the service provider.

[0049] (2) The service provider selects α+1 hash functions h0,…,h α-1 ,h α , for each leaked account (u i , v i ), calculate α+1 hash values and x i =h α (u i ||v i ) = [x i，0 ,..., x i，l-1 , where \(i\in[n]\), h j : \(\{0, 1\}\ * \to\{0, 1\}\ l , \(l\geq(\log n+\lambda)\) (usually in bytes). To achieve better efficiency, a larger base \(b\) (usually a power of 2) is used, and \(x\ i can be re - represented as where l b = l / \log_2b, Let be the first \(\beta\) bits of \(p\ i，j \) ( \(\beta\ll l\), usually in bytes), and the service provider establishes a match between and . Finally, the service provider uses multiple indexes to split the database \(D\) into multiple blocks

[0050] (3) For each block the service provider calls HE.Encode to encode it into a plaintext block where

[0051] 2. Online phase:

[0052] (1) For an account \((u^*, v^*)\) that wants to check if it has been leaked, the user uses \(\alpha + 1\) hash functions \(h_0,\ldots,h α-1 , h α \) to calculate \(\alpha + 1\) hash values: and and selects the first \(\beta\) bits of as the index To achieve better efficiency, a larger base \(b\) is used, and \(x^*\) can be re - represented as where \(\{h j : \(\{0, 1\}\ * \to\{0, 1\}\ l |j\in[\alpha + 1]\}, l\geq(\log n+\lambda)\), l b = l / \log b,

[0053] (2) The user encodes into a plaintext and encrypts into a ciphertext Then, the user sends a request report To service providers.

[0054] (3) Upon receiving After that, use Look up the database to get the plaintext block in

[0055] (4) The service provider randomly selects an integer vector r = [r0, ..., r n-1 ], encoding r as a plaintext <r>=HE.Encode(r), call HE.Evalrk to calculate the evaluation circuit And return the reply report To the user.

[0056] (5) User receives reply report After that, decrypt For a plain text And decode <Y * > is an integer vector Y * If Y * There are l b consecutive 0s at position v·l b ~(v+1)·l b , where v∈[n / l b ], then the output user's account has been leaked, otherwise the output user's account has not been leaked.

[0057] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.< / r> < / x> < / x> < / x> < / x> < / x> < / r>

Claims

1. A low-communication multi-index privacy-preserving password checking method, characterized in that: include: Step 1: The user sends the public key and the re-linear key to the service provider; Step 2: The service provider splits the database into multiple blocks and encodes the multiple blocks into plaintext blocks; Step 3: The user sends a request report to the service provider. After receiving the request report, the service provider searches the database to obtain the plaintext block. The service provider randomly selects an integer vector, encodes the integer vector into a plaintext, and returns a reply report to the user. Step 4: The user decrypts the received reply report into a plaintext, and decodes the plaintext into an integer vector. If there are multiple consecutive preset values ​​in the specified position of the integer vector, the output user's account has been leaked, otherwise the output user's account has not been leaked.

2. The method according to claim 1, characterized in that The step 1 comprises: In the preprocessing phase, the user and the service provider first negotiate the parameters (n, q, t) of the homomorphic encryption algorithm and the hash function {h j :{0,1} * →{0,1} l |j∈[α+1]}; the user inputs the security parameter λ and calls the key generation operation HE.KeyGen(1 λ ) generates a private key sk, a public key pk and a relinear key rk, and sends {pk,rk} to the service provider.

3. The method according to claim 1, characterized in that The step 2 comprises: Step 21: The service provider calculates α+1 hash values ​​for each leaked account, and uses the basis to represent one of the multiple hash values; Step 22: After the service provider selects the first several bits from the α hash values ​​respectively, the selected hash value is matched with the hash value outputted in step 21 after being represented by the basis, that is, the database is split into multiple blocks; Step 23: The service provider encodes each of the plurality of blocks into a plaintext block.

4. The method according to claim 3, characterized in that: The step 21 comprises: The service provider selects α+1 hash functions h0,…,h α-1 ,h α , for each leaked account (u i ,v i ), calculate α+1 hash values and x i =h α (u i ||v i )=[x i,0 ,…,x i,l-1 ], where i∈[n], h j :{0,1} * →{0,1} l , l≥(logn+λ), use the basis b to convert x i Expressed as in, l b = l / log2b, u i and v i represent user name and password respectively, and n is the total number of leaked accounts stored in database D.

5. The method according to claim 4, characterized in that The step 22 comprises: Yes i,j The first β bits, β<<l, the service provider establishes and service provider uses multiple indexes The database D = {(u0,v0),…,(u n-1 ,v n-1 )}Split into multiple blocks 6. The method according to claim 5, characterized in that The step 23 comprises: For each block The service provider calls the encoding operation HE.Encode to encode it into a plaintext block in 7. The method according to claim 1, characterized in that The step 3 comprises: Step 31: The user inputs the account to be checked into α+1 hash functions, obtains α+1 hash values, and uses a basis to represent one of the multiple hash values; then the hash value represented by the basis is encoded into a plain text, and the plain text is encrypted into a cipher text. The user selects the first several bits from the α hash values ​​to obtain the hash value and the cipher text as a request report and sends them to the service provider; Step 32: After receiving the request report sent by the user, the service provider uses the hash value obtained by selecting the first several bits from the α hash values ​​to search the database to obtain the plaintext block; the service provider obtains a reply report based on the ciphertext in the request report and sends it to the user.

8. The method according to claim 7, characterized in that The step 31 comprises: For the account to be checked (u * ,v * ), the user uses α+1 hash functions h0,…,h α-1 ,h α , calculate α+1 hash values: and and select The first β bits of Use the basis b to convert x * Re-expressed as Among them, {h j :{0,1} * →{0,1} l |j∈[α+1]}, l≥(logn+λ), l b = l / log b, The user will Encoded as a plaintext and will Encrypted into a ciphertext User sends request report To service providers.

9. The method according to claim 8, characterized in that The step 32 comprises: The service provider receives After that, use Look up the database to get the plaintext block in The service provider randomly selects an integer vector r = [r0,…,r n-1 ], encoding r as a plaintext <r>=HE.Encode(r), calling the homomorphic evaluation operation HE.Eval rk Calculation Evaluation Circuit And return the reply report To the user.< / r> 10. The method according to claim 9, characterized in that The step 4 is specifically as follows: User receives reply report After that, decrypt For a plain text And decode <Y * > is an integer vector Y * ; if Y * There are l b consecutive 0s at position v·l b ~(v+1)·l b , where v∈[n / l b ], then the output user's account has been leaked, otherwise the output user's account has not been leaked.

Images