A query method, electronic device and system

Abstract

A query method, electronic device and system are applied to the field of information security technology. The method includes: a first device sends a first query request to a second device, and the first query request includes a first ciphertext obtained by encrypting the first data using a first key. The second device sends a second ciphertext to the first device and a first ciphertext set corresponding to the incremental data of the data set in the second device, the second ciphertext is obtained by encrypting the first ciphertext using a second key, and the ciphertext in the first ciphertext set is obtained by encrypting the incremental data using the second key, and the incremental data refers to: data whose status in the data set is updated between time t1 and time t2; the status includes a deregistration status or a newly added status. The first device determines a first query result based on the second ciphertext, the first ciphertext set and the first key, and the first query result indicates whether the first data is included in the second device.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of information security technology, and in particular to a query method, electronic device and system. Background Art

[0002] When using electronic devices such as mobile phones and tablets, data is often queried from the cloud, servers or other devices. At the same time, the query process may involve the interaction of private information.

[0003] In the prior art, Private Set Intersection (PSI) can be used to protect privacy information during the query process.

[0004] However, in the existing PSI, the queried end (such as the cloud, server) needs to feedback a large amount of data to the query request end (such as mobile phones, tablets and other electronic devices), and the transmission of this data requires a large communication overhead, such as a lot of traffic. Summary of the invention

[0005] The present application provides a query method, electronic device and system, which can reduce the amount of data transmitted from the queried end to the query request end, thereby saving communication overhead.

[0006] In the first aspect, the present application provides a query method, which is applied to a first device such as a mobile phone, a tablet, and a laptop computer. The first device has a need to query data from other devices (such as a second device). Specifically, the first device sends a first query request to the second device, and the first query request includes a first ciphertext obtained by encrypting the first data using a first key. That is, the first device wants to query whether the data set of the second device includes the first data. The first device receives a second ciphertext from the second device and a first ciphertext set corresponding to the incremental data of the data set in the second device. The second ciphertext is obtained by encrypting the first ciphertext using a second key. The ciphertext in the first ciphertext set is obtained by encrypting the incremental data using the second key. The incremental data refers to: data in which the state of the data set is updated between time t1 and time t2; the state includes a deregistration state or a newly added state, time t2 is the current time, and time t1 is a time in the process of the first device querying whether the data set includes the first data before time t2. That is, time t1 is a time between the mobile phone 210 sending a query request to the cloud 220 in a certain historical query of the first data (such as the previous query) and the mobile phone 210 obtaining the query result of the historical query. For example, in a query immediately before the first query request (recorded as a previous query), the first device queries the first data, and time t1 may be a time when a query result is obtained for the previous query.

[0007] It should be understood that if the first device has queried the second device for the first data at time t1, it means that the first data is data that has been queried by the first device in the past. In other words, the aforementioned query method is aimed at the scenario where the first data that has been queried at time t1 is queried again at time t2. In this scenario, the second device will not return the ciphertext of all data in the data set of the second device, but will only return the ciphertext set consisting of the ciphertext of the data added or cancelled between time t1 and time t2 in the data set. This can reduce the amount of data returned by the second device to the first device, saving communication overhead.

[0008] Exemplarily, at time t1, the first device queries the second device whether the registered user's number includes number 1, and the first query request is used to query whether the registered user's number in the second device includes number 1. That is, number 1 is the first data, and the registered user's number is the data set in the second device. Then, for the first query request, the second device can only carry the ciphertext (i.e., the first ciphertext set) of the numbers cancelled or newly added (i.e., incremental data) among the registered user's numbers between time t1 and time t2 in the query response, without carrying the ciphertext of all registered user's numbers.

[0009] Then, the first device determines a first query result based on the second ciphertext, the first ciphertext set, and the first key, where the first query result indicates whether the second device includes the first data.

[0010] In summary, by using the present application, for queries on historically queried data, the second device can only return the first ciphertext set of incremental data, thereby reducing the amount of data transmission between the second device and the first device and saving communication overhead.

[0011] In a possible design, the first query request also includes the first hash feature of the first data. Incremental data refers to data whose state is updated between time t1 and time t2 and whose second hash feature is the same as the first hash feature.

[0012] It should be understood that if a certain data in the first data and the incremental data is the same, then the hash values ​​of the two must be the same, and the hash features are naturally the same. Then, through the hash feature, data that may be the same as the first data can be found. Therefore, in the data whose state is updated between time t1 and time t2 in the data set, data whose second hash feature is the same as the first hash feature is further found as incremental data, and the incremental data is data that may be the same as the first data.

[0013] That is to say, by adopting this design method, the second device does not send the ciphertext of all data whose status is updated in the data center between time t1 and time t2 to the first device, but sends a part of the data whose status is updated to the first device, thereby further reducing the data transmission volume and further saving communication overhead.

[0014] In another possible design, the first hash feature includes information about preset bits (i.e., part of the bits) in the hash value of the first data, and the second hash feature includes information about preset bits in the hash value of the data whose state is updated. For example, the preset bits are one or more bits from high to low in the hash value, such as 8, 12, 16 bits, etc. Among them, the one or more bits from high to low can also be called a hash prefix.

[0015] In another possible design, the first device determines the first query result based on the second ciphertext, the first ciphertext set, and the first key, including: the first device decrypts the second ciphertext using the first key to obtain a third ciphertext. The first device compares the third ciphertext with the first ciphertext set to obtain a first comparison result, and the first comparison result indicates whether the first ciphertext set includes the third ciphertext. The first device determines the first query result based on the first comparison result.

[0016] It should be understood that, under normal circumstances, the amount of the first data will not be large. However, the data set in the second device includes a lot of data, and the data in the data set also changes frequently, that is, the incremental data is large. In short, the amount of the first data is usually less than the amount of the incremental data. For example, if the first data is the contact numbers saved in the mobile phone's address book, and the data set is the numbers of registered users of a certain application, the contact numbers are usually only dozens or hundreds, while the registered users of the application are often many, generally reaching tens of thousands, hundreds of thousands or even more. The registered users are changing at any time, so the incremental data of the registered user numbers are generally more than the contact numbers.

[0017] Correspondingly, the number of second ciphertexts is less than the number of ciphertexts in the first ciphertext set. Under this premise, the amount of computation required to decrypt the second ciphertext is obviously smaller than the amount of computation required to encrypt the ciphertexts in the first ciphertext set. Therefore, in this design, the method of first decrypting the second ciphertext and then comparing it can reduce the amount of computation required by the first device.

[0018] In another possible design, the first device determines the first query result based on the first comparison result, including: if the first ciphertext set includes the ciphertext of the newly added data equal to the third ciphertext, it indicates that the first data is the same as the newly added data in the data set of the second device, such as the contact number is the same as the number of the newly registered user, and the first query result can be obtained to indicate that the second device includes the first data. If the first ciphertext set includes the ciphertext of the deregistered data equal to the third ciphertext, it indicates that the first data is the same as the deregistered data in the data set of the second device, such as the contact number is the same as the number of the deregistered registered user, and the first query result can be obtained to indicate that the second device does not include the first data. If the first ciphertext set does not include the ciphertext equal to the third ciphertext, it indicates that the incremental data does not include the first data. At the same time, if the first device queries the second device at time t1 and finds that the first data is not included, it indicates that the non-incremental data (that is, the data in the data set other than the incremental data) does not include the first data either, and the first query result can be obtained to indicate that the second device does not include the first data. If the first ciphertext set does not include the ciphertext equal to the third ciphertext, it indicates that the incremental data does not include the first data. At the same time, if the first device queries and finds that the second device includes the first data at time t1, it indicates that the non-incremental data includes the first data, and a first query result can be obtained indicating that the second device includes the first data.

[0019] In another possible design, before determining the first query result, the first device detects that the first data is not newly added between time t1 and time t2.

[0020] In practice, only for the first data that has been queried historically can the query result be obtained based on the ciphertext of the incremental data. For data that has not been queried historically, the query result can be obtained based on the ciphertext of the full amount of data (such as all the data in the data set, or data in the data set that may be the same as the unqueried data). Therefore, in this design method, the first device needs to determine that the first data is historically queried data, such as determining that the first data is not newly added between time t1 and time t2. In this way, the accuracy of the query result can be guaranteed.

[0021] Exemplarily, the first device records the newly added tags of each piece of data (such as each contact number) to indicate whether the data is newly added. The first device can detect whether the data is newly added by querying the newly added tags of the data.

[0022] In another possible design, the second query request and the first query request are two adjacent query requests, and the second query request is a query request for the first device to query whether the data set includes the first data at time t1.

[0023] In another possible design, after the first device queries whether the data set includes the first data at time t1, the first device records the query time, and the query time indicates time t1. The first query request also includes the query time, and the query time is used by the second device to determine the first ciphertext set.

[0024] After each query, the first device records the query time and carries it in the next query request, so that the second device can determine the time t1 and thus determine the first ciphertext set.

[0025] In another possible design, the second device may first encrypt the incremental data using the second key, and further compress the encrypted ciphertext using the first compression algorithm to obtain compressed ciphertext, that is, the ciphertext in the first ciphertext set is the compressed ciphertext obtained by compressing using the first compression algorithm. In this way, the first ciphertext set is all compressed ciphertext, which can further reduce the amount of data transmitted from the second device to the first device and save communication overhead.

[0026] Correspondingly, the first device can use the first key to decrypt the second ciphertext, and then compress it using the first compression algorithm to obtain the third ciphertext. In this way, the third ciphertext and the ciphertext in the first ciphertext set are both compressed ciphertexts encrypted using the second key and then compressed using the first compression algorithm, and the two are comparable.

[0027] In another possible design, the ciphertext in the first ciphertext set is a compressed ciphertext obtained by compressing using the first compression algorithm, or the ciphertext in the first ciphertext set is not a compressed ciphertext. That is, the ciphertext in the first ciphertext set may be a compressed ciphertext, or may not be a compressed ciphertext. Exemplarily, if it cannot be guaranteed that there is no collision between the compressed ciphertexts obtained after the ciphertexts of different incremental data are compressed (i.e., there is no identical compressed ciphertext), the ciphertext of the incremental data will not be compressed. Conversely, if it can be guaranteed that there is no collision between the compressed ciphertexts obtained after the ciphertexts of different incremental data are compressed, the ciphertext of the incremental data can be compressed. In this way, compression collisions can be avoided and the accuracy of the query results can be improved.

[0028] Accordingly, after receiving the query response, if the first device determines that the length of the ciphertext in the first ciphertext set is greater than the first length, it indicates that the ciphertext in the first ciphertext set is not a compressed ciphertext. In this case, the first device can obtain the third ciphertext by decrypting the second ciphertext using the first key without further compressing the decrypted result. If it is determined that the length of the ciphertext in the first ciphertext set is less than or equal to the first length, it indicates that the ciphertext in the first ciphertext set is a compressed ciphertext. In this case, the first device can decrypt the second ciphertext using the first key and then compress it using the first compression algorithm to obtain the third ciphertext. In this way, it can be ensured that the third ciphertext and the ciphertext in the first ciphertext set are both ciphertexts encrypted using the second key, or that the third ciphertext and the ciphertext in the first ciphertext set are both compressed ciphertexts encrypted using the second key and then compressed using the first compression algorithm, so that the third ciphertext and the ciphertext in the first ciphertext set are comparable.

[0029] In another possible design, the ciphertext in the first ciphertext set is a compressed ciphertext obtained by compressing using a first compression algorithm, or the ciphertext in the first ciphertext set is a compressed ciphertext obtained by compressing using a second compression algorithm. In other words, the ciphertext in the first ciphertext set may be a compressed ciphertext obtained by compressing using the first compression algorithm, or may be a compressed ciphertext obtained by compressing using the second compression algorithm. The second device adopts the first compression algorithm or the second compression algorithm to ensure that there is no collision of the ciphertext in the first ciphertext set. In this way, compression collision can be avoided and the accuracy of the query result can be improved.

[0030] Correspondingly, after receiving the query response, the first device can use the first key to decrypt the second ciphertext, and then compress it using the target compression algorithm that matches the length of the ciphertext in the first ciphertext set to obtain the third ciphertext. The length of the ciphertext in the first ciphertext set is the second length, and the second length is the length of the compressed ciphertext obtained by compression with the first compression algorithm. In this case, the target compression algorithm is the first compression algorithm. The length of the ciphertext in the first ciphertext set is the third length, and the third length is the length of the compressed ciphertext obtained by compression with the second compression algorithm. In this case, the target compression algorithm is the second compression algorithm. In this way, it can be ensured that the third ciphertext and the ciphertext in the first ciphertext set are both compressed ciphertexts encrypted using the second key and then compressed using the first compression algorithm, or are both compressed ciphertexts encrypted using the second key and then compressed using the second compression algorithm, so that the third ciphertext and the ciphertext in the first ciphertext set are comparable.

[0031] In another possible design, the ciphertext before compression includes multiple bits, and the ciphertext after compression includes information of some bits (such as the second bit) in the ciphertext before compression. Alternatively, the hash value of the ciphertext before compression includes multiple bits, and the ciphertext after compression includes information of some bits in the hash value of the ciphertext before compression. That is, the ciphertext before compression or the information of some bits in the hash value of the ciphertext before compression is taken as the compressed ciphertext.

[0032] In the second aspect, the present application provides a query method, which is applied to a second device such as a cloud device and a server that provides query services. Specifically, the second device receives a first query request from the first device, and the first query request includes a first ciphertext obtained by encrypting the first data using a first key. The second device sends a second ciphertext and a first ciphertext set corresponding to the incremental data of the data set in the second device to the first device, the second ciphertext is obtained by encrypting the first ciphertext using a second key, and the ciphertext in the first ciphertext set is obtained by encrypting the incremental data using the second key, and the incremental data refers to: data in which the status of the data set of the second device is updated between time t1 and time t2; the status includes a deregistration status or a newly added status, time t2 is the current time, and time t1 is a time in the process of the first device querying whether the data set includes the first data before time t2. For the principle and effect of the query method, please refer to the relevant description of the first aspect, which will not be repeated here.

[0033] In a possible design, the first query request also includes first characteristic information, and the first characteristic information is characteristic information of the ciphertext obtained by encrypting the first data using an irreversible first encryption algorithm. Incremental data refers to: data whose state is updated between time t1 and time t2, in which the second characteristic information matches the first characteristic information, and the second characteristic information is characteristic information of the ciphertext obtained by encrypting the data whose state is updated using the first encryption algorithm. For the principle and effect of the query method, please refer to the relevant description in the possible design of the first aspect, which will not be repeated here.

[0034] In another possible design, before the second device sends the second ciphertext and the first ciphertext set corresponding to the incremental data of the data set in the second device to the first device, the second device detects that the first query request is not the first query request of the first device to query the data set of the second device.

[0035] In practice, when querying for the first time, there is no historical query result to refer to, and the second device needs to return the ciphertext of the full amount of data (such as all the data in the data set, or the data in the data set that may be the same as the queried data) to the first device so that the first device can obtain the complete query result. Therefore, in this design, before returning the data, the second device needs to first determine that this query is not the first query. In this way, the correctness of the returned data can be guaranteed.

[0036] Exemplarily, if it is the first query, the first device may carry indication information indicating that no query has occurred in the query request, such as a time tag NA; if it is not the first query, the first device may carry indication information indicating that a query has occurred in the query request, such as the query time of the last query. In this way, the second device can detect whether it is the first query based on the indication information.

[0037] In another possible design, the first query request includes a query time, and the query time indicates that the first device has queried the data set of the second device at time t1. On the one hand, the query time can be used by the second device to determine that this is not the first query; on the other hand, the query time can be used by the second device to determine time t1, thereby determining the first ciphertext set.

[0038] In another possible design, before the second device sends the second ciphertext and the first ciphertext set corresponding to the incremental data of the data set in the second device to the first device, the second device detects that the first data is not new data in the first device between time t1 and time t2.

[0039] In practice, only for the first data that has been queried historically, can the second device return only the ciphertext of the incremental data to the first device. For data that has not been queried historically, the second device needs to return the ciphertext of the full amount of data (such as all the data in the data set, or data in the data set that may be the same as the unqueried data), so that the first device can obtain accurate query results. Therefore, in this design method, the first device needs to determine that the first data is historically queried data, such as determining that the first data is not newly added between time t1 and time t2. In this way, the accuracy of the query results can be guaranteed.

[0040] Exemplarily, the query request may carry a new tag indicating whether the queried data is new data, which is used to indicate whether the data is new. The second device can detect whether the data is new by using the new tag.

[0041] In another possible design, before the second device sends a query response to the first device, the second device may obtain a target processing parameter corresponding to the incremental data; the target processing parameter includes a second key and compression information; the compression information includes: indication information for indicating whether to compress the ciphertext encrypted using the second key, and the compression algorithm used when indicating to compress the ciphertext encrypted using the second key. In other words, the second device needs to obtain the target processing parameter before it can process and obtain the first ciphertext set. It should be noted that the target processing parameter needs to achieve the following effect: the first ciphertext set obtained using the target processing parameter does not include the same compressed ciphertext. That is, through the target processing parameter, compression collisions can be avoided and the accuracy of the query results can be improved.

[0042] Then, the second device processes the incremental data based on the target processing parameters to obtain the first ciphertext set. The second key is used by the second device to encrypt the incremental data. The indication information is used by the second device to determine whether it is necessary to further compress the incremental data after encrypting it with the second key. For example, if the indication information indicates that the ciphertext encrypted with the second key does not need to be compressed, the second device only needs to encrypt the incremental data with the second key to obtain the ciphertext in the first ciphertext set; if the indication information indicates that the ciphertext encrypted with the second key needs to be compressed, the second device needs to encrypt the incremental data with the second key and then compress it to obtain the ciphertext in the first ciphertext set. The compression algorithm is used by the second device to determine the compression algorithm used when further compressing the incremental data after encrypting it with the second key, such as the first compression algorithm or the second compression algorithm. For example, if the compression algorithm is the first compression algorithm, the second device uses the first compression algorithm to compress the ciphertext encrypted with the second key to obtain the ciphertext in the first ciphertext set. If the compression algorithm is the second compression algorithm, the second device uses the second compression algorithm to compress the ciphertext encrypted with the second key to obtain the ciphertext in the first ciphertext set. This ensures that there is no identical ciphertext in the first ciphertext set.

[0043] In another possible design, a large amount of experimental data of the same type as the data set in the second device can be used to conduct experiments, so that the first processing parameters that make the experimental ciphertext sets corresponding to each set of experimental data sets do not include the same ciphertext, such as obtaining compression information corresponding to different hash features, or obtaining compression information applicable to all hash features. Then, the second device can obtain the target processing parameters for processing the incremental data from the first processing parameters. For example, if the data set of the second device includes the numbers of registered users, the experimental data can be a large number of phone numbers, such as all domestic or global phone numbers.

[0044] Specifically, the experimental process is as follows: the second device groups multiple experimental data based on the hash features of the multiple experimental data to obtain multiple experimental data sets. Each experimental data set includes experimental data with the same hash features. The second device calculates the experimental ciphertext set corresponding to each experimental data set based on the initial processing parameters, and the experimental ciphertext set includes: the experimental data in the experimental data set is encrypted using a random key, and then compressed using a first compression algorithm to obtain a compressed ciphertext; the initial processing parameters include a random key and a first compression algorithm. The second device detects whether each experimental ciphertext set includes the same compressed ciphertext, and obtains the first processing parameter based on the detection result.

[0045] It should be understood that the use of the first processing parameters can ensure that each experimental ciphertext set does not include the same ciphertext. In practice, the incremental data is a subset of the experimental data, so the use of the target processing parameters in the first processing parameters can naturally ensure that the first ciphertext set does not store the same ciphertext.

[0046] Furthermore, in the first implementation, the second device detects whether each experimental ciphertext set includes the same compressed ciphertext, and obtains the first processing parameter based on the detection result, including:

[0047] Repeat the following process until the same compressed ciphertext is not included in each experimental ciphertext set to obtain the first processing parameter: detect whether each experimental ciphertext set includes the same compressed ciphertext. If there is at least one experimental ciphertext set that includes the same compressed ciphertext, the second device updates the random key in the initial processing parameter, and uses the updated initial processing parameter to recalculate the experimental ciphertext set corresponding to each experimental data set.

[0048] In other words, if the same ciphertext exists in any experimental ciphertext set, the random key is updated until the same ciphertext does not exist in any experimental ciphertext set after being processed with the updated random key and the first compression algorithm, and the first processing parameter includes the updated random key and the first compression algorithm. Thus, the first processing parameter is obtained so that the same ciphertext does not exist in any experimental ciphertext set.

[0049] It should be understood that if the initial processing parameters are used so that each experimental ciphertext set does not include the same compressed ciphertext, then the first processing parameters are the initial processing parameters, that is, the initial random key and the first compression algorithm.

[0050] In implementation mode 1, the first processing parameter can be applied to the processing of all data in the data set. That is, all numbers can be processed using the first processing parameter. Then, the second device obtains the target processing parameter corresponding to the incremental data from the detected first processing parameter, including: the second device determines the detected first processing parameter as the target processing parameter corresponding to the incremental data. In other words, the second key in the target processing parameter is the random key in the first processing parameter, and the compression algorithm in the target processing parameter is the first compression algorithm in the first processing parameter.

[0051] In the second implementation, the second device detects whether each experimental ciphertext set includes the same compressed ciphertext, and obtains the first processing parameter based on the detection result, including: if the first experimental ciphertext set among the multiple experimental ciphertext sets includes the same compressed ciphertext, then the second device updates the compression information in the initial processing parameter, and obtains the first processing parameter corresponding to the first hash feature, the first hash feature is the hash feature of the experimental data set corresponding to the first experimental ciphertext set, and the indication information in the updated compression information indicates that the ciphertext encrypted using the second key is not compressed. In other words, if the first experimental ciphertext set includes the same ciphertext, the indication information in the first processing parameter corresponding to the first hash feature indicates that the ciphertext encrypted using the second key is not compressed, and the second key is the initial random key.

[0052] The second experimental ciphertext set among the multiple experimental ciphertext sets does not include the same compressed ciphertext, and the second device uses the initial processing parameter as the first processing parameter corresponding to the second hash feature, and the second hash feature is the hash feature of the experimental data set corresponding to the second experimental ciphertext set. In other words, if the second experimental ciphertext set includes the same ciphertext, the first processing parameter corresponding to the second hash feature is the initial processing parameter, that is, the second key is the initial random key, and the compression algorithm is the first compression algorithm.

[0053] In implementation method three, the second device detects whether the same compressed ciphertext is included in each experimental ciphertext set, and obtains a first processing parameter based on the detection result, including: the first experimental ciphertext set among multiple experimental ciphertext sets includes the same compressed ciphertext, the second device updates the compression algorithm in the initial processing parameter, and obtains a first processing parameter corresponding to a first hash feature, the first hash feature is a hash feature of an experimental data set corresponding to the first experimental ciphertext set, and the length of the ciphertext compressed by the updated compression algorithm is greater than the length of the ciphertext compressed by the compression algorithm before the update. It should be understood that the longer the ciphertext compressed by the compression algorithm is, the lower the possibility of a collision. In other words, if the first experimental ciphertext set includes the same ciphertext, the first processing parameter corresponding to the first hash feature is obtained, the compression algorithm is the updated compression algorithm (also referred to as the second compression algorithm), and the second key is the initial random key.

[0054] The second experimental ciphertext set among the multiple experimental ciphertext sets does not include the same compressed ciphertext, and the second device uses the initial processing parameter as the first processing parameter corresponding to the second hash feature, and the second hash feature is the hash feature of the experimental data set corresponding to the second experimental ciphertext set. In other words, if the second experimental ciphertext set includes the same ciphertext, the first processing parameter corresponding to the second hash feature is the initial processing parameter, that is, the second key is the initial random key, and the compression algorithm is the first compression algorithm.

[0055] In the above-mentioned implementation method 2 and implementation method 3, the second device obtains the target processing parameter corresponding to the incremental data from the first processing parameter obtained by detection, including: the second device obtains the first processing parameter corresponding to the hash feature that is the same as the hash feature of the incremental data (that is, the feature information is the hash feature) from the first processing parameter obtained by detection as the target processing parameter corresponding to the incremental data.

[0056] Exemplarily, using implementation method 2, if the hash feature of the incremental data is the same as the first hash feature, the indication information in the target processing parameter indicates that the ciphertext encrypted using the second key is not compressed, and the second key is the initial random key. If the hash feature of the incremental data is the same as the second hash feature, the compression algorithm in the target processing parameter is the first compression algorithm, and the second key is the initial random key. This ensures that there is no identical ciphertext in the first ciphertext set processed using the target processing parameter.

[0057] Another exemplary implementation is to use implementation method 3. If the hash feature of the incremental data is the same as the first hash feature, the compression algorithm in the target processing parameter is the second compression algorithm, and the second key is the initial random key. If the hash feature of the incremental data is the same as the second hash feature, the compression algorithm in the target processing parameter is the first compression algorithm, and the second key is the initial random key. This ensures that there is no identical ciphertext in the first ciphertext set processed using the target processing parameter.

[0058] In a third aspect, the present application provides a query method, which is applied to a first device and a second device. Specifically, the first device sends a first query request to the second device, and the first query request includes a first ciphertext obtained by encrypting the first data using a first key. In response to the first query request, the second device sends a second ciphertext and a first ciphertext set corresponding to the incremental data of the data set in the second device to the first device, the second ciphertext is obtained by encrypting the first ciphertext using the second key, and the ciphertext in the first ciphertext set is obtained by encrypting the incremental data using the second key, and the incremental data refers to: data in which the state of the data set is updated between time t1 and time t2; the state includes a deregistration state or a newly added state, time t2 is the current time, and time t1 is a time in the process of the first device querying whether the data set includes the first data before time t2. In response to the second ciphertext and the first ciphertext set, the first device determines a first query result based on the second ciphertext, the first ciphertext set and the first key, and the first query result indicates whether the second device includes the first data. For the principle and effect of the query method, please refer to the relevant description of the first aspect, which will not be repeated here.

[0059] In a fourth aspect, the present application further provides an electronic device, comprising a memory and one or more processors. The memory is coupled to the processor. The memory is used to store computer program code, and the computer program code includes computer instructions. Wherein, the electronic device is a first device, and when the computer instructions are executed by the processor, the electronic device executes the steps executed by the first device in the first aspect, the second aspect, the third aspect, and any possible design thereof; or, the electronic device is a second device, and when the computer instructions are executed by the processor, the electronic device executes the steps executed by the second device in the first aspect, the second aspect, the third aspect, and any possible design thereof.

[0060] In a fifth aspect, the present application also provides a communication system, comprising a first device and a second device as in the first aspect, the second aspect, the third aspect and any possible design thereof.

[0061] In a sixth aspect, an embodiment of the present application provides a chip system, which is applied to an electronic device including a display screen and a memory; the chip system includes one or more interface circuits and one or more processors; the interface circuit and the processor are interconnected through a line; the interface circuit is used to receive a signal from the memory of the electronic device and send the signal to the processor, and the signal includes a computer instruction stored in the memory. Wherein, the electronic device is a first device, and when the processor executes the computer instruction, the electronic device executes the steps executed by the first device in the first aspect, the second aspect, the third aspect, and any possible design thereof. Alternatively, the electronic device is a second device, and when the processor executes the computer instruction, the electronic device executes the steps executed by the second device in the first aspect, the second aspect, the third aspect, and any possible design thereof.

[0062] In a seventh aspect, the present application provides a computer storage medium, which includes computer instructions. Wherein, when the computer instructions are executed on a first device, the first device is caused to execute the steps executed by the first device in the first aspect, the second aspect, the third aspect, and any possible design thereof. Alternatively, when the computer instructions are executed on a second device, the second device is caused to execute the steps executed by the second device in the first aspect, the second aspect, the third aspect, and any possible design thereof.

[0063] In an eighth aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method described in the first aspect and any possible design thereof.

[0064] It can be understood that the beneficial effects that can be achieved by the above-mentioned electronic device, communication system, chip system, computer storage medium, and computer program product can refer to the beneficial effects in the first aspect, the second aspect, the third aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 A schematic diagram of a PSI provided in an embodiment of the present application;

[0066] Figure 2 A diagram of a communication system provided in an embodiment of the present application;

[0067] Figure 3 A schematic diagram of scenario 1 to which the embodiment of the present application is applicable;

[0068] Figure 4A A schematic diagram of scenario 2 to which the embodiment of the present application is applicable;

[0069] Figure 4B A schematic diagram of scenario 3 to which the embodiment of the present application is applicable;

[0070] Figure 5A One of the flowcharts of the query method;

[0071] Figure 5B This is the second flowchart of the query method;

[0072] Figure 5C This is the third flowchart of the query method;

[0073] Figure 6 An example diagram of a query method provided in an embodiment of the present application;

[0074] Figure 7 A hardware structure diagram of an electronic device provided in an embodiment of the present application;

[0075] Figure 8 One of the phase structure diagrams of the query method provided in the embodiment of the present application;

[0076] Fig. 9 One of the flowcharts of stage 1 in the query method provided in the embodiment of the present application;

[0077] Fig.10 A flowchart of stage 2 of the query method provided in an embodiment of the present application;

[0078] Fig.11 One of the flowcharts of stage 3 in the query method provided in the embodiment of the present application;

[0079] Fig.12 One of the principle diagrams of the query method provided in the embodiment of the present application;

[0080] Fig.13 One of the flowcharts of stage 4 in the query method provided in the embodiment of the present application;

[0081] Fig.14 The second flowchart of stage 3 of the query method provided in the embodiment of the present application;

[0082] Fig.15 The second flowchart of stage 4 in the query method provided in the embodiment of the present application;

[0083] Fig.16 Flowchart 2 of Phase 1 of the query method provided in the embodiment of the present application

[0084] Fig.17 This is a flowchart of the first query in the query method provided in the embodiment of the present application;

[0085] Fig.18This is a flowchart for a non-first query in the query method provided in an embodiment of the present application;

[0086] Fig.19 One of the flowcharts of the query method provided in the embodiment of the present application;

[0087] Fig. 20 The second flowchart of the query method provided in the embodiment of the present application;

[0088] Fig.21 The second schematic diagram of the query method provided in the embodiment of the present application;

[0089] Fig. 22 The second diagram of the phase structure of the query method provided in the embodiment of the present application;

[0090] Fig.23A One of the flowcharts of stage 0 in the query method provided in an embodiment of the present application;

[0091] Fig. 23B The second flowchart of phase 0 in the query method provided in the embodiment of the present application;

[0092] Fig.23C The third flowchart of stage 0 in the query method provided in the embodiment of the present application;

[0093] Fig.24 A structural diagram of the chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0094] The technical solutions in the embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the embodiments of the present application, the terms used in the following embodiments are only for the purpose of describing specific embodiments, and are not intended to be used as limitations on the present application. As used in the specification and the appended claims of the present application, the singular expressions "a", "said", "above", "the" and "this" are intended to also include expressions such as "one or more", unless there is a clear indication to the contrary in the context. It should also be understood that in the following embodiments of the present application, "at least one", "one or more" refer to one or more (including two). The term "and / or" is used to describe the association relationship of associated objects, indicating that three relationships can exist; for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in a "or" relationship.

[0095] References to "one embodiment" or "some embodiments" etc. described in this specification mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Thus, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways. The term "connection" includes direct connection and indirect connection, unless otherwise specified. "First" and "second" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated.

[0096] In the embodiments of the present application, the words "exemplarily" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplarily" or "for example" is intended to present related concepts in a specific way.

[0097] Before describing the embodiments of the present application, a brief introduction to the technical terms involved in the present application is given:

[0098] 1. Private Set Intersection (PSI).

[0099] PSI is a secure multi-party computing (SMPC) technology. With PSI, the intersection of data held by both parties can be obtained without leaking data other than the intersection of data held by both parties, thus achieving privacy protection.

[0100] For example, see Figure 1 , the mobile phone has a private data set A, and the cloud has a private data set B. The mobile phone needs to query the intersection A∩B of private data sets A and B. However, the mobile phone does not want to disclose its private data set A to the cloud, and the cloud does not want to disclose the data in its private data set B other than A∩B to the mobile phone. For this scenario, the mobile phone and the cloud can use PSI so that the mobile phone only obtains A∩B, but does not obtain the data in the private data set B other than A∩B, and the cloud does not obtain the private data set A.

[0101] In the embodiment of the present application, PSI is used to prevent the disclosure of data other than the intersection of the data held by both parties during the query process, thereby achieving privacy protection.

[0102] 2. PSI encryption algorithm.

[0103] The PSI encryption algorithm refers to an algorithm that supports data encryption in a scheme using PSI. Exemplarily, the PSI encryption algorithm includes the Diffie-Hellman (DH) algorithm, the Elliptic Curve Diffie-Hellman (ECDH / ECC) algorithm, the Leonard Adleman-Ron Rivest-Adi Shamir (RSA) blind signature algorithm, the Oblivious Transfer (OT) algorithm, etc. In this article, the DH algorithm and the ECDH algorithm are mainly used to illustrate the present application scheme.

[0104] Among them, the DH protocol and the ECDH protocol are both interchangeable encryption protocols. Interchangeable encryption algorithms are algorithms whose encryption and decryption order can be swapped.

[0105] For example, a commutative encryption algorithm is used to encrypt data x using key a to obtain ciphertext x a , use key b to ciphertext x a Further encryption to obtain the ciphertext x ab Using the exchangeable encryption algorithm, use the key b to encrypt the data y and get the ciphertext y b , use key a to ciphertext y b Further encryption to obtain the ciphertext y ba If data x and data y are equal, then the above ciphertext x ab With the ciphertext x ba That is, for the same data, if an interchangeable encryption algorithm is used, the same ciphertext can be obtained by exchanging the encryption order (referred to as Principle 1). In PSI, this Principle 1 can be used to achieve privacy protection.

[0106] Furthermore, for the above ciphertext x ab , first use key a to decrypt and get the ciphertext x b , if data x and data y are equal, then the ciphertext x b is equal to the ciphertext obtained by encrypting data y using key b, that is, ciphertext y b Then, for data x, after double encryption using the commutative encryption algorithm (that is, first encrypt with key a, then encrypt with key b), and then decrypt with key a, we can get the ciphertext x obtained by encrypting data x with key b. b , if the ciphertext x b The ciphertext y obtained by encrypting data y with key bb If they are equal, it can be determined that data x and data y are equal (referred to as Principle 2). In PSI, Principle 2 can also be used to implement privacy protection to reduce query latency.

[0107] It should be noted that, unless otherwise stated below, encryption / decryption in PSI is implemented using an interchangeable encryption algorithm.

[0108] See also Figure 2 , is a communication system applicable to PSI, the communication system may include a first device (such as Figure 2 The mobile phone 210 shown in FIG. 2 and the second device (such as Figure 2 The first device is a device having a query requirement, and the second device is a device providing a query service.

[0109] The first device and the second device are connected in communication for transmitting data in the query process. For example, the first device sends a query request to the second device, and the second device returns a query response to the first device. Exemplarily, a wired connection can be established between the first device and the second device using a universal serial bus (USB). Alternatively, a wireless connection can be established between the first device and the second device through a global system for mobile communications (GSM), a general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), Bluetooth, wireless fidelity (Wi-Fi), NFC, voice over Internet protocol (VoIP), and a communication protocol that supports a network slicing architecture.

[0110] The first device may be a mobile phone, tablet computer, desktop, laptop, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, cellular phone, personal digital assistant (PDA), augmented reality (AR)\virtual reality (VR) device and other devices with query needs. The second device may be a cloud (which may be understood as a cloud device, cloud server), a server (which may be understood as a traditional server), a personal computer (PC) and other devices that can provide query services. The embodiments of the present application do not impose any special restrictions on the specific forms of the first device and the second device.

[0111] Exemplarily, the first device may be any end of a business to consumer (B2C) mode, a consumer to consumer (C2C) mode, or a business to business (B2B) mode, and the second device may be the other end of a B2C mode, a C2C mode, or a B2B mode. It should be understood that, compared with a B-end device, a C-end device is more sensitive to communication overhead. Therefore, if the first device is a C-end device in the B2C mode or the C2C mode, the query method provided in the embodiment of the present application can significantly save the communication overhead of the first device.

[0112] Hereinafter, the first device is Figure 2 As shown in the mobile phone 210, the second device is Figure 2 Cloud 220 is shown as an example.

[0113] The following are some typical scenarios of PSI:

[0114] Scenario 1: Friend discovery scenario. That is, discovering whether the contacts in the address book have registered accounts in the social application.

[0115] When the mobile phone 210 installs and runs the social application A for the first time, it can display Figure 3Interface 301 is shown. Interface 301 includes a prompt text "Do you allow to find contacts in the address book?" to prompt the user to find out whether the contacts in the address book have accounts registered in the social application. In addition, interface 301 also includes two options "Yes" and "No". In response to the user's selection of the "Yes" option in interface 301, mobile phone 210 can send a query request to find contacts in the address book to cloud 220 to query whether each contact in the address book has an account registered in social application A. After the query is completed, mobile phone 210 can display Figure 3 Interface 302 is shown. Interface 302 includes contacts who have registered accounts in social application A, such as Tom, Alice, etc. Of course, interface 302 may also include information such as accounts of these contacts in social application A (such as I love eating fish, Happy every day, etc.), avatars, etc.

[0116] In the process of running social application A for a non-first time, in response to an operation of discovering address book friends (such as the user clicking a button for discovering address book friends in the settings of social application A), mobile phone 210 may also send a query request for discovering address book friends to cloud 220, and display the query results after obtaining them, which will not be elaborated here.

[0117] In the above scenario 1, the query request sent by the mobile phone 210 to the cloud 220 usually needs to carry the contact number included in the address book. In this way, the cloud 220 can find out whether each contact in the address book has an account registered in the social application A by comparing the contact number with the number of the registered user recorded in the cloud 220 (referred to as the registration number). For example, the address book includes the contact number "12345678910", and the registration number recorded in the cloud 220 also includes "12345678910". The cloud 220 can determine that the contact number "12345678910" has an account registered in the social application A. However, the contact number included in the address book of the mobile phone 210 is private information. If the mobile phone 210 sends it directly to the cloud 220, there will be a risk of privacy leakage.

[0118] In scenario 1, the private information in the mobile phone 210 is the contact number, and the private information in the cloud 220 is the registration number. In scenario 1, using PSI, while realizing friend discovery, the contact number can be prevented from being leaked to the cloud 220. In addition, the registration number in the cloud 220 other than the intersection of the contact number and the registration number can also be prevented from being leaked to the mobile phone 210.

[0119] Scenario 2: Anti-fraud cloud check scenario. That is, check whether the unfamiliar call is a phone number with security risks (referred to as risk number).

[0120] After receiving an unknown call, the mobile phone 210 can send a risk number query request to the cloud 220 to check whether the unknown call is a risk number. After finding that the unknown call is a risk number, the mobile phone 210 can display Figure 4A The interface 401 of the call in progress is shown. The interface 401 includes a prompt text "fraud call" to prompt that the unfamiliar call is a risky number.

[0121] In the above scenario 2, the query request sent by the mobile phone 210 to the cloud 220 usually needs to carry the caller number of the unfamiliar call. In this way, the cloud 220 can find out whether the caller number of the unfamiliar call is a risky number by comparing the caller number with the risk number recorded in the anti-fraud number library of the cloud 220. For example, the caller number of the unfamiliar call is "10987654321", and the number "10987654321" is also recorded in the anti-fraud number library of the cloud 220, and the cloud 220 can determine that the caller number is a risky number. However, the caller number received by the mobile phone 210 is private information, and the mobile phone 210 sends it directly to the cloud 220, which will cause the risk of privacy leakage.

[0122] In scenario 2, the private information in the mobile phone 210 is the incoming call number, and the private information in the cloud 220 is the risk number in the anti-fraud number library. In scenario 2, PSI is used to prevent the incoming call number from being leaked to the cloud 220 while implementing anti-fraud. In addition, the risk number in the cloud 220 other than the intersection of the incoming call number and the anti-fraud number library can also be prevented from being leaked to the mobile phone 210.

[0123] Scenario 3: Leaked password check scenario. That is, check whether the password is leaked.

[0124] After detecting the password check event, the mobile phone 210 may send a query request for leaked passwords to the cloud 220 to check whether the password in the mobile phone 210 has been leaked. For example, the mobile phone may display Figure 4BInterface 402 is shown. Interface 402 is a password setting interface, which is used to manage passwords in mobile phone 210. Interface 402 includes setting item 403 for leaked password check. For example, setting item 403 includes the text "Check for leaked passwords" to indicate that setting item 403 is used to check for leaked passwords; and setting item 403 also includes the text "Your password can be monitored safely and you will be reminded when the password is leaked" to introduce the function of leaked password check. In addition, setting item 403 also includes button 4031, which is in the off state. The password check event may be a user clicking operation on button 4031. In response to the user clicking operation on button 4031, the function of leaked password check may be turned on. After turning on the check, mobile phone 210 may send a query request for leaked passwords to cloud 220. Alternatively, after the leaked password check function is turned on, mobile phone 210 may periodically send a query request for leaked passwords to cloud 220. After the query is completed, mobile phone 210 may display Figure 4B The interface 404 shown still includes the setting item 403, but the button 4031 in the setting item 403 is turned on, indicating that the function of checking for leaked passwords is turned on. In addition, the interface 405 includes a prompt message that the password of application 1 has been leaked, which is used to prompt that the password of application 1 has been leaked, and there is a security risk.

[0125] In scenario 3, the private information in the mobile phone 210 is the password for application or unlocking, and the private information in the cloud 220 is the password collected from various channels. In scenario 3, PSI is used to prevent the password in the mobile phone 210 from being leaked to the cloud 220 while realizing the leaked password query. In addition, the password in the cloud 220 other than the intersection of the password in the mobile phone 210 and the password in the cloud 220 can also be prevented from being leaked to the mobile phone 210.

[0126] The above scenarios 1 to 3 are all binary query scenarios, that is, query scenarios that obtain a yes (YES) or no (NO) result through query. For example, whether the contact is registered in social application A, whether the incoming call number is a risky number, and whether the secret has been leaked.

[0127] In practice, PSI can also be used in other query scenarios involving privacy information. For example, after the above scenario 1 finds that the contact number "12345678910" has an account registered in social application A, the mobile phone 210 can continue to query the cloud 220 for the service functions activated by the registered user corresponding to the contact number "12345678910" in social application A, such as video calls, voice calls, text messages, etc. Obviously, the activated service function is not a simple yes or no result, so it is not a binary query. In this scenario, the use of PSI can prevent the contact number "12345678910" in the mobile phone 210 from being leaked to the cloud 220, and prevent numbers other than "12345678910" in the cloud 220 from being leaked to the mobile phone 210.

[0128] In the following, the process of implementing privacy protection using PSI will be mainly described in combination with the above-mentioned scenarios 1 and 2. In scenarios 1 and 2, the private information is all phone numbers. In addition, for the sake of distinction, the private information in the mobile phone 210 is recorded as private information x, and the private information x includes x1, x2...xm, where m is the number of private information in the mobile phone 210. And, the private information in the cloud 220 is recorded as private information y, and the private information y includes y1, y2...yn, where n is the number of private information in the cloud 220. Usually, n is much larger than m. For example, the risk numbers or registered numbers included in the cloud 220 may be hundreds of thousands, so n may be in the hundreds of thousands; and the current incoming call number in the mobile phone 210 is usually only one, that is, m=1, or the contact numbers in the mobile phone 210 are usually only dozens or hundreds, so m is also dozens or hundreds, which is obviously much smaller than n.

[0129] See also Figure 5A ,For the above privacy query scenario, the process of using PSI to achieve privacy protection includes:

[0130] S501, cloud 220 uses key b to encrypt n pieces of private information y to obtain data set Hn(y) b , n is a positive integer.

[0131] For example, the n risk numbers are y1, y2, y3...yn. After encryption with key b, the ciphertext y1 can be obtained in sequence. b ,y2 b ,y3 b ……yn b .y1 b ,y2 b ,y3 b ……yn b Construct the above data set Hn(y) b .

[0132] S502: In response to the query event, the mobile phone 210 uses the key a to encrypt m pieces of private information x to obtain a data set Hm(x) a , m is a positive integer.

[0133] The query event is used to trigger the mobile phone 210 to perform a binary query on the cloud 220. For example, the query event can be a user's Figure 3 Alternatively, the query event may be an event in which the mobile phone 210 receives an unknown call. Alternatively, the query event may be a user's Figure 4B The click operation of button 4031 in the interface 402 is shown.

[0134] For example, the incoming call number is x1, and after encryption with key a, the ciphertext x1 can be obtained a .x1 a Construct the above data set Hm(x) a It should be understood that if m is larger, the data set Hm(x) a There will be more ciphertext included.

[0135] S503, the mobile phone 210 sends a query request to the cloud 220, the query request includes the data set Hm(x) a .

[0136] The mobile phone 210 does not send the plain text of the private information x to the cloud 220, but only sends the ciphertext of the private information x encrypted once to avoid privacy leakage.

[0137] Exemplarily, the mobile phone 210 sends a query request for risky numbers to the cloud 220 , and the query request carries a ciphertext of the incoming call number.

[0138] S504: In response to the query request, the cloud 220 uses the key b to perform a query on the data set Hm(x). a The ciphertext in is encrypted twice to obtain the data set Hm(x) ab .

[0139] For example, cloud 220 performs the following operations on the dataset Hm(x): a The ciphertext x1 in a Using key b for secondary encryption, we can get the ciphertext x1 ab .x1 ab Construct the above data set Hm(x) ab .

[0140] S505, the cloud 220 sends the data set Hm(x) to the mobile phone 210 ab And the data set Hn(y) b .

[0141] That is, cloud 220 will further encrypt the ciphertext of private information x and return it to mobile phone 210, and will not obtain the plaintext of private information x. In addition, cloud 220 will not send the plaintext of private information y to mobile phone 210, but only send the ciphertext of private information y once encrypted to avoid privacy leakage.

[0142] At this point, it should be noted that there is no strict execution order between the above S501 and S502-S504. In practice, it is sufficient as long as S501 is completed before S505.

[0143] S506, the mobile phone 210 is based on the data set Hn(y) b And the dataset Hm(x) ab Included content, complete data comparison, and obtain comparison results.

[0144] In a specific implementation, see Figure 5B , the above S506 further includes:

[0145] S5061a, mobile phone 210 can use key a to perform the data set Hn(y) b The ciphertexts in are encrypted twice to obtain the data set Hn(y) ba .

[0146] For example, the mobile phone 210 performs the following operations on the data set Hn(y): b The ciphertext y1 in b ,y2 b ,y3 b ……yn b Using key a for secondary encryption, we can get the ciphertext y1 in turn. ba ,y2 ba ,y3 ba ……yn ba .y1 ba ,y2 ba ,y3 ba ……yn ba Construct the above data set Hn(y) ba .

[0147] S5061b, mobile phone 210 sends the data set Hm(x) ab And the data set Hn(y) ba Compare and obtain the comparison result.

[0148] It should be understood that the aforementioned encryption (such as encryption using key a and encryption using key b) all use commutative encryption algorithms, such as DH and ECDH. According to the first principle of commutative encryption algorithms (for details, please refer to the terminology introduction of "PSI encryption algorithm" above), if the private information xi and the private information yj are the same, then the data set Hm(x)ab The ciphertext xi corresponding to xi ab , and the data set Hn(y) ba The ciphertext yj corresponding to yj ba equal.

[0149] Then, for the data set Hm(x) ab The ciphertext xi in ab , if the data set Hn(y) ba Includes the same ciphertext yj ba , it means that the private information y includes the ciphertext xi ab The corresponding private information xi; if the data set Hn(y) ba does not include the same ciphertext yj ba , it means that the private information y does not include the ciphertext xi ab The corresponding privacy information xi.

[0150] For example, if the comparison results in a data set Hm(x) ab The ciphertext x1 in ab With the data set Hn(y) ba The ciphertext y3 in ba If they are the same, it means that the risk number library of cloud 220 includes the incoming call number x1.

[0151] In another specific implementation, see Figure 5C , the above S506 further includes:

[0152] S5062a, mobile phone 210 uses key a to perform a check on data set Hm(x) ab Decrypt the ciphertext in and get the data set Hm(x) b .

[0153] For example, the mobile phone 210 performs the following operations on the data set Hm(x): ab The ciphertext x1 in ab Decrypt using key a to get ciphertext x1 b .x1 b Construct the above data set Hm(x) b In S601, the mobile phone 210 only needs to perform the data set Hm(x) ab In the decryption of m ciphertexts, m is much smaller than n. Therefore, compared with encrypting n ciphertexts, decrypting m ciphertexts requires less computation, takes less time, and has lower latency. This can improve query efficiency.

[0154] S5062b, mobile phone 210 sends the data set Hm(x) b And the data set Hn(y) b Compare and obtain the comparison result.

[0155] According to the second principle of the commutative encryption algorithm (for details, please refer to the terminology of the "PSI encryption algorithm" in the previous article), if the private information xi and the private information yj are the same, then for the data set Hm(x) ab Chinese ab The decrypted ciphertext xi b , and the data set Hn(y) b The ciphertext yj corresponding to yj b Then, for the data set Hm(x) b The ciphertext xi in b , if the data set Hn(y) b Includes the same ciphertext yj b , it means that the private information y includes the ciphertext xi b The corresponding private information xi; if the data set Hn(y) b does not include the same ciphertext yj b , it means that the private information y does not include the ciphertext xi b The corresponding privacy information xi.

[0156] It should be noted that in order to improve the query efficiency, the following will mainly focus on Figure 5C The method shown is used to illustrate.

[0157] It should be noted that, after comparison, the mobile phone 210 can only determine whether the cloud 220 includes the same private information as the private information x, but cannot obtain the private information other than the private information x in the cloud 220. For example, the mobile phone 210 can determine whether the risk numbers in the cloud 220 include the incoming call number x1, but cannot determine whether the cloud 220 includes numbers other than the incoming call number x1.

[0158] S507 , the mobile phone 210 prompts that the query result of the private information x corresponding to the same element in the comparison result is “yes”.

[0159] Among them, the same element refers to the data set Hm(x) ab And the data set Hn(y) ba (or dataset Hm(x) b And the data set Hn(y) b ). For example, ciphertext x1 ab and ciphertext y3 ba .

[0160] For example, the mobile phone 210 may display Figure 4A The interface 401 shown is used to prompt that the incoming call number x1, such as "10987654321", is a risky number.

[0161] It can be seen that the use of Figure 5A-Figure 5CThe solution shown can ensure that the private information x in the mobile phone 210 will not be leaked to the cloud 220 while implementing the query. On the other hand, it can ensure that the remaining private information y in the cloud 220 except the private information x will not be leaked to the mobile phone 210.

[0162] At the same time, the above Figure 5A-Figure 5C In the scheme shown, in S505, the cloud 220 needs to convert the data set Hn(y) including n ciphertexts into b The data is sent to the mobile phone 210. However, n is very large, that is, the cloud 220 needs to transmit a large amount of data to the mobile phone 210, and the communication overhead is very large, such as requiring a lot of traffic. In addition, if multiple queries are made, the communication overhead will increase exponentially. For example, if the communication overhead of one query is O(n), then the communication overhead of p queries is O(p*n). When the communication overhead increases to a certain extent, users may find it difficult to accept.

[0163] Based on this, an embodiment of the present application provides a query method, which is applied to a communication system including a mobile phone 210 and a cloud 220.

[0164] Generally, the private information x in the mobile phone 210 and / or the private information y in the cloud 220 will change dynamically over time. For example, the contact numbers in the mobile phone 210 will be added or deleted, and the registration numbers in the cloud 220 will be added or cancelled, etc. It should be understood that the above dynamic changes may cause the query results to change. For example, if there is a new contact number in the mobile phone 210, then the new contact number may be found to be a registered number. For another example, if a registered number is cancelled in the cloud 220, then the contact number that was found to be a registered number last time may change to not be a registered number because the registration number is cancelled. In addition, the rest of the data that has not changed will not cause the query results to change. For example, if a contact number was found to be a registered number last time, and the contact number in the mobile phone 210 has not been deleted since the last query, and the registration number that is the same as the contact number in the cloud 220 has not been cancelled, then the contact corresponding to the contact number can still be found to be a registered user.

[0165] Therefore, see Figure 6 In the embodiment of the present application, after the mobile phone 210 sends a query request (first query request) to the cloud 220 for the first time, the cloud 220 will not send the ciphertext of all private information y in the cloud 220 (i.e., the data set Hn(y)) to the mobile phone 210. b), but only the ciphertext of the incremental data compared to the historical query will be sent. The incremental data includes the privacy information y (such as registration number y1 and registration number y2) that may be the same as the newly added privacy information x (such as contact number x4) between time t1 and time t2, and / or the privacy information y (such as registration number yn+1 and registration number yn+2) whose status is updated (such as added) between time t1 and time t2, and the privacy information y (such as registration number yn+1) that may be the same as the privacy information x (first data, such as contact number x1, contact number x2 and contact number x3) generated before time t1.

[0166] Among them, time t2 is the current time. That is, the time when the cloud 220 determines the ciphertext of the incremental data. Time t1 is a time before time t2 when the mobile phone 210 queries the cloud 220 for the private information y. That is, time t1 is a time between the mobile phone 210 sending a query request to the cloud 220 and the mobile phone 210 obtaining the query result of the historical query in a certain historical query (such as the previous query). For example, time t1 is the time when the query result of the previous query is obtained.

[0167] Continue to see Figure 6 , mobile phone 210 can find the incremental situation of the query result (such as contact number x4 is a registered number) based on the data sent by cloud 220, and combine the query result at time t1 (such as contact number x1 and contact number x2 are registered numbers) to obtain the query result of this time (the first query result, such as contact number x1, contact number x2 and contact number x4 are registered numbers).

[0168] According to the embodiment of the present application, after receiving a non-initial query request from the mobile phone 210, the cloud 210 only sends the ciphertext of the incremental data, without sending the ciphertext of all the private information y, that is, without sending the data set Hn(y) b In this way, even if multiple queries are made, there will not be excessive communication overhead, thus saving communication overhead.

[0169] It should be noted here that Figure 6In the example and its corresponding description, although the incremental data is included in the privacy information y whose state is updated between time t1 and time t2, and the privacy information y that may be the same as the privacy information x generated before time t1 is used for explanation. However, in practice, for the query of the privacy information x generated before time t1, as long as the incremental data satisfies the privacy information y whose state is updated between time t1 and time t2, the effect of reducing the data transmission volume can be achieved. Thereby saving the communication overhead. In the following, the explanation is still mainly based on the privacy information y whose state is updated between time t1 and time t2, and the privacy information y that may be the same as the privacy information x generated before time t1, so as to achieve the reduction of data transmission volume to a greater extent.

[0170] The implementation of the embodiments of the present application will be described in detail below with reference to the accompanying drawings. Figure 7 The hardware structure diagram of an electronic device (such as a first device and a second device) provided in an embodiment of the present application. Taking the electronic device as a mobile phone 210 as an example, Figure 7 As shown, the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0171] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0172] The processor 110 can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0173] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of an electronic device. While the charging management module 140 is charging the battery 142, it may also power the electronic device through the power management module 141.

[0174] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the display screen 194, the camera 193, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be set in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

[0175] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor.

[0176] The electronic device can realize the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0177] The electronic device can realize the camera function through the camera module 193, ISP, video codec, GPU, display screen 194, application processor AP, neural network processor NPU, etc.

[0178] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The internal memory 121 can be used to store computer executable program code, which includes instructions. The internal memory 121 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the electronic device (such as audio data, a phone book, etc.), etc.

[0179] The electronic device can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0180] The key 190 may include a power key, a volume key, etc. The key 190 may be a mechanical key or a touch key. The electronic device may receive key input and generate key signal input related to user settings and function control of the electronic device.

[0181] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations acting on different applications (such as taking pictures, audio playback, etc.) can correspond to different vibration feedback effects. Indicator 192 can be an indicator light, which can be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0182] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to or disconnected from the electronic device by inserting the SIM card interface 195 or pulling the SIM card out of the SIM card interface 195.

[0183] It should be noted that the above Figure 7 The hardware structure of the electronic device shown is only exemplary. In practice, the electronic device may have more Figure 7 More or less structures. Taking the electronic device as cloud 220 as an example, the electronic device may mainly include a processor and a memory.

[0184] The following still takes the first device being a mobile phone 210 and the second device being a cloud 220 as an example to explain in detail the query method provided in the embodiment of the present application.

[0185] See also Figure 8 The query method provided in the embodiment of the present application includes the following four stages:

[0186] Phase 1, cloud 220 data initialization phase. In phase 1, cloud 220 needs to encrypt n pieces of private information y to obtain a data set Hn(y) b Exemplarily, the cloud 220 needs to execute S501 mentioned above.

[0187] In some embodiments, the cloud 220 can complete data initialization offline to avoid initialization operations during the query process and reduce query latency.

[0188] Phase 2, mobile phone 210 request phase. In phase 2, mobile phone 210 responds to the query event, needs to encrypt the private information x and send a query request to cloud 220. Exemplarily, in phase 2, mobile phone 210 can complete the above steps S502-S503.

[0189] Phase 3, cloud 220 query response phase. In phase 3, cloud 220 may respond to the query request from mobile phone 210. Exemplarily, in phase 3, cloud 220 needs to complete the above steps S504-S505.

[0190] Phase 4, the mobile phone 210 compares the data sent by the cloud 220, thereby obtaining the query result. For example, in phase 4, the mobile phone 210 can complete the above S506-S507.

[0191] In practice, the amount of data included in the private information set Hn(y) is very large. Accordingly, the encrypted data set Hn(y) b The amount of ciphertext data in is also very large. The data set Hn(y) is subsequently transmitted to the mobile phone 210. b It requires a lot of communication overhead, such as a lot of traffic. When the communication overhead increases to a certain extent, users may find it difficult to accept. To address this problem, the cloud 220 can also reduce the amount of data transmitted to the mobile phone 210 through data processing, thereby saving communication overhead. Specifically, the cloud 220 can process the data set Hn(y) b The ciphertext buckets and / or compressed datasets Hn(y) in b The ciphertext in the method can be used to reduce the amount of data transmitted to the mobile phone 210. The following are respectively described:

[0192] In some embodiments, in stage 1, the cloud 220 may store the data set Hn(y) b The large amount of ciphertext included is divided into multiple buckets (which can also be understood as groups). Later in stage 3, when the cloud 220 sends the ciphertext to the mobile phone 210, it can only send the ciphertext in the required bucket (which can be called the target bucket), thereby reducing communication overhead.

[0193] See also Fig. 9In phase 1, cloud 220 may complete the following steps:

[0194] S901. The cloud 220 calculates hash values ​​for n pieces of private information y respectively to obtain n hash values.

[0195] The cloud 220 may use a hash algorithm (HA) to calculate a hash value of each piece of private information y. For example, the hash algorithm includes Message-Digest Algoorithm 4 (MD4), Message-Digest Algoorithm 5 (MD5), Secure Hash Algorithm 256 (SHA-256), Hash-based Message Authentication Code (HMAC), etc.

[0196] Taking the n pieces of private information y as risk numbers y1, y2, y3, y4 as an example, the mobile phone 210 calculates the hash values ​​of the n risk numbers and can obtain the hash values ​​0002E11A0C0E...51A1518, 000341AA6176...C300081, 000C497DE639...4BB1298, 0002DF235902...D6B71BD in sequence.

[0197] It should be understood that the hash algorithm is an irreversible encryption algorithm, and therefore, it can prevent the encrypted hash value from being restored to plain text by other devices (such as mobile phone 210), further improving data security.

[0198] S902 (i.e., S501 above), cloud 220 encrypts n pieces of private information y using key b (second key) to obtain a data set Hn(y) b .

[0199] In a specific implementation, the cloud 220 may encrypt the n pieces of private information y itself to achieve encryption of the n pieces of private information y. Fig. 9 This implementation is not shown in the figure. For example, the cloud 220 can encrypt the risk number itself. It should be noted that if this implementation is adopted, there is no strict order restriction between S901 and S902, and S901 and S902 only need to be completed before S903.

[0200] In another specific implementation, the cloud 220 may encrypt n hash values ​​corresponding to n pieces of private information y to encrypt the n pieces of private information y. Fig. 9This is the implementation shown. For example, the cloud 220 can encrypt the hash values ​​of the risk numbers 0002E11A0C0E…51A1518, 000341AA6176…C300081, 000C497DE639…4BB1298, 0002DF235902…D6B71BD respectively to obtain the ciphertext y1 b ,y2 b ,y3 b ,y4 b .

[0201] S903, cloud 220 sends the data set Hn(y) b The ciphertext yj in b Divide into the bucket corresponding to the hash value prefix of the private information yj, 1≤j≤n, j is an integer.

[0202] Before S903, cloud 220 can represent buckets according to the possible values ​​of the hash value prefix (i.e., the first k bits). Among them, k can be 8, 12, 16, etc. For example, k=16, that is, buckets are represented according to the possible values ​​of the first 16 bits, then buckets 0x 0000, buckets 0x 0001... buckets 0x ffff can be obtained. Among them, 0x represents hexadecimal. It should be understood that for simplicity, 0x will be omitted in the following text and figures.

[0203] For any private information yj, after the above S901, the hash value of the private information yj is obtained, such as S(yj); and after the above S902, the ciphertext yj of the private information yj is obtained. b In S903, the cloud 220 can convert the ciphertext yj b Divide into buckets corresponding to the hash value prefix of S(yj).

[0204] Taking k=16 as an example, the hash value of the risk number y1 is 0002E11A0C0E…51A1518, that is, the hash value prefix is ​​0002. Then, the ciphertext y1 b Divided into bucket 0002; the hash value of risk number y2 is 000341AA6176…C300081, that is, the hash value prefix is ​​0003, then the ciphertext y2 b Divided into bucket 0003; the hash value of risk number y3 is 000C497DE639…4BB1298, that is, the hash value prefix is ​​000C, then the ciphertext y3 b Divided into bucket 000C; the hash value of risk number y4 is 0002DF235902…D6B71BD, that is, the hash value prefix is ​​0002, then the ciphertext y4 b Divide into bucket 0002.

[0205] After S903, the buckets will include ciphertexts. For example, the ciphertexts included in each bucket are shown in Table 1 below:

[0206] Table 1

[0207]

[0208] Among them, bucket 0002 contains ciphertext y1 b ,yn b ; Bucket 0003 contains ciphertext y2 b ; Bucket 000C contains ciphertext y3 b .

[0209] At this point, the cloud 220 can divide the ciphertexts of the n pieces of private information y into multiple buckets, so as to subsequently determine the target bucket.

[0210] In phase 2, the mobile phone 210 can also obtain the hash value prefixes of the m pieces of private information x, so that the cloud 220 can determine the target bucket in phase 3.

[0211] See also Fig.10 In stage 2, the mobile phone 210 can complete the following steps:

[0212] S1001. In response to a query event, the mobile phone 210 calculates hash values ​​for m pieces of private information x respectively to obtain m hash values.

[0213] Exemplarily, a hash value is calculated for the incoming call number x1, and a hash value of 0002936ED794…8921B4B is obtained.

[0214] For the specific implementation of S1001, please refer to the relevant description of S901 above, which will not be repeated here. It should be noted that in order to make the hash value of private information y and the hash value of private information x comparable, in S1001, the hash algorithm used by mobile phone 210 is the same as the hash algorithm used by cloud 220 in S901 above. Furthermore, in order to quickly obtain the query result after receiving the query event, cloud 220 and mobile phone 210 can use a hash algorithm with faster computing speed to calculate the hash value, such as MD5, SHA256, etc.

[0215] S1002 (i.e., S502 above), the mobile phone 210 encrypts the m pieces of private information x using the key a (the first key) to obtain the data set Hm(x) a .

[0216] Similar to the above S902: In a specific implementation, the mobile phone 210 can encrypt the m pieces of private information x itself to achieve encryption of the m pieces of private information x. Fig.10 This implementation is not shown. For example, the mobile phone 210 can encrypt the incoming call number x1 itself. It should be noted that if this implementation is adopted, there is no strict order restriction between S1001 and S1002, and S1001 and S1002 only need to be completed before S1003. In another specific implementation, the mobile phone 210 can also encrypt the m hash values ​​corresponding to the m pieces of private information x to encrypt the m pieces of private information. Fig.10 This is the implementation shown. For example, the mobile phone 210 can encrypt the hash value 0002936ED794...8921B4B of the incoming call number x1.

[0217] It should be noted that, in order to ensure the comparability of the ciphertexts of the n pieces of private information y in the cloud 220 and the ciphertexts of the m pieces of private information x in the mobile phone 210, if the method of encrypting the private information y itself is adopted in S902, the method of encrypting the private information x itself should also be adopted in S1002. If the method of encrypting the hash value of the private information y is adopted in S902, the method of encrypting the hash value of the private information x should also be adopted in S1002.

[0218] S1003, the mobile phone 210 constructs a hash value prefix and a data set Hm(x) based on the m hash values a The relationship dictionary of each ciphertext in 1.

[0219] For any private information xi, after the above S1001, the hash value of the private information xi is obtained, such as S(xi); and after the above S1002, the ciphertext xi of the private information xi is obtained. a , such as ciphertext x1 a In S1003, the mobile phone 210 can establish the hash value prefix and ciphertext xi of S(xi) a , and obtain the relationship dictionary 1. For example, the relationship dictionary 1 includes the hash value prefix 0002 of the hash value 0002936ED794…8921B4B of the incoming call number x1 and the ciphertext x1 a The corresponding relationship.

[0220] In the mobile phone 210, the above-mentioned relationship dictionary 1 may be maintained. Exemplarily, the data structure in the relationship dictionary 1 is shown in the following Table 2:

[0221] Table 2

[0222] Hash value prefix Ciphertext 0002 <![CDATA[x1 a ]]>

[0223] S1004 . The mobile phone 210 sends a query request to the cloud 220 . The query request includes the relationship dictionary 1 .

[0224] The relational dictionary 1 includes the ciphertext of m pieces of private information x, i.e., the data set Hm(x) a It can be seen that in this embodiment, the mobile phone 210 can send the data set Hm(x) to the cloud 220 by sending the relationship dictionary 1 to the cloud 220. a , that is, to implement the above S503.

[0225] The mobile phone 210 may send a query request to the cloud 220 in a secure and encrypted manner, such as https, to ensure information security.

[0226] And, in stage 3, the cloud 220 can determine the target bucket according to the hash value prefix included in the relationship dictionary 1 to reduce the amount of data returned to the mobile phone 210 and reduce communication overhead.

[0227] See also Fig.11 In stage 3, cloud 220 may complete the following steps:

[0228] S1101. Cloud 220 queries relational dictionary 1 for a target bucket corresponding to a hash value prefix.

[0229] Cloud 220 traverses each hash value prefix in relational dictionary 1 and searches for the target bucket corresponding to the hash value prefix. For example, the hash value prefix in relational dictionary 1 includes 0002. Then, cloud 220 can search for the target bucket as bucket 0002.

[0230] It should be understood that if private information x and private information y are the same, then their hash values ​​should also be the same. At the same time, the bucket is identified by the hash value prefix, and the bucket includes the ciphertext of private information y. The hash value prefix in relational dictionary 1 is the hash value prefix of private information x. Therefore, by searching for the target bucket corresponding to the hash value prefix in relational dictionary 1, the ciphertext of private information y that may be the same as private information x can be found.

[0231] S1102, cloud 220 uses key b to re-encrypt the ciphertext in relational dictionary 1 to obtain data set Hm(x) ab .

[0232] It should be understood that the ciphertext in the relational dictionary 1 is the data set Hm(x) mentioned above. a , then for the data set Hm(x) a After encrypting each ciphertext in, we can get the data set Hm(x) ab , thereby realizing the process of S504 above, which will not be repeated here.

[0233] There is no strict sequence between S1101 and S1102 in the foregoing. In practice, S1101 and S1102 may be performed in sequence, S1102 and S1101 may be performed in sequence, or S1101 and S1102 may be performed simultaneously. This embodiment of the application does not specifically limit this.

[0234] S1103, cloud 220 takes the ciphertext and data set Hm(x) in the target bucket ab Sent to mobile phone 210.

[0235] For example, the cloud 220 can also send the ciphertext and data set Hm(x) in the target bucket to the mobile phone 210 in a secure encrypted manner, such as https. ab , to ensure information security.

[0236] Compared with the embodiment without bucketing: In this embodiment, the cloud 220 does not ciphertext all its private information y, such as the data set Hn(x) b is sent to the mobile phone 210, and only the ciphertext in the target bucket (such as data set Hn0(x) b ) is sent to the mobile phone 210. Where n0 is the number of ciphertexts included in the target bucket, and n0 is a positive integer less than n. That is, the previous S505 will be updated to S1103. In this way, the amount of data sent by the cloud 220 to the mobile phone 210 can be reduced, reducing communication overhead.

[0237] At this point, it should be noted that different values ​​of k will reduce the communication overhead to different degrees. The larger the value of k, the greater the degree of reduction in communication overhead. The following will explain in detail the impact of the value of k on communication overhead:

[0238] The larger the value of k is, the finer the bucketing is. Then, in phase 1, when the ciphertext of the private information y in the cloud 220 is divided into buckets, the ciphertext can be dispersed into more buckets, making the ciphertext bucketing finer.

[0239] Exemplarily, the private information y in the cloud 220 and its hash value and ciphertext are shown in Table 3 below:

[0240] Table 3

[0241] Privacy Information Hash value Ciphertext Risk Number y1 0002E11A0C0E…51A1518 <![CDATA[Ciphertext y1 b > Risk Number y2 000341AA6176…C300081 <![CDATA[Ciphertext y2 b > Risk Number y3 000C497DE639…4BB1298 <![CDATA[Ciphertext y3 b > Risk Number y4 0002DF235902…D6B71BD <![CDATA[Ciphertext y4 b >

[0242] Taking the data in Table 3 above as an example, see Fig.12 , the following compares the buckets to which the four private information y in Table 3 belong when k = 8 and k = 16:

[0243] When k=8, buckets 00, 01, ... ff can be obtained, for a total of 256 buckets; and when k=16, buckets 0000, 0001, ... ffff can be obtained, for a total of 65536 buckets. Obviously, compared with k=8, when k=16, more buckets can be obtained, and the buckets are more refined.

[0244] The first 8 bits of the 4 hash values ​​in Table 3 are all 00. In phase 1, if k=8 buckets are used, the 4 ciphertexts y1 in Table 3 are b 、ciphertext y2 b 、Ciphertext y3 b And the ciphertext y4 b will be divided into bucket 00. That is, bucket 00 includes 4 ciphertexts. The first 16 bits of the 4 hash values ​​in Table 3 are 0002, 0003, 000C and 0002 respectively. In stage 1, if k=16 buckets are used, the 4 ciphertexts y1 in Table 3 are b 、ciphertext y2 b 、Ciphertext y3 b And the ciphertext y4 b will be divided into bucket 0002, bucket 0003, bucket 000C and bucket 0002 in sequence. That is, the 4 ciphertexts are divided into 3 buckets, of which bucket 0002 includes 2 ciphertexts, bucket 0003 includes 1 ciphertext, and bucket 000C includes 1 ciphertext. Obviously, compared with k=8: k=16 can make the ciphertext bucketing more refined.

[0245] Accordingly, in stage 3, the target bucket determined by cloud 220 contains fewer ciphertexts. Fig.12 The example of , and the private information x in the mobile phone 210 and its hash value and ciphertext are shown in Table 4 below:

[0246] Table 4

[0247] Privacy Informationx Hash value Ciphertext Incoming call number x1 0002936ED794…8921B4B <![CDATA[Ciphertext x1 a >

[0248] k=8, then the hash value prefix of the hash value 0002936ED794…8921B4B in Table 4 is 00. Then, in stage 3, cloud 220 can determine that the target bucket is bucket 00, and thus the ciphertext in bucket 00, such as ciphertext y1 b 、ciphertext y2 b 、Ciphertext y3 b And the ciphertext y4 b Send it to mobile phone 210. k = 16, then the hash value prefix of the hash value 0002936ED794…8921B4B in Table 4 is 0002. Then, in stage 3, cloud 220 can determine that the target bucket is bucket 0002, and thus the ciphertext in bucket 002, ciphertext y3b And the ciphertext y4 b It is sent to the mobile phone 210. Obviously, compared with k=8, when k=16, the cloud 220 sends less ciphertext to the mobile phone 210, thereby reducing the communication overhead to a greater extent.

[0249] Therefore, in order to further reduce the communication overhead, k can be set to a larger value.

[0250] However, the larger the value of k, the more bits of the hash value will be used to identify the bucket, that is, more bits in the hash value will be exposed. Correspondingly, the number of remaining unexposed bits will be smaller, and the degree of privacy protection will be lower.

[0251] Taking the example of a hash value with 128 bits, if k=16, the first 16 bits of the hash value of the private information x will be sent to the cloud 220 as the hash value prefix in the relational dictionary 1, that is, exposed to the cloud 220. The remaining unexposed hash value bits are 128-16=112 bits. If k=64, the first 64 bits of the hash value of the private information x will be sent to the cloud 220 as the hash value prefix in the relational dictionary 1, that is, exposed to the cloud 220. The remaining unexposed hash value bits are only 128-64=64 bits. Obviously, compared with k=16: when k=64, there are fewer unexposed bits, the cloud 220 is more likely to predict the private information x, and the degree of privacy protection is lower.

[0252] In summary, in actual implementation, the appropriate k value can be set based on the requirements for communication overhead and the degree of privacy protection.

[0253] Since, in stage 3, the cloud 220 sends the ciphertext of the target bucket, then in stage 4, the mobile phone 210 only needs to send the data set Hm(x) b Compare with the ciphertext in the target bucket.

[0254] See also Fig.13 In stage 4, the mobile phone 210 can complete the following steps:

[0255] S1301 (i.e., S506 above), mobile phone 210 uses key a to perform a check on data set Hm(x) ab The ciphertext in is decrypted once to obtain the data set Hm(x) b .

[0256] For the specific implementation of S1301, please refer to the description in S506 above.

[0257] S1302, mobile phone 210 sends data set Hm(x) b Compare it with the ciphertext in the target bucket to get the comparison result.

[0258] For example, the dataset Hm(x) b Includes the ciphertext x1 of the incoming call number x1 b , and the target bucket is bucket 0002, which contains the ciphertext y1 b and ciphertext y4 b Therefore, mobile phone 210 can compare ciphertext x1 b Is it consistent with the ciphertext y1 b Or the ciphertext yn b The same, get the comparison result. Among them, if the ciphertext x1 b With the ciphertext y1 b Or the ciphertext yn b If the ciphertext x1 is the same as b With the ciphertext y1 b and ciphertext yn b If they are all different, it means that the incoming call number x1 is not a risky number.

[0259] In this embodiment, the cloud 220 only sends the ciphertext in the target bucket (i.e., the data set Hn0(y) b ) is used for comparison, therefore, in S1302, the data compared by the mobile phone 210 is the data set Hn0(y) b , rather than the ciphertext of all private information y in the cloud 220. That is, the previous S506 is updated to S1302. In this way, the amount of data to be compared by the mobile phone 210 can be reduced, and the comparison efficiency can be improved.

[0260] S1303 (ie, S507 above), the mobile phone 210 prompts that the query result of the private information x corresponding to the same element in the comparison result is "yes".

[0261] For the specific implementation of S1303, please refer to the description in S507 above.

[0262] In the previous description of stage 1 to stage 4, scenario 2 (i.e., anti-fraud cloud check scenario) is used as an example. In scenario 2, the private information x in the mobile phone 210 is the currently received incoming call number x1, that is, there is only one piece of private information x. Then, in stage 3, the cloud 220 determines only one target bucket. Correspondingly, in stage 4, the mobile phone 210 only needs to compare the ciphertext of one incoming call number x1 with the ciphertext in one target bucket.

[0263] However, in other scenarios (such as scenario 1 and scenario 3), there may be multiple pieces of private information x in the mobile phone 210, and multiple target buckets may be determined in stage 3. Accordingly, in stage 4, the mobile phone 210 needs to compare the multiple pieces of private information x with the ciphertexts in the multiple target buckets. For example, in scenario 1, the mobile phone 210 includes multiple contact numbers, and the hash value prefixes of the multiple contact numbers involve 0002, 0003, and ffee, then the target buckets include bucket 0002, bucket 0003, and bucket ffee, then the mobile phone 210 needs to compare the ciphertexts of the multiple contact numbers with the ciphertexts in bucket 0002, bucket 0003, and bucket ffee.

[0264] In this case, if each piece of private information x (such as a contact number) is compared with the ciphertext in bucket 0002, bucket 0003, and bucket ffee, the workload of the comparison will be very large, affecting the query efficiency. Based on this, in some embodiments, in stage 3, the mobile phone 210 can also establish a data set Hm(x) ab The relationship dictionary 2 between each ciphertext in the target bucket and the ciphertext in the target bucket; then, in stage 4, for the data set Hm(x) ab Any ciphertext xi in ab Decryption gets the ciphertext xi b , mobile phone 210 only needs to send the ciphertext xi b and the ciphertext xi in relation dictionary 2 ab The corresponding ciphertext is compared to reduce the comparison workload and improve query efficiency.

[0265] Specifically, Fig.14 As shown, in stage 3, cloud 220 can complete the following steps:

[0266] S1401, cloud 220 queries the target bucket corresponding to the hash value prefix in relational dictionary 1. For details, please refer to the description of S1101 above.

[0267] Exemplarily, the content included in the relationship dictionary 1 is shown in the following Table 5:

[0268] Table 5

[0269]

[0270] Then, cloud 220 may determine that the target buckets include bucket 0002, bucket 0003, and bucket ffee.

[0271] S1402, cloud 220 uses key b to re-encrypt the ciphertext in relational dictionary 1 to obtain data set Hm(x) ab For details, please refer to the description of S1102 above.

[0272] For example, cloud 220 encrypts the four ciphertexts in relational dictionary 1 shown in Table 5 twice to obtain ciphertext x1 in sequence ab 、Ciphertext x2 ab 、Ciphertext x3 ab and ciphertext x4 ab That is, the data set Hm(x) ab Including ciphertext x1 ab 、Ciphertext x2 ab 、Ciphertext x3 ab and ciphertext x4 ab .

[0273] S1403, cloud 220 establishes data set Hm(x) ab The relationship dictionary between each ciphertext in the target bucket and the ciphertext in the target bucket 2.

[0274] For the data set Hm(x) ab Any ciphertext xi in ab , we can create the ciphertext xi ab With the ciphertext xi a The corresponding relationship between the ciphertext of the first bucket in the target bucket. Among them, the first bucket is the ciphertext xi a The bucket corresponding to the hash value prefix.

[0275] For example, if the relation dictionary 1 is as shown in Table 5 above, the cloud 220 can establish a data set Hm(x) ab Chinese Cipher Text x1 ab and ciphertext x3 ab Corresponding relationship with the ciphertext in bucket 0002, ciphertext x4 ab The corresponding relationship with the ciphertext in bucket 0003, and the ciphertext x2 ab The corresponding relationship between the ciphertext in the bucket ffee is obtained to obtain the relational dictionary 2. For example, the data structure in the relational dictionary 2 is shown in Table 6 below:

[0276] Table 6

[0277]

[0278] S1404 . The cloud 220 sends the relationship dictionary 2 to the mobile phone 210 .

[0279] In relational dictionary 2, the ciphertext of private information y constitutes the previous data set Hn0(y) b , the ciphertext of the private information x constitutes the previous data set Hm(x) ab Therefore, by sending the relational dictionary 2 to the mobile phone 210 , the ciphertext and the data set Hm(x)ab in the target bucket can be sent to the mobile phone 210 , that is, S1103 is implemented.

[0280] In this embodiment, Fig.15As shown, in stage 4, the mobile phone 210 can complete the following steps:

[0281] S1501, mobile phone 210 uses key a to compare data set Hm(x) in relation dictionary 2 ab The ciphertext in is decrypted once to obtain the data set Hm(x) b Please refer to the description in S506 above.

[0282] Exemplarily, the mobile phone 210 may decrypt the ciphertext of the private information x in Table 6 above.

[0283] S1502, mobile phone 210 sends data set Hm(x) b The ciphertext xi in b and the ciphertext xi in relation dictionary 2 ab The corresponding ciphertexts are compared to obtain the comparison results.

[0284] For example, the dataset Hm(x) b Includes ciphertext x1 b 、Ciphertext x2 b 、Ciphertext x3 b and ciphertext x4 b , then the mobile phone 210 can convert the ciphertext x1 b and the ciphertext x1 in relation dictionary 2 ab The corresponding ciphertext (such as the ciphertext in bucket 0002 in Table 6) is compared and the ciphertext x2 b and the ciphertext x2 in relation dictionary 2 ab The corresponding ciphertext (such as the ciphertext in bucket ffee in Table 6) is compared and the ciphertext x3 b and the ciphertext x3 in relation dictionary 2 ab The corresponding ciphertext (such as the ciphertext in bucket 0002 in Table 6) is compared, and the ciphertext x4 b and the ciphertext x4 in relation dictionary 2 ab The corresponding ciphertext (such as the ciphertext in bucket 0003 in Table 6) is compared.

[0285] Obviously, for the data set Hm(x) b Any ciphertext xi in b , the mobile phone 210 does not need to compare it with Hn0(y) b All ciphertexts in the . This reduces the workload of comparison and improves query efficiency.

[0286] S1503, the mobile phone 210 prompts that the query result of the privacy information corresponding to the same element in the comparison result is "yes". For details, please refer to the description in the above S507.

[0287] In practice, the private information x in the mobile phone 210 and / or the private information y in the cloud 220 will change dynamically over time. For example, the contact numbers in the mobile phone 210 will be added or deleted, and the registration numbers in the cloud 220 will be added or cancelled, etc. Moreover, the above dynamic changes will cause the query results to change. For example, if there is a new contact number in the mobile phone 210, then it may be found that the contact corresponding to the new contact number is a registered user. For another example, if a registration number is cancelled in the cloud 220, then the contact that was found to be a registered user last time may change to not being a registered user. In addition, the rest of the data that has not changed will not cause the query results to change. For example, the contact corresponding to the contact number was found to be a registered user last time, and after the last query, the contact number in the mobile phone 210 has not been deleted, and the registration number in the cloud 220 that is the same as the contact number has not been cancelled, then the query is still that the contact corresponding to the contact number is a registered user.

[0288] Based on this, in some embodiments, cloud 220 can obtain the above dynamically changing incremental data and send it to mobile phone 210 so that mobile phone 210 can determine the change of query results. Finally, mobile phone 210 combines the historical query results with the change of query results to obtain the current query results.

[0289] See also Fig.16 In this embodiment, in stage 1, after S903, it further includes S1601:

[0290] S1601. Cloud 220 establishes a correspondence between the ciphertext of private information y and the update time tag and the cancellation tag of private information y to obtain a relationship dictionary 3.

[0291] The update time tag is used to indicate the update time of the private information y, such as the time when the private information y was added or cancelled. The cancellation tag is used to indicate whether the private information y is cancelled.

[0292] And, the relation dictionary 3 includes the correspondence between the hash value prefix, the ciphertext of the private information y, and the update label.

[0293] For example, the bucketing result is shown in Table 1 above. Cloud 220 can add update time and logout fields based on Table 1 to obtain the relationship dictionary 3 shown in Table 7 below:

[0294] Table 7

[0295]

[0296] In a specific implementation method, when establishing the relationship dictionary 3, the update time label (such as the "Update Time" field in Table 7) is uniformly set to the current time, such as 2023-4-22; and the deregistration label (such as the "Deregistration" field in Table 7) is set according to the actual situation of whether each piece of privacy information y is deregistered.

[0297] After S1601, the initial relationship dictionary 3 is constructed. Subsequently, if it is detected that the private information y is updated, such as a new addition or a cancellation, the cloud 220 needs to update the relationship dictionary 3, as shown in S1602 and S1603 below:

[0298] S1602. In response to the newly added private information y00, the cloud 220 adds a record of the private information y00 in the relational dictionary 3. The record of the private information y00 includes the hash value prefix, ciphertext, update time label and logout label of the private information y00, and obtains the updated relational dictionary 3.

[0299] For example, if a new user registers for social application A, cloud 220 may find that a new registration number has been added, that is, the private information y00 is the new registration number.

[0300] The cloud 220 may record the current time as the update time of the private information y0.

[0301] For example, the hash value of the private information y00 is 0a9e, and the ciphertext is y00 b , the current time is 2023-4-23, then a new record can be added to the above Table 7 to obtain the relationship dictionary 3 shown in the following Table 8:

[0302] Table 8

[0303]

[0304] S1603 . In response to the cancellation of the private information y11 , the cloud 220 changes the update time tag and the cancellation tag of the private information y11 in the relationship dictionary 3 to obtain an updated relationship dictionary 3 .

[0305] For example, if a user cancels his account in social application A, cloud 220 may find that a registration number has been cancelled, that is, the private information y11 is the cancelled registration number.

[0306] The cloud 220 may record the current time as the update time of the privacy information y11, and change the logout tag to yes.

[0307] For example, the private information y11 is the ciphertext y1 in Table 8 above. b The corresponding privacy information, the current time is 2023-4-25, then the ciphertext y1 in Table 8 above can be bThe corresponding value of the "Update Time" field is changed to 2023-4-25, and the value of the "Deregister" field is changed to "Yes", resulting in the relationship dictionary 3 shown in Table 9 below:

[0308] Table 9

[0309]

[0310] Combine the following Fig.17 To illustrate the specific implementation of the first query:

[0311] In the first query, in stage 2, the mobile phone 210 may carry information indicating that no comparison has occurred in the query request (such as the comparison time tag 1 described below), so that the cloud 220 can determine that it is the first query. Specifically, the mobile phone 210 may perform the following S1701-S1704:

[0312] S1701, in response to the query event, the mobile phone 210 calculates hash values ​​for the m1 pieces of private information x currently in the mobile phone 210, and obtains m1 hash values. For details, please refer to the description of S1001.

[0313] It should be understood that the private information x in the mobile phone 210 may be deleted or added, so the private information x in each query may be different. For the sake of distinction, the private information x in the mobile phone 210 in the first query is recorded as m1 pieces of private information x.

[0314] S1702, mobile phone 210 encrypts m1 pieces of private information using key a to obtain data set Hm1(x) a For details, please refer to the description of S1002.

[0315] S1703, mobile phone 210 constructs hash value prefix, data set Hm1(x) a The corresponding relationship between each ciphertext, comparison time label 1 and added label 1 in the ciphertext dictionary 4 is obtained. Among them, the comparison time label 1 indicates that no comparison has occurred, and the added label 1 indicates that the private information x is not newly added.

[0316] That is, based on the relationship dictionary 1 constructed in the previous S1003, the comparison time label and the newly added label are further added.

[0317] For example, the relationship dictionary 1 is as shown in Table 5 above. Based on Table 5, the cloud 220 can add a comparison time tag and a new tag to obtain the relationship dictionary 4 shown in Table 10 below:

[0318] Table 10

[0319]

[0320] In Table 10 above, the value "NA" in the "Comparison Time" field is the comparison time label 1, which is used to indicate that no comparison has occurred. And the value "No" in the "Newly Added" field is the new addition label 1, which is used to indicate that the private information x is not newly added.

[0321] S1704 . The mobile phone 210 sends a query request (a second query request) to the cloud 220 . The query request includes the relationship dictionary 4 .

[0322] Relationship dictionary 4 includes relationship dictionary 1. Therefore, when mobile phone 210 sends relationship dictionary 4 to cloud 220, it can also send relationship dictionary 1 to cloud 220.

[0323] In the first query, in stage 3, cloud 220 can determine that it is the first query, and return the full amount of data that may be the same for the first query. Specifically, cloud 220 can perform the following S1705-S1708:

[0324] S1705 , the cloud 220 determines that the relationship dictionary 4 includes the comparison time tag 1 .

[0325] If the relation dictionary 4 includes the comparison time tag 1, it indicates that it is the first query. For the first query, the cloud 220 may use S1706-S1708 to process.

[0326] S1706, cloud 220 queries the target bucket corresponding to the hash value prefix in relational dictionary 4. For details, please refer to the description of S1101 above.

[0327] S1707, cloud 220 uses key b to re-encrypt the ciphertext in relational dictionary 4 to obtain data set Hm1(x) ab For details, please refer to the description of S1102 above.

[0328] S1708, cloud 220 sends the ciphertext of the target bucket and its corresponding cancellation tag, as well as the data set Hm1(x) to mobile phone 210 ab .

[0329] In this embodiment, the cloud 220 not only sends the ciphertext included in the target bucket to the mobile phone 210, but also sends the cancellation tag of the ciphertext to the mobile phone 210, so that the mobile phone 210 can determine whether the private information y corresponding to the ciphertext is cancelled.

[0330] For example, the target bucket includes bucket 0002 in Table 9 above, then cloud 220 needs to send ciphertext y1 b and its cancellation label "yes", and the ciphertext y4 b and its deregistration label "No".

[0331] In the first query, in stage 4, the mobile phone 210 not only needs to compare and obtain the same elements, but also needs to further determine the query result by combining whether the data returned by the cloud 220 is deregistered data or newly added data. Specifically, the mobile phone 210 can execute the following S1709-S1711:

[0332] S1709, mobile phone 210 uses key a to perform a check on data set Hm1(x) ab The ciphertext in is decrypted once to obtain the data set Hm1(x) b For details, please refer to the description of S1301 above.

[0333] S1710, mobile phone 210 sends data set Hm1(x) b Compare the ciphertext in the target bucket with the ciphertext in the target bucket.

[0334] S1711, if the data set Hm1(x) b The ciphertext xi in b and the ciphertext yj in the target bucket b The same, and the ciphertext yj b The logout label indicates that the logout has not been completed, and the mobile phone 210 displays the query result of the private information xi as "yes".

[0335] If the ciphertext xi b With the ciphertext yj b The same can only mean that the two are the same element. Furthermore, only the ciphertext yj b The logout tag indicates that the ciphertext yj b The corresponding private information yj is still valid, for example, it is still a risk number, still a registration number, etc. In this case, the query result is displayed as yes.

[0336] On the contrary, if the ciphertext xi b With the ciphertext yj b Different, or, the ciphertext xi b With the ciphertext yj b Same, but ciphertext yj b If the logout label (such as "yes") indicates that the user has logged out, the query result is displayed as no, or is not displayed.

[0337] In addition, after the first query is completed, the mobile phone 210 may also execute the following S1712:

[0338] S1712. Mobile phone 210 updates the comparison time.

[0339] Exemplarily, the mobile phone 210 updates the comparison time to the current time, such as 2023-4-24. When the comparison time is used for the next query, the mobile phone 210 determines the comparison time tag in the relationship dictionary 4.

[0340] It should be noted that Fig.17 In the embodiment, the mobile phone 210 executes S1712 only after the stage 4 is completed. In practice, this is not a limitation, and the mobile phone 210 can execute S1712 at any time during the first query process. For example, after executing S1704 to send the query request, S1712 is executed immediately to update the comparison time.

[0341] After completing the above-mentioned first query, the mobile phone 210 may also send a query request to the cloud 220 for the second, third, ... time, that is, triggering the second, third, ... query, which are collectively referred to as non-first query.

[0342] Combine the following Fig.18 , explaining the specific implementation of non-first query:

[0343] When it is not the first query, in stage 2, the mobile phone 210 can carry information indicating that a comparison has occurred in the query request (such as the comparison time tag 2 described below), so that the cloud 220 can determine that it is not the first query. In addition, the mobile phone 210 can also carry information indicating whether each piece of private information x is new data in the mobile phone 210 (such as the new tag 2 described below) in the query request, so that the cloud 220 can determine whether the data to be queried is new data in the mobile phone 210 or data that has been queried historically. Specifically, the mobile phone 210 can execute the following S1801-S1804:

[0344] S1801. In response to a query event, the mobile phone 210 calculates hash values ​​for the m2 pieces of private information x currently in the mobile phone 210, and obtains m2 hash values. For details, please refer to the description of S1001.

[0345] Similar to S1701, for the sake of distinction, the private information x in the mobile phone 210 when it is not the first query is recorded as m2 pieces of private information x.

[0346] S1802, mobile phone 210 encrypts m2 pieces of private information x using key a to obtain data set Hm2(x) a For details, please refer to the description of S1002.

[0347] For the sake of convenience, among the m2 pieces of private information x, the piece of information that the mobile phone 210 has queried from the cloud 220 at time t1 is called the first data, and the data set Hm2(x) a The ciphertext of the first data (first ciphertext) is included.

[0348] S1803, mobile phone 210 constructs hash value prefix, data set Hm2(x) aThe corresponding relationship between each ciphertext, comparison time label 2 and added label 2 in the ciphertext dictionary 5 is obtained. Among them, the comparison time label 2 indicates the last comparison time, and the added label 2 indicates whether it is newly added or not.

[0349] Different from the first query, when it is not the first query, at least one query has occurred, so there is a comparison time. Therefore, the comparison time of each piece of private information x no longer indicates that no comparison has occurred, but indicates the last comparison time, such as the comparison time recorded in S1712 above.

[0350] Also, in the process from the last query to the current query, new private information x may be generated in the mobile phone 210. When it is not the first query, the new label 2 of the new private information x is set to indicate new addition. Except for the new private information x, the new labels 2 of the remaining private information x are all set to indicate not new addition.

[0351] Exemplarily, the relationship dictionary 5 is shown in Table 11 below:

[0352] Table 11

[0353]

[0354]

[0355] In Table 11 above, the value "2023-4-24" of the "Comparison Time" field is the comparison time label 2, which is used to indicate that the last comparison time is 2023-4-24. And the value "yes" or "no" of the "newly added" field is the new label 2. Among them, the value of the "newly added" field of some ciphertexts is "yes", which is used to indicate that the private information x is newly added; the value of the "newly added" field of some ciphertexts is "no", which is used to indicate that the private information x is not newly added.

[0356] Taking the last query as the first query as an example, Table 11 updates the comparison time compared to Table 10 and adds the ciphertext x5 a Records, and reduced ciphertext x3 a This means that compared with the first query, the ciphertext x5 has been added. a The corresponding private information x, and the deleted ciphertext x3 a The corresponding private information x.

[0357] S1804 . The mobile phone 210 sends a query request (a first query request) to the cloud 220 . The query request includes the relationship dictionary 5 .

[0358] When it is not the first query, in stage 3, cloud 220 can determine that it is not the first query, and determine that the query includes new data in mobile phone 210 and / or data that has been historically queried in mobile phone 210. In addition, for the new data in mobile phone 210, cloud 220 can return information about the full amount of data that may be the same as the new data. For the data that has been queried in mobile phone 210, cloud 220 can return information about the data that may be the same as the data that has been queried, and the data whose status (such as new status and deregistration status) has been updated. Specifically, in stage 3, cloud 220 can execute the following S1805-S1810:

[0359] S1805 , the cloud 220 determines that the relationship dictionary 5 does not include the comparison time label 1 .

[0360] If the relation dictionary 5 does not include the comparison time tag 1, it indicates that it is not the first query. For the non-first query, the cloud 220 uses different processing methods for the newly added and non-newly added ciphertexts. Specifically, the newly added ciphertext is processed by the following S1806; the non-newly added ciphertext is processed by the following S1807-S1808.

[0361] S1806, cloud 220 queries the target bucket 1 corresponding to the hash value prefix in the newly added record indicated by the newly added tag 2. For details, please refer to the description of S1101 above.

[0362] Taking the relation dictionary 5 as shown in Table 11 and the bucketing result as shown in Table 9 as an example, the newly added label 2 indicates that the newly added record is the record of the last row, that is, "Hash value prefix: 0a9e; ciphertext: x5 a ; Comparison time: 2023-4-24; Newly added: Yes", where the hash value prefix is ​​0a9e. Then, cloud 220 can query Table 9 to find that target bucket 1 is bucket 0a9e.

[0363] S1807, cloud 220 searches for target bucket 2 corresponding to the hash value prefix (first hash feature) in the record indicated by the newly added tag 2, which is not newly added. For details, please refer to the description of S1101 above.

[0364] For ease of explanation, the hash prefix of the target bucket 2 may be referred to as a second hash feature.

[0365] Still taking the relation dictionary 5 as shown in Table 11 and the bucketing result as shown in Table 9 as an example, the newly added label 2 indicates that the records other than the last row are not newly added, and the involved hash value prefixes include 0002, 0003 and ffee. Then, the cloud 220 can query Table 9 to find that the target bucket 2 is bucket 0002, bucket 0003 and bucket ffee (not shown in Table 9).

[0366] S1808. Cloud 220 queries the update time of each record in target bucket 2, and determines record 1 in target bucket 2 whose update time is later than the comparison time.

[0367] For example, the target bucket 2 is bucket 0002 in Table 9 and the relationship dictionary 5 is as shown in Table 11. The comparison time in Table 11 is 2023-4-24. The records in the target bucket 2 are as follows:

[0368] Record 1, hash value prefix: 0002; ciphertext: y1 b ; Update time: 2023-4-25; Cancellation: Yes;

[0369] Record 2, hash value prefix: 0002; ciphertext: y4 b ; Update time: 2023-4-22; Cancellation: No.

[0370] Then, the cloud 220 can compare the update time "2023-4-25" of the first record and the update time "2023-4-22" of the second record with the comparison time "2023-4-24". Obviously, the update time "2023-4-25" of the first record is later than the comparison time "2023-4-24", and the update time "2023-4-22" of the second record is earlier than the comparison time "2023-4-24".

[0371] If the update time of record 1 in target bucket 2 is later than the comparison time, it means that record 2 has been updated after the last comparison, so cloud 220 can use record 1 for comparison in this query. For example, the update time of the first record "2023-4-25" is later than the comparison time "2023-4-24", that is, the first record is record 1, and cloud 220 uses the first record for comparison in this query.

[0372] If the update time of record 2 in target bucket 2 is earlier than the comparison time, it means that record 1 has not been updated since the last comparison. Then, in the historical query process, record 2 has been used for comparison. Therefore, cloud 220 may no longer use record 2 for comparison in this query. Exemplarily, the update time "2023-4-25" in the second record is earlier than the comparison time "2023-4-24", that is, the second record is record 2, and cloud 220 may no longer use the second record for comparison in this query.

[0373] And, in Phase 3, also includes:

[0374] S1809, cloud 220 uses key b to re-encrypt the ciphertext in relational dictionary 5 to obtain data set Hm2(x) abFor details, please refer to the description of S1102 above.

[0375] It should be understood that, among the above S1806-S1809, it is only necessary to ensure that S1807 is before S1808, and there is no order restriction for the remaining steps.

[0376] S1810, cloud 220 sends the ciphertext of record 1 in target bucket 1 and target bucket 2 (referred to as target ciphertext) and its corresponding cancellation tag, as well as data set Hm2(x) to mobile phone 210 ab .

[0377] Compared with the first query: In the non-first query, the cloud 220 does not send the ciphertexts of all records in the target bucket (such as all records in target bucket 1 and target bucket 2) and their corresponding deregistration tags to the mobile phone 210, but only sends the ciphertexts of all records in a part of the target bucket (such as target bucket 1) and the ciphertexts (first ciphertext set) of some records (such as record 1) in another part of the target bucket (such as target bucket 2) and their deregistration status to the mobile phone 210. In this way, the amount of data sent can be further reduced, reducing communication overhead.

[0378] For example, target bucket 1 is bucket 0a9e in Table 9, and record 1 in target bucket 2 is record "hash value prefix: 0002; ciphertext: y1" in bucket 0002 shown in Table 9. b ; Update time: 2023-4-25; Cancellation: Yes", then the target ciphertext and its corresponding cancellation tag are shown in Table 12 below:

[0379] Table 12

[0380] Ciphertext Logout <![CDATA[y1 b ]]> yes <![CDATA[y0 b ]]> no

[0381] The hash value prefix corresponding to the target bucket 1 is the same as the hash value prefix of the newly added record indicated by the newly added label 2. Among them, the target bucket 1 contains records of private information y, and the newly added record indicated by the newly added label 2 is the record of private information x added after the last query. Therefore, the record in the target bucket 1 can be regarded as a record of private information y that may be the same as the newly added private information x. That is, the target bucket 1 includes records corresponding to the incremental private information x in the mobile phone 210.

[0382] The hash value prefix corresponding to the above-mentioned target bucket 2 is the same as the hash value prefix of the newly added record indicated by the newly added label 2. Among them, the target bucket 2 contains records of private information y, and the newly added label 2 indicates that the newly added record is not a record of private information x that was newly added after the last query. Therefore, the records in the target bucket 2 can be regarded as records of private information y that may be the same as the non-newly added private information x. Furthermore, record 1 is a record of private information y that may be the same as the non-newly added private information x and has been updated. That is, record 1 is a record of a portion of the updated (also understood as an increment) private information y in cloud 220.

[0383] In other words, when it is not the first query, the cloud 220 only sends the record of incremental data to the mobile phone 210.

[0384] When it is not the first query, in stage 4, the mobile phone 210 obtains the same elements by comparison and obtains the query result based on whether the data returned by the cloud 220 is deregistered data or newly added data. In some cases, it is necessary to further combine the query results of historical queries and / or whether the data to be queried is newly added data in the mobile phone 210 to obtain the query result of this time. Specifically, the mobile phone 210 can execute the following S1811-S1814:

[0385] S1811, mobile phone 210 uses key a to perform a pairing operation on data set Hm2(x) ab The ciphertext in is decrypted once to obtain the data set Hm2(x) b For details, please refer to the description of S1301 above.

[0386] S1812, mobile phone 210 sends data set Hm2(x) b The ciphertext in is compared with the target ciphertext.

[0387] S1813, if the data set Hm2(x) b The ciphertext xi in b and the ciphertext yj in the target ciphertext b The same, and the ciphertext yj b The deregistration tag indicates that the deregistration has not been completed, and the mobile phone 210 displays the query result of the private information xi as "yes". For details, please refer to the description of S1711 above.

[0388] Ciphertextxi b and the target ciphertext yj b If the ciphertext yj b Not cancelled, to show the ciphertext yj b The corresponding private information yj is still valid, for example, it is still a risk number, still a registration number, etc. In this case, the query result of the private information xi is confirmed to be yes.

[0389] For example, for newly added private information x5 (i.e., newly added after the last query), the ciphertext x5 of the private information x5 is queried. b Compared with the ciphertext y0 in Table 12 above b The same means that the private information x5 is the same as the ciphertext y0 b The corresponding private information y0 is the same. And, the ciphertext y0 b The deregistration tag indicates that the deregistration is not completed, which indicates that the private information y0 is still valid. Therefore, the mobile phone 210 can display the query result of the private information x5 as yes.

[0390] S1814, if the data set Hm2(x) b The ciphertext xi in b and the ciphertext yj in the target ciphertext b Same, but the ciphertext yj b The logout tag indicates that the logout has been completed, and the mobile phone 210 displays the query result of the private information xi as "no".

[0391] Ciphertextxi b and the target ciphertext yj b If the ciphertext yj b Already cancelled, to indicate the ciphertext yj b The corresponding private information yj is no longer in a valid state, for example, it is no longer a risk number, no longer a registered number, etc. In this case, the query result of confirming the private information xi is no.

[0392] For example, for the original private information x1 (i.e., before the last query), the ciphertext x1 of the private information x1 is queried. b Compared with the ciphertext y1 in Table 12 above b The same means that the private information x1 and the ciphertext y1 b The corresponding private information y1 is the same. And, the ciphertext y1 b The deregistration tag of indicates that the private information y1 has been deregistered, which indicates that the private information y1 is no longer valid. Therefore, the mobile phone 210 can display that the query result of the private information x1 is no.

[0393] S1815. If the data set Hm2(x) b The ciphertext xi in b It is different from all the ciphertexts in the target ciphertext, and the newly added tag 2 of the private information xi indicates that it is newly added, and the mobile phone 210 displays the query result of the private information xi as "no".

[0394] If the private information xi is newly added, then after S1806 and S1810, the cloud 220 has sent all the ciphertexts of the private information y that may be the same as the private information xi to the mobile phone 210. On this basis, if the ciphertext xi b If it is different from all the ciphertexts in the target ciphertext (including all ciphertexts of private information y that may be the same as private information xi), it means that the private information xi is not included in the cloud 220, so the query result of the private information xi is no.

[0395] After the above S1813-S1815, the increment of the query result is obtained, that is, the change compared with the previous query. On this basis, the query result of the current query can also be obtained in combination with the query result of the previous query. Specifically, as shown in the following S1816:

[0396] S1816, if the data set Hm2(x) b The ciphertext xi in b The private information xi is different from all the ciphertexts in the target ciphertext, and the new tag 2 of the private information xi indicates that it is not new, and the mobile phone 210 displays the query result of the last query of the private information xi.

[0397] If the private information xi is not newly added, then after the above S1807, S1808 and S1810, the cloud 220 only sends the ciphertext of all the private information y that may be the same as the private information xi and whose update time is later than the comparison time to the mobile phone 210. On this basis, if the ciphertext xi b It is different from all the ciphertexts in the target ciphertext, which can only indicate that the private information y updated later than the comparison time does not include the private information xi. Further, if the query result of the private information xi obtained in the last query is no, it can be further determined that the private information y updated earlier than the comparison time does not include the private information xi, so it is determined that the cloud 220 does not include the private information xi, and the query result of the private information xi is no. On the contrary, if the query result of the private information xi obtained in the last query is yes, it can be further determined that the private information y updated earlier than the comparison time includes the private information xi, so it is determined that the cloud 220 includes the private information xi, and the query result of the private information xi is yes.

[0398] It can be seen that if the data set Hm2(x) b The ciphertext xi in bIf the private information xi is different from all the ciphertexts in the target ciphertext, and the newly added tag 2 of the private information xi indicates that it is not newly added, the mobile phone 210 shall take the query result of the private information xi obtained by the last query as the standard. That is, if the query result of the private information xi obtained by the last query is yes, then the query result of the private information xi obtained by this query is yes; if the query result of the private information xi obtained by the last query is no, then the query result of the private information xi obtained by this query is no. Of course, the mobile phone 210 can directly keep the state of the private information xi (yes or no state) unchanged without obtaining the historical query results.

[0399] In addition, after the non-first query is completed, the mobile phone 210 may also execute the following S1817:

[0400] S1817: Mobile phone 210 updates the comparison time. For details, please refer to the description of S1712 above.

[0401] In order to facilitate the above Fig.17 and Fig.18 The understanding of the query process shown below is combined with Fig.19 The flowchart shown below briefly explains the core of the query process:

[0402] S1901. The mobile phone 210 sends a query request to the cloud 220. The query request is used to query whether the private information y of the cloud 220 includes the private information xi. For details, please refer to the description of S1701-S1704 or S1801-S1804 above.

[0403] S1902: The cloud 220 detects whether the query request is the first request of the mobile phone 210 to query the private information x from the cloud 220. If yes, S1903 is executed; if no, S1905 is executed. For details, please refer to the description of S1705 or S1805 above.

[0404] Specifically, as shown in S1705, if the query request includes the comparison time tag 1, the cloud 220 may determine it as the first query. As shown in S1805, if the query request does not include the comparison time tag 1, the cloud 220 may determine it as a non-first query.

[0405] S1903, the cloud 220 sends a query response 1 to the mobile phone 210, and the query response 1 includes information about the full amount of data that may be the same as the private information xi. For details, please refer to the description of S1706-S1708 above.

[0406] It should be noted that in the above embodiments, the hash value prefix is ​​mainly used to search for possibly identical data, such as searching for private information y that may be identical to private information x. In actual implementation, this is not limited to this. For example, other bits in the hash value may also be used to search for possibly identical data. In other words, some bits (preset bits) of the hash value may be used to search for possibly identical data.

[0407] S1904: Mobile phone 210 determines the query result based on query response 1. For details, please refer to the description of S1709-S1711 above.

[0408] If the data set Hm1(x) b The ciphertext xi in b and the ciphertext yj in the target bucket b The same, and the ciphertext yj b The logout label indicates that the logout is not completed, and the query result of the private information xi is "yes". If the dataset Hm1(x) b The ciphertext xi in b and the ciphertext yj in the target bucket b Same, but the ciphertext yj b The deregistered label indicates that it has been deregistered, or if the dataset Hm1(x) b The ciphertext xi in b If it is different from all the ciphertexts in the target bucket, the query result of the private information xi is "No"

[0409] It should be noted that during the first query, the mobile phone 210 does not need to refer to the query results of the historical query and whether the private information xi is new data in the mobile phone 210 .

[0410] S1905: The cloud 220 determines the newly added data of the mobile phone 210 in the private information xi, and determines the full amount of data that may be the same as the newly added data in the private information xi. For details, please refer to the description of S1806 above.

[0411] For example, if the newly added tag 2 of the ciphertext indicates "newly added", it means that the ciphertext is the ciphertext of newly added data.

[0412] S1906, the cloud 220 determines the data in the private information xi that the mobile phone 210 has already queried, and determines the incremental data in the full data that may be the same as the queried data and whose status has been updated in the cloud 220. For details, please refer to the description of S1807-S1808 above.

[0413] For example, if the newly added tag 2 of the ciphertext indicates that it is not newly added, it means that the ciphertext is the ciphertext of data that has been queried.

[0414] In this way, for the repeatedly queried private information xi, the cloud 220 only needs to return the information of the incremental data, which can greatly reduce the amount of transmitted data.

[0415] S1907, the cloud 220 sends a query response 2 to the mobile phone 210, and the query response 2 includes information about the full amount of data that may be the same as the newly added data, and / or information about the incremental data whose status has been updated in the cloud 220 in the full amount of data that may be the same as the already queried data. For details, please refer to the description of S1809-S1810 above.

[0416] At this point, it should be noted that, in practice, the private information xi may only include the newly added data, in which case only S1905 needs to be executed. Then, the query response 2 does not include the information of the incremental data whose status in the cloud 220 is updated in the full amount of data that may be the same as the data that has been queried. Alternatively, the private information xi may only include the data that has been queried, in which case only S1906 needs to be executed. Then, the query response 2 does not include the information of the full amount of data that may be the same as the newly added data.

[0417] S1908: The mobile phone 210 determines the query result based on the query response 2, whether the private information xi is new data in the mobile phone 210, and the historical query result (such as the last query result). For details, please refer to the description of S1811-S1816 above.

[0418] For the case where the private information xi is new data in the mobile phone 210, if the data set Hm2(x) b The ciphertext xi in b and the ciphertext yj in the target ciphertext b The same, and the ciphertext yj b The logout label indicates that the logout is not completed, so the query result of the private information xi is "yes". If the dataset Hm2(x) b The ciphertext xi in b and the ciphertext yj in the target ciphertext b Same, but the ciphertext yj b The logout tag of indicates that the user has logged out, and the query result of the private information xi is “no”.

[0419] For the case where the private information xi is not new data in the mobile phone 210, if the data set Hm2(x) b The ciphertext xi in b and the ciphertext yj in the target ciphertext b The same, and the ciphertext yj b The logout label indicates that the logout is not completed, so the query result of the private information xi is "yes". If the dataset Hm2(x) b The ciphertext xi inb and the ciphertext yj in the target ciphertext b Same, but the ciphertext yj b The logout tag indicates that the data set has been logged out, and the query result of the private information xi is "no". b The ciphertext xi in b If the private information xi is different from all the ciphertexts in the target ciphertext, the query result of the private information xi obtained by the historical query is used as the query result of this time. For example, if the query result of the private information xi obtained by the historical query is "yes", the query result of the private information xi obtained this time can also be "yes"; if the query result of the private information xi obtained by the historical query is "no", the query result of the private information xi obtained this time can also be "no".

[0420] In some other embodiments, in stage 1, the cloud 220 may also convert the data set Hn(y) b Compress each ciphertext in to obtain the compressed data set Hn(y) b’ In the subsequent stage 3, the cloud 220 can compress the data set Hn(y) b’ Return to the mobile phone 210 so that the mobile phone 210 can compare. It should be understood that the data set Hn(y) before compression b Compare: Compressed data set Hn(y) b’ That is, the amount of data transmitted from the cloud 220 to the mobile phone 210 can be reduced, reducing communication overhead.

[0421] See also Fig. 20 , after S501 in stage 1, it also includes S2001:

[0422] S2001, cloud 220 for data set Hn(y) b Compress each ciphertext in to obtain the compressed data set Hn(y) b’ .

[0423] For example, cloud 220 processes the data set Hn(y) b The ciphertext y1 in b 、ciphertext y2 b 、Ciphertext y3 b ... ciphertext yn b Compress them separately and get the compressed results y1 in turn b’ , the compressed result y2 b’ , the compressed result y3 b’ ...The compressed result yn b’ .

[0424] In a specific implementation, cloud 220 can use fingerprint compression to compress ciphertext. Fingerprint compression refers to using the "fingerprint" of the ciphertext to represent the ciphertext, thereby achieving compression of the ciphertext. It should be understood that the "fingerprint" here represents information that can uniquely represent the ciphertext, and is not a fingerprint in the conventional sense.

[0425] For example, the specific implementation of fingerprint compression may be: Cloud 220 uses the data set Hn(y) b A portion of the bits (the second bit) of each ciphertext in is used as the result of ciphertext compression. Fig.17 Compression method 1 shown, data set Hn(y) b The ciphertexts DC9CA4E4602…204B3, 60E9A9315AB…E4F5E, 294DE95CBCD…C1D91, and A61DF617262…79A1F are included in the dataset. Cloud 220 can take the first 32 bits of these ciphertexts and obtain the compressed results DC9CA4E4, 60E9A931, 294DE95C, and A61DF617 in turn. Then the dataset Hn(y) b’ These include DC9CA4E4, 60E9A931, 294DE95C and A61DF617.

[0426] As another example, the specific implementation of fingerprint compression may be: Cloud 220 performs the following operations on the data set Hn(y): b Calculate the hash value of each ciphertext in , and then take some bits of the hash value (the second bit) as the result of ciphertext compression. Fig.17 Compression method 2 shown, data set Hn(y) b The ciphertexts DC9CA4E4602…204B3, 60E9A9315AB…E4F5E, 294DE95CBCD…C1D91, and A61DF617262…79A1F are included in the data set. Cloud 220 can hash these ciphertexts and obtain the hash values ​​51A15180…002E11A0C0E, C3000810…00341AA6176, 4BB12980…00C497DE639, and D6B71BD0…002DF235902. Then, Cloud 220 takes the first 32 bits of these hash values ​​and obtains the compressed results 51A15180, C3000810, 4BB12980, and D6B71BD0, respectively. The data set Hn(y) b’ These include 51A15180, C3000810, 4BB12980 and D6B71BD0.

[0427] And, in phase 3, S505 is replaced by S2002:

[0428] S2002, cloud 220 sends data set Hm(x) to mobile phone 210 ab And the data set Hn(y) b’ .

[0429] In this embodiment, since the cloud 220 sends the compressed ciphertext, in stage 4, the mobile phone 210 decrypts the data set Hm(x) b After S5062a, S2003 is also included to make the data comparable:

[0430] S2003, mobile phone 210 data set Hm(x) b Compress each ciphertext in and get the data set Hm(x) b '.

[0431] For example, the mobile phone 210 performs the following operations on the data set Hm(x): b The ciphertext x1 in b Compress and get the compressed result x1 b’ .

[0432] It should be understood that the compression algorithm used in S1403 is the same as the compression algorithm used in S1401.

[0433] And, S5062b in stage 4 is replaced by S2004:

[0434] S2004, mobile phone 210 sends the data set Hm(x) b’ And the data set Hn(y) b’ Compare and obtain the comparison result.

[0435] Since the mobile phone 210 only sends the data set Hm(x) b ' and data set Hn(y) b’ Comparison, without the need to restore the data set Hm(x) b’ And the data set Hn(y) b’ Therefore, when compressing, the cloud 220 or the mobile phone 210 can use an irreversible compression algorithm to further reduce the amount of data.

[0436] At this point, it should be noted that the above embodiments of ciphertext bucketing and ciphertext compression can be combined. For example, in stage 1, cloud 220 can divide the ciphertext into buckets; and cloud 220 compresses the ciphertext in each bucket. In stage 3, after receiving the query request, cloud 220 can send the compressed result in the target bucket to mobile phone 210. In stage 4, mobile phone 210 decrypts the data set Hm(x) b After that, the data set Hm(x) can be bAfter each ciphertext in the target bucket is compressed, it is compared with the compressed result in the target bucket. In this way, the amount of transmitted data can be reduced to a greater extent through bucketing and compression, reducing communication overhead.

[0437] In practice, after different ciphertexts are compressed, the compression results may be the same, that is, a collision occurs. Fig.21 Taking the compression method 1 shown in the figure as an example, the first 32 bits of the ciphertext are taken as the result of compression. Although the two ciphertexts are different, the first 32 bits of the two ciphertexts may be the same. And, generally speaking, the lower the compression rate (that is, the greater the degree of compression), the greater the possibility of compression collision. Taking the first 32 bits and the first 16 bits of the ciphertext as an example, if the first 16 bits are taken, 16 bits of the ciphertext need to be retained, while if the first 32 bits are taken, 32 bits of the ciphertext need to be retained. Obviously, the compression rate of the first 16 bits is lower. However, the possible values ​​of 16 bits include 0000-ffff, a total of 16 4 There are 16 possible values ​​for the 32 bits, including 00000000-ffffffff. 8 It should be understood that the fewer possible values, the greater the possibility of a collision. Then, taking the first 32 bits of the ciphertext, the possibility of a collision is greater.

[0438] After a collision occurs, the query may go wrong. Exemplarily, the risk numbers in cloud 220 include number 1, number 2, number 3, number 5, number 6, and number 10, and the incoming call number in mobile phone 210 is number 4. In other words, number 4 is not included in the risk numbers in cloud 220, that is, number 4 is not a risk number. However, if the compression result of any one of number 1, number 2, number 3, number 5, number 6, and number 10 is the same as the compression result of number 4, mobile phone 210 may determine number 4 as a risk number after comparison. This is obviously inconsistent with the actual situation (that is, number 4 is not a risk number), and the query went wrong.

[0439] Generally speaking, as long as the probability of error is not high, the impact will not be significant. However, in some scenarios, such query errors are not allowed. For example, identifying a contact who is not registered with social application A as a registered user of social application A is obviously not allowed. Therefore, in the embodiment of ciphertext compression, it is necessary to further avoid the problem of collision.

[0440] In some embodiments, see Fig. 22, before the cloud 220 executes the previous stage 1, it also includes stage 0, in which the cloud 220 determines the processing parameters (first processing parameters). The processing parameters include key b, indication information for indicating whether to compress the ciphertext encrypted using key b, and one or more of the compression algorithms used when indicating to compress the ciphertext encrypted using key b. Subsequently (such as in stages 1-4), the cloud 220 and the mobile phone 210 can process based on these processing parameters to avoid collisions and improve the accuracy of the query. For example, in stage 1, the cloud 220 can obtain the ciphertext in each bucket based on these processing parameters so that there is no collision in each bucket.

[0441] The following uses the combination of ciphertext bucketing and ciphertext compression as an example, mainly in scenario 1, to illustrate the specific implementation of phase 0. Fig.23A , Fig. 23B and Fig.23C In phase 0, cloud 220 may perform the following steps:

[0442] S2301. Cloud 220 obtains all possible Q pieces of private information (experimental data) and obtains a full data set H(Q) of private information, where 1≤Q and Q is an integer.

[0443] Exemplarily, the full data set H(Q) includes all mobile phone numbers (experimental numbers), such as mobile phone number q1, mobile phone number q2...mobile phone number qQ, which is about 2 billion.

[0444] S2302. Cloud 220 uses hash algorithm 1 to calculate hash values ​​for Q pieces of private information respectively, and obtains Q hash values.

[0445] For the specific implementation of S2302, please refer to the description of S901 above, which will not be repeated here.

[0446] S2303. Cloud 220 divides the buckets according to the hash value prefixes of the Q hash values ​​(ie, the values ​​of the first k0 bits).

[0447] A hash value prefix is ​​divided into a bucket. Taking k = 16 as an example, buckets 0000, 0001...ffff can be obtained, for a total of 65536 buckets.

[0448] S2304. Cloud 220 randomly generates a key b0, and uses the key b0 to encrypt Q pieces of private information to obtain Q pieces of ciphertext.

[0449] Cloud 220 can use key b0 to encrypt Q hash values ​​to obtain ciphertext q1 b0 、ciphertext q2 b0 ,……,ciphertextqQ b0， Thus, Q pieces of private information can be encrypted ( Fig.23A, Fig. 23B and Fig.23C This is the implementation shown); alternatively, the cloud 220 can use the key b0 to encrypt the Q pieces of private information itself, thereby encrypting the Q pieces of private information.

[0450] For the specific implementation of S2304, please refer to the description of S902 above, which will not be repeated here.

[0451] S2305, Cloud 220 divides the Q ciphertexts into buckets.

[0452] For any ciphertext qz b0 (1≤z≤Q, z is an integer), cloud 220 divides it into buckets corresponding to the hash value prefix of the private information qz.

[0453] For example, if the hash value prefix of the mobile phone number q1 is 0001, then the ciphertext q1 of the mobile phone number q1 can be b0 Divided into bucket 0001; the hash value prefix of mobile phone number q2 is ffff, then the ciphertext q2 of mobile phone number q2 can be b0 Divide into buckets ffff... The hash value prefix of the mobile phone number qQ is 0000, then the ciphertext qQ of the mobile phone number qQ can be b0 Divide into bucket 0000.

[0454] For the specific implementation of S2305, please refer to the description of S903 above, which will not be repeated here.

[0455] S2306. Cloud 220 uses compression algorithm 1 (first compression algorithm) to compress the ciphertext in each bucket.

[0456] The ciphertext in bucket 0000 includes ciphertext q5 b0 、ciphertext q80 b0 、ciphertext q900 b0 And the ciphertext qQ b0 For example, we can take some bits of these ciphertexts, or take some bits of these ciphertexts after hashing them, so as to obtain the compressed results of each ciphertext, such as DC9CA4, 60E9A9, 294DE9 and DC9CA4. In stage 0, the ciphertext in each bucket obtained by encryption and compression using a random key is called an experimental ciphertext set.

[0457] After S2306, after compression, the compressed results of each ciphertext can be obtained. Subsequently, cloud 220 can complete collision detection and avoidance based on the compression results, so that there is no collision problem in each bucket. The following is an explanation of three specific implementation methods.

[0458] In a first implementation, the cloud 220 can avoid collision by regenerating a random key, and determine the random key that ultimately avoids collision as the second key. Fig.23A As shown, after S2306, it also includes:

[0459] S2307a: Cloud 220 detects whether at least one bucket has a collision. If yes, S2304 and subsequent steps are repeated; if no, S1408a is executed.

[0460] For any bucket, cloud 220 can detect whether the bucket includes the same compressed result. If the same compressed result is included, it indicates that there is a collision in the bucket. For example, bucket 0000 includes two DC9CA4, which indicates that there is a collision in bucket 0000. On the contrary, if the same compressed result is not included, it indicates that there is no collision in the bucket.

[0461] If at least one bucket with a collision is included, S2304 and its subsequent steps are repeatedly executed to regenerate a key for encryption. Experience shows that in the case of a collision, if the key is changed for encryption and then compressed, the possibility of a collision occurring again will be greatly reduced. Therefore, by repeatedly executing S2304 and its subsequent steps, the possibility of a collision may be reduced.

[0462] If at least one bucket having a collision is not included, that is, there is no collision problem in all buckets, the following S2308a is executed to save the processing parameters.

[0463] S2308a, cloud 220 saves hash algorithm 1, k0, b0 and compression algorithm 1.

[0464] That is, the processing parameters include bucketing, hash algorithm 1, k0, b0, and compression algorithm 1. The cloud 220 stores the processing parameters, which can be used for processing in subsequent stages.

[0465] The hash algorithm 1 is used for hashing in stage 1 and stage 2. Exemplarily, the hashing is performed in S901 and S1001.

[0466] k0 is used to obtain a hash value prefix in phase 1 and phase 2. Exemplarily, k0 can be used as k to obtain a hash value prefix in S903 and S1003.

[0467] b0 refers to a key randomly generated during the last round of execution of S2304. b0 is used for encryption processing in phase 1 and phase 3. Exemplarily, b0 can be used as b for encryption in S902 and S1102.

[0468] Compression algorithm 1 is used to compress ciphertext in stage 1 and stage 4. Exemplarily, ciphertext is compressed in S1601 and S1603.

[0469] That is, in implementation mode 1, cloud 220 can detect whether the same compressed ciphertext is included in each bucket. If at least one bucket includes the same compressed ciphertext, cloud 220 can update the random key, and use the updated secretary key and the original compression algorithm 1 to re-obtain the compressed ciphertext in each bucket until the same compressed ciphertext does not exist in all buckets, and then obtain the final processing parameters. For example, the processing parameters include the final updated random key and compression algorithm 1. Among them, the final updated random key is used as the key b in the previous text.

[0470] It should be understood that in stage 0, the collision detection is performed on the full data set (such as 2 billion mobile phone numbers), and the effect of no collision in each bucket is achieved. Then, in stages 1 to 4, these processing parameters are used to process the subset of the above full data set (such as Hm(x) and Hn(y) in the previous text), which can also ensure that the compressed results of ciphertexts with the same hash value prefix (i.e., ciphertexts divided into a bucket in stage 0) will not have collisions. Then, in stage 4, mobile phone 210 uses Fig.15 By comparing the methods shown, there is no possibility of query errors, thereby improving the accuracy of the query results. The same is true for the implementation methods 2 and 3 below.

[0471] In the second implementation, the cloud 220 can mark the buckets where collisions occur, such as recording the hash prefix (first hash feature) of the buckets where collisions occur. In the subsequent compression process, if the hash feature of the private information y is the same as the recorded hash feature, the private information y will not be further compressed after being compressed using the key b to avoid collisions. Specifically, Fig. 23B As shown, after S2306, it also includes:

[0472] S2307b, cloud 220 traverses the buckets and detects whether there is a collision in the compressed result in the current bucket. If yes, execute S2308b; if no, continue to detect the next bucket.

[0473] For the specific implementation of detecting whether there is a collision, please refer to the description in S2307a above, which will not be repeated here.

[0474] S2308b, cloud 220 marks the current bucket.

[0475] For the current bucket, if a collision is detected, the current bucket is marked. For example, the hash prefix of the bucket with the collision is recorded. In this way, when the ciphertext in each bucket is compressed in the subsequent stage 1, the ciphertext in the marked bucket will not be compressed.

[0476] S2309b, cloud 220 saves hash algorithm 1, k0, b0 and compression algorithm 1.

[0477] Regarding hash algorithm 1, k0 and b0, please refer to the relevant description in S2308a above, which will not be repeated here.

[0478] It should be noted that, in this implementation, compression algorithm 1 is used to compress the ciphertext in the unmarked buckets in stage 1, while for the marked buckets, compression algorithm 1 is not needed for compression. That is, if the hash prefix of the private information y is the same as the hash feature of the marked bucket, there is no need to further compress the private information y after encrypting it with key b. On the contrary, if the hash prefix of the private information y is different from the hash feature of the marked bucket, further compression is needed after encrypting the private information y with key b. And, in stage 4, the ciphertext xi is obtained by decrypting with key a. b After that, you may need to b Compression may not be necessary for the ciphertext xi b Specifically, the mobile phone 210 can compress the ciphertext xi b The data to be compared, such as the ciphertext xi in relational dictionary 2 ab The length of the corresponding data determines whether the ciphertext xi needs to be b If the length of the data to be compared is less than or equal to length 1 (the first length), it means that the data to be compared is compressed, so the ciphertext xi needs to be compressed. b Compression. If the length of the data to be compared is greater than length 1, it means that the data to be compared is not compressed, so there is no need to compress the ciphertext xi. b Compression. In this way, the two compared data can be made comparable while avoiding collisions.

[0479] Of course, in stage 1, cloud 220 can identify the compressed result or the uncompressed ciphertext. Thus, in stage 4, if the ciphertext xi is found b The data to be compared has a compressed result identifier (or does not have an uncompressed ciphertext identifier), and the mobile phone 210 can convert the ciphertext xi b After compression, it is compared with the data to be compared; if the ciphertext xi is found b The data to be compared does not have a compressed result identifier (or has an uncompressed ciphertext identifier), and the mobile phone 210 can convert the ciphertext xi b Without compression, it is compared with the data to be compared.

[0480] In implementation method 3, cloud 220 may use a longer compression bit number for buckets with collisions to avoid collisions. Specifically, Fig.23C As shown, it also includes:

[0481] S2307c, cloud 220 traverses the buckets and detects whether there is a collision in the compressed results in each bucket. If yes, execute S2308c; if not, continue to detect the next bucket.

[0482] For the specific implementation of detecting whether there is a collision, please refer to the description in S2307a above, which will not be repeated here.

[0483] S2308c, cloud 220 uses compression algorithm 2 (the second compression algorithm) to re-compress the ciphertext in the current bucket. The number of compression bits of compression algorithm 2 is greater than that of compression algorithm 1.

[0484] For any bucket, if a collision is detected in the current bucket, the compression rate is sacrificed and a compression algorithm 2 with a longer compression number is used to compress the ciphertext in the current bucket to avoid collision.

[0485] For example, the ciphertext in bucket 0000 includes ciphertext q5 b0 、ciphertext q80 b0 、ciphertext q900 b0 And the ciphertext qQ b0 , if 24 bits are taken, the compressed results DC9CA4, 60E9A9, 294DE9 and DC9CA4 can be obtained in sequence, among which DC9CA4 is repeated and there is a collision. Then, 28 bits can be taken. For example, if 28 bits are taken, the compressed results DC9CA41, 60E9A92, 294DE93 and DC9CA44 can be obtained in sequence.

[0486] S2309c: Cloud 220 checks whether there is a collision in the compressed result in the current bucket. If yes, S2308c and S2309c are repeated. If no, S2310c is executed.

[0487] If a collision still exists after compression with a longer compression bit number, S2308c and subsequent steps are repeated for the current bucket, and the compression bit number is increased again for compression.

[0488] If there is no collision after compression with a longer compression bit number, the following S2310c can be executed so that a longer compression bit number is used for the current bucket in the future to avoid collision.

[0489] S2310c, cloud 220 associates compression algorithm 2 with the current bucket and saves it.

[0490] In this way, when the ciphertexts in each bucket are compressed in the subsequent stage 1, the ciphertexts in the current bucket will be compressed using compression algorithm 2.

[0491] S2311c, cloud 220 saves hash algorithm 1, k0, b0 and compression algorithm 1.

[0492] Regarding hash algorithm 1, k0 and b0, please refer to the relevant description in S2308a above, which will not be repeated here.

[0493] It should be noted that in this implementation, compression algorithm 1 is used in stage 1 to compress the ciphertext in the bucket that is not associated with compression algorithm 2, while for the bucket associated with compression algorithm 2, compression algorithm 2 is used for compression. And, in stage 4, the ciphertext xi is obtained by decrypting with key a. b After that, it may be necessary to use compression algorithm 1 for compression, or it may be necessary to use compression algorithm 2 for compression. Specifically, the mobile phone 210 may use the ciphertext xi b The data to be compared, such as the ciphertext xi in relational dictionary 2 ab The number of bits of the corresponding data (which can also be understood as the length), select compression algorithm 1 or compression algorithm 2 for the ciphertext xi b If the number of bits of the data to be compared is 1 (equal to the number of bits of compression algorithm 1, such as the second length), then the ciphertext xi b Compression algorithm 1 is used for compression. If the number of bits of the data to be compared is 2 (equal to the number of bits of compression algorithm 2, such as the third length), then the ciphertext xi b Compression algorithm 2 is used for compression. In this way, the two compared data can be made comparable under the premise of avoiding collision.

[0494] Of course, in stage 1, after cloud 220 compresses each ciphertext, it can identify the compression algorithm used in the compressed result. b The data to be compared has the identifier of compression algorithm 1, and the mobile phone 210 can use compression algorithm 1 to compare the ciphertext xi b Compression; if the ciphertext xi is found b The data to be compared has the identifier of compression algorithm 2, and the mobile phone 210 can use compression algorithm 2 to compare the ciphertext xi b compression.

[0495] In the three implementations described above, the only processing parameters that change are b0 and the compression algorithm. For example, in implementation one, b0 may be regenerated; in implementation three, the compression algorithm used in some buckets is compression algorithm 2. In addition, hash algorithm 1 and k0 have not changed. Therefore, mobile phone 210 and cloud 220 can also preset the hash algorithm to hash algorithm 1 and the number of bits of the hash value prefix to k0, and then use hash algorithm 1 and k0 in stages 0-4. There is no need to save hash algorithm 1 and k0 in stage 0. That is, there is no need to save hash algorithm 1 and k0 in S2308a, S2309b and S2311c.

[0496] In the above embodiment for avoiding collision, the combination of ciphertext bucketing and ciphertext compression is used as an example for explanation. In actual real time, only ciphertext compression may be used to save communication overhead, and ciphertext bucketing may not be used to save communication overhead. In this case, the above S2301 and S2302 can be omitted, and there is no need to save bucket-related parameters, such as hash algorithm 1 and k0. In this way, collisions can also be avoided.

[0497] The present application also provides an electronic device, which may include: a memory and one or more processors. The memory and the processor are coupled. The memory is used to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the electronic device can execute the various functions or steps executed by the mobile phone in the above method embodiment.

[0498] The present application also provides a chip system, such as Fig.24 As shown, the chip system 2400 includes at least one processor 2401 and at least one interface circuit 2402. The processor 2401 and the interface circuit 2402 can be interconnected via lines. For example, the interface circuit 2402 can be used to receive signals from other devices (such as a memory of an electronic device). For another example, the interface circuit 2402 can be used to send signals to other devices (such as processor 2401). Exemplarily, the interface circuit 2402 can read instructions stored in the memory and send the instructions to the processor 2401. When the instructions are executed by the processor 2401, the electronic device can perform the various steps in the above embodiments. Of course, the chip system may also include other discrete devices, which are not specifically limited in the embodiments of the present application.

[0499] This embodiment further provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are executed on an electronic device, the electronic device executes each function or step executed by the mobile phone in the above method embodiment.

[0500] This embodiment further provides a computer program product. When the computer program product is run on a computer, the computer executes each function or step executed by the mobile phone in the above method embodiment.

[0501] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory so that the chip executes each function or step performed by the mobile phone in the above method embodiment.

[0502] Among them, the electronic device, communication system, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above and will not be repeated here.

[0503] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0504] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0505] The unit described as a separate component may or may not be physically separated, and the component shown as a unit may be one physical unit or multiple physical units, that is, it may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiment.

[0506] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0507] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), disk or optical disk and other media that can store program code.

[0508] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present application and are not intended to limit it. Although the present application has been described in detail with reference to the preferred embodiments, a person of ordinary skill in the art should understand that the technical solution of the present application may be modified or replaced by equivalents without departing from the spirit and scope of the technical solution of the present application.

Claims

1. A query method, characterized in that: The method comprises: The first device sends a first query request to the second device, where the first query request includes a first ciphertext obtained by encrypting the first data using the first key; The first device receives a second ciphertext from the second device and a first ciphertext set corresponding to incremental data of a data set in the second device, wherein the second ciphertext is obtained by encrypting the first ciphertext using a second key, and the ciphertext in the first ciphertext set is obtained by encrypting the incremental data using the second key, and the incremental data refers to: data in which a state of the data set is updated between time t1 and time t2; the state includes a deregistered state or a newly added state, the time t2 is the current time, and the time t1 is a time before time t2 when the first device queries whether the data set includes the first data; The first device decrypts the second ciphertext using the first key to obtain a third ciphertext; The first device compares the third ciphertext with the first ciphertext set to obtain a first comparison result, wherein the first comparison result indicates whether the first ciphertext set includes the third ciphertext; The first device determines a first query result based on the first comparison result, where the first query result indicates whether the second device includes the first data.

2. The method according to claim 1, characterized in that: The first query request also includes a first hash feature of the first data; The incremental data refers to data whose status is updated in the data set between time t1 and time t2, and whose second hash feature is the same as the first hash feature.

3. The method according to claim 2, characterized in that The first hash feature includes information of a preset bit in the hash value of the first data, and the second hash feature includes information of the preset bit in the hash value of the data whose status is updated.

4. The method according to claim 1, characterized in that The first device determines the first query result based on the first comparison result, including: If the first ciphertext set includes ciphertext of newly added data that is equal to the third ciphertext, then the first query result indicates that the second device includes the first data; Alternatively, if the first ciphertext set includes a ciphertext of cancellation data that is equal to the third ciphertext, then the first query result indicates that the second device does not include the first data; Alternatively, if the first ciphertext set does not include a ciphertext equal to the third ciphertext, and at time t1, the first device queries that the second device does not include the first data, then the first query result indicates that the second device does not include the first data; Alternatively, if the first ciphertext set does not include a ciphertext equal to the third ciphertext, but the first device queries at time t1 that the second device includes the first data, then the first query result indicates that the second device includes the first data.

5. The method according to claim 4, characterized in that Before determining the first query result, the method further includes: The first device detects that the first data is not newly added between time t1 and time t2.

6. The method according to any one of claims 1 to 5, characterized in that The second query request and the first query request are two consecutive query requests. The second query request is a query request for the first device to query whether the data set includes the first data at time t1.

7. The method according to any one of claims 1 to 5, characterized in that The method further comprises: After the first device queries whether the data set includes the first data at time t1, the first device records the query time, where the query time indicates time t1; The first query request also includes the query time, and the query time is used by the second device to determine the first ciphertext set.

8. A query method, characterized in that: The method comprises: The second device receives a first query request from the first device, where the first query request includes a first ciphertext obtained by encrypting the first data using the first key; The second device sends the second ciphertext and a first ciphertext set corresponding to the incremental data of the data set in the second device to the first device, so that the first device compares the first ciphertext set with a third ciphertext obtained by decrypting the second ciphertext using the first key, determines a first comparison result indicating whether the first ciphertext set includes the third ciphertext, and determines a first query result based on the first comparison result, the first query result indicating whether the second device includes the first data; Among them, the second ciphertext is obtained by encrypting the first ciphertext with a second key, and the ciphertext in the first ciphertext set is obtained by encrypting the incremental data with the second key. The incremental data refers to: data in which the status of the data set of the second device is updated between time t1 and time t2; the status includes a deregistration status or a new addition status, the time t2 is the current time, and the time t1 is a time before time t2 when the first device queries whether the data set includes the first data.

9. The method according to claim 8, characterized in that The first query request also includes first characteristic information, where the first characteristic information is characteristic information of ciphertext obtained by encrypting the first data using an irreversible first encryption algorithm; Among them, incremental data refers to: data in which the second characteristic information matches the first characteristic information in the data whose status is updated between time t1 and time t2, and the second characteristic information is the characteristic information of the ciphertext obtained by encrypting the data whose status is updated using the first encryption algorithm.

10. The method according to claim 8 or 9, characterized in that: Before the second device sends the second ciphertext and the first ciphertext set corresponding to the incremental data of the data set in the second device to the first device, the method further includes: The second device detects that the first query request is a query request for the first device to query the data set of the second device, which is not the first time.

11. The method according to claim 10, characterized in that The first query request includes a query time, and the query time indicates that the first device has queried the data set of the second device at time t1.

12. The method according to claim 10, characterized in that Before the second device sends the second ciphertext and the first ciphertext set corresponding to the incremental data of the data set in the second device to the first device, the method further includes: The second device detects that the first data is not new data in the first device between time t1 and time t2.

13. A query method, characterized in that: The method comprises: The first device sends a first query request to the second device, where the first query request includes a first ciphertext obtained by encrypting the first data using the first key; In response to the first query request, the second device sends a second ciphertext and a first ciphertext set corresponding to incremental data of a data set in the second device to the first device, wherein the second ciphertext is obtained by encrypting the first ciphertext using a second key, and the ciphertext in the first ciphertext set is obtained by encrypting the incremental data using the second key, and the incremental data refers to: data in which a state of the data set is updated between time t1 and time t2; the state includes a deregistered state or a newly added state, the time t2 is the current time, and the time t1 is a time before the time t2 in the process of the first device querying whether the data set includes the first data; In response to the second ciphertext and the first ciphertext set, the first device decrypts the second ciphertext using the first key to obtain a third ciphertext; The first device compares the third ciphertext with the first ciphertext set to obtain a first comparison result, wherein the first comparison result indicates whether the first ciphertext set includes the third ciphertext; The first device determines a first query result based on the first comparison result, where the first query result indicates whether the second device includes the first data.

14. An electronic device, characterized in that: The device comprises a memory and a processor, wherein the memory and the processor are coupled; wherein the memory stores a computer program code, wherein the computer program code comprises a computer instruction; Wherein, the electronic device is a first device, and when the computer instruction is executed by the processor, the electronic device executes the steps executed by the first device in the method according to any one of claims 1 to 7 and 13; Alternatively, the electronic device is a second device, and when the computer instructions are executed by the processor, the electronic device executes the steps executed by the second device in the method as described in any one of claims 8 to 13.

15. A communication system, characterized in that: The communication system comprises the first device and the second device according to any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that: including computer instructions; Wherein, when the computer instruction is executed on the first device, the first device is caused to execute the steps executed by the first device in the method according to any one of claims 1 to 7 and 13; Alternatively, when the computer instructions are executed on a second device, the second device is caused to execute the steps executed by the second device in the method according to any one of claims 8 to 13.

17. A chip system, characterized in that: The chip system is applied to an electronic device including a processor and a memory, the chip system includes one or more interface circuits and one or more processors, the interface circuit and the processor are interconnected through a line, the interface circuit is used to receive a signal from the memory of the electronic device and send the signal to the processor, the signal includes a computer instruction stored in the memory; Wherein, the electronic device is a first device, and when the processor executes the computer instruction, the electronic device executes the steps executed by the first device in any one of the methods of claims 1-7 and 13; Alternatively, the electronic device is a second device, and when the processor executes the computer instructions, the electronic device executes the steps executed by the second device in the method as described in any one of claims 8 to 13.

Images