Low-communication multi-index privacy-preserving password checking method

Abstract

The present invention discloses a low-communication, multi-index privacy-preserving password checking method, which includes the following steps: a user sends a public key and a relinear key to a service provider; the service provider splits a database into multiple blocks and encodes the multiple blocks into plaintext blocks; 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 blocks, 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 based on the integer vector, outputs whether the user's account has been leaked. The present invention can check whether the user's queried account has been leaked without revealing the user's queried account information.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, 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 using the same account to register for multiple different applications. With the help of leaked accounts on the dark web, attackers can attempt to log in to a legitimate user's account, which is also known as a credential stuffing attack. Therefore, the leakage of accounts in one application may also threaten the security of other applications and further expose users to financial losses and privacy leaks, such as fraudulent transactions, identity theft, and illegal fund transfers. 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 if 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 databases storing leaked accounts.

[0003] Currently deployed privacy-preserving password checking services reduce computational overhead by partitioning the database storing compromised accounts into multiple blocks. Specifically, the service provider uses a hash function to calculate the hash value of the username, selects the first 1 bits of the hash value as an identifier, and partitions the database into multiple blocks. If a user's account exists in the database storing compromised accounts, it will share the same block identifier with the database and can be found within that block. Therefore, simply executing the privacy-preserving password checking protocol between the user's account and the block can determine whether the user's account has been compromised.

[0004] However, some existing privacy-preserving password checking protocols implicitly trust service providers to honestly process account hashes. Because account hashes contain password information, this raises concerns among users about whether service providers can reliably maintain account privacy in the event of a compromise. Furthermore, some existing privacy-preserving password checking protocols offer 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 includes:

[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 includes:

[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 λ ) Generate private key sk, public key pk and relinear key rk, and send {pk, rk} to the service provider.

[0013] Furthermore, the step 2 includes:

[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: The service provider selects the first several bits from each of the αα hash values ​​and matches the selected hash values ​​with the hash values ​​output from step 21 after being expressed using the basis, thus splitting the database 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 includes:

[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 ∈ [n], h j : {0, 1} * → {0, 1} l , l ≥ (log n + λ), represent x using the base b as i where l b = l / log2 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 β bits of p i，j , β << l, the service provider establishes a match between and ; the service provider uses multiple indexes to split the database D = {(u0, v0), …, (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 α + 1 hash functions to obtain α + 1 hash values, and represents 1 of the multiple hash values using a base; then encodes the hash value represented by the base into a plaintext, and encrypts the plaintext into a ciphertext. The user selects the hash values obtained from the first several bits of the αα hash values respectively and sends the hash values 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 values obtained from the first several bits of 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.

[0026] ​Furthermore, the step 31 includes:

[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 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] Furthermore, the step 32 includes:

[0030] The service provider receives After that, use Search 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 response report To the user.

[0032] Furthermore, the step 4 includes:

[0033] User receives reply report After that, decrypt For a plaintext and decode <Y * > is an integer vector Y * If Y * There is 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-mentioned technical solution, the present invention has the following advantages: in response to the problems of password information leakage, high computational and communication costs existing in existing privacy-preserving password checking schemes, the present invention designs a low-communication multi-index privacy-preserving password checking scheme based on homomorphic encryption and hash functions. This scheme enables users to check whether their accounts appear in the database storing leaked accounts without disclosing their query account information. In addition, the scheme uses multiple different hash functions to generate multiple hash prefixes for user names (instead of user names and passwords), and divides the database storing leaked accounts into multiple small blocks, which can effectively reduce the number of time-consuming ciphertext calculations, reduce 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 following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments described 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 figure is a flowchart of a low-communication multi-index privacy-preserving password checking method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0037] The present invention will be further described with reference to the accompanying drawings and embodiments. The embodiments described are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by those skilled in the art 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, allowing simultaneous operation of multiple data, which greatly improves computational efficiency. Assuming 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 the 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, the first (w-1)·s data are packed and encoded into w-1 plaintext polynomials. Then, the remaining r data are padded with 0s and encoded 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 plaintext <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, this paper designs a low-communication multi-index privacy-preserving password checking scheme. This scheme consists of two phases: preprocessing and online phase, which are described in detail 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 (a power of 2), q is the ciphertext coefficient modulus, and t is the plaintext modulus. The user then enters the security parameter λ and calls HE.KeyGen(1 λ ) Generate private key sk, public key pk and 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 the matching between and . Finally, the service provider uses multiple indices 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:<e 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) The service provider receives After that, use Search 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 response report To the user.

[0056] (5) User receives reply report After that, decrypt For a plaintext and decode <Y * > is an integer vector Y * If Y * There is 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 and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the 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 by 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 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 ​​at 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; The step 3 comprises: Step 31: The user enters the account to be checked hash function, we get Hash values, and use the basis to represent one of the multiple hash values; then encode the hash value represented by the basis into a plaintext, and encrypt the plaintext into a ciphertext. The user will The hash value obtained by selecting the first several bits from the hash values ​​and the ciphertext are sent to the service provider as a request report; Step 32: After receiving the request report from the user, the service provider uses The hash value obtained by selecting the first several bits from the hash values ​​is searched in the database to obtain the plaintext block; the service provider obtains a response report based on the ciphertext in the request report and sends it to the user; The step 31 comprises: For accounts to be checked , users use Hash functions ,calculate Hash values: and , and select Before Bits as indexes ; Use base Will Re-expressed as , among which , , , , ; The user will Encoded as a plaintext , and Encrypted into a ciphertext ; User sends request report to service providers; The step 32 includes: The service provider receives After that, use Search the database to get the plaintext block ,in , ; The service provider randomly selects an integer vector ,coding For a plaintext , calling the homomorphic evaluation operation Calculation Evaluation Circuit , and return a response report To the user.

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 of the homomorphic encryption algorithm. and hash functions ; User input security parameters , call the key generation operation Generate a private key , public key and relinear key , and send To service providers.

3. The method according to claim 1, characterized in that The step 2 includes: Step 21: The service provider calculates for each compromised account Hash value, and use the basis to represent one of the multiple hash values; Step 22: Service providers After selecting the first several bits of the hash value, 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 includes: Service provider selection Hash functions , for each leaked account ,calculate hash values and ,in , , , using the base Will Expressed as ,in, , , ; and Represents the user name and password respectively, For the database The total amount of leaked accounts is stored.

5. The method according to claim 4, characterized in that The step 22 includes: yes Before Bit, , service providers establish and Matching between; service providers use multiple indexes The database Split into multiple blocks .

6. The method according to claim 5, characterized in that The step 23 includes: For each block , the service provider calls the encoding operation Encode it into a plaintext block ,in , .

7. The method according to claim 1, characterized in that The step 4 is specifically as follows: User receives reply report After that, decrypt , and decode is an integer vector ;if There are Consecutive 0s at position ,in, , then the output user's account has been leaked, otherwise the output user's account has not been leaked.

Images